From nobody Wed Mar 1 01:43:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F71298AB for ; Wed, 1 Mar 2017 01:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Pkb_09W5Wbr7 for ; Wed, 1 Mar 2017 01:43:09 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685BE1298C5 for ; Wed, 1 Mar 2017 01:43:08 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id x75so6258568vke.2 for ; Wed, 01 Mar 2017 01:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8o4o7szHK7b2JDQVkdhA69YKOexoVnzxk6mKQKphEzc=; b=vTvV0MPErA8QOtcDSGV0TwR1Jfr8vmMNPxG/ZHbJ/teYFs3kla/Q0rJIuPRKPxMJ7g VYU4PrhOLPzoYKAccoao1/qVOj6bJI9bIWKgAisMl/tmKCNdAOCw5EMavMkweF6nhILc QOyoo8/H9g6V9AvzGU96bR1+XspkW6jSLHz94forusT+22G1uHhYTuLiefYsahFTbJYi NMOs9BBvMaFUQXYXP5oxtPLAUGCBjIsUHWW9707Fa4TWRtRXGGGJcKT0opSc7mTsDFq+ g8AisyzhJwsO0jxa6WJeO2b9k/YtfZse3eQ/wiZFpSW6xoWlABbgt5slEDdu61I/e3CA +6Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8o4o7szHK7b2JDQVkdhA69YKOexoVnzxk6mKQKphEzc=; b=jMxU3PmVVbkVkYHvzGVYvtetJ0avE0Vck0fS/OOnWmTNzw8yM4vQnYH/JTgWsVCYYP ImKn4PAB7wBbDZU5ubFj7EmVAUH3TS9GjxJWsEkriHuNP5E5UMxXLSjkSpvTi+yw4Xih Rwm8S0lbspxzsp6CsB7hypmOZwZSpB1Ezh3BQUr14gQrxhZoZoHiB3RWQw30NnMHVQek jk3L467Lvxfvc22L8ABQnoJawgF/KTCMWDbp6+Wf7dE1IYD+ATyQGA9UhuPiWHgrrFWo N8IWjXm/czMvmmupiJTPK3X9s7Rx3ILSogRWZ6pWpO00d+vLeeqMtO2MXGA4H0cXhsvL 4yPQ== X-Gm-Message-State: AMke39n3DT+zOmv3pnlmg8v4oxx31Y5NQo5e6QyCDVh/9ljX7F2D/gKo6SXY8+RiPSkGNZvheI4CZTYaUzt9RSzQ X-Received: by 10.31.59.197 with SMTP id i188mr2512115vka.45.1488361387257; Wed, 01 Mar 2017 01:43:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 1 Mar 2017 01:42:46 -0800 (PST) In-Reply-To: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> From: Lorenzo Colitti Date: Wed, 1 Mar 2017 18:42:46 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1142f178c950700549a82360 Archived-At: Cc: 6man WG , james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:43:10 -0000 --001a1142f178c950700549a82360 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 4:56 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > I really don't understand this statement. How can you say that it's a > > parameter, given that every RFC that has been published on this topic > > starting from 1998 states that (most) IIDs are 64 bits long? > > Yes, I think we have a long tradition of expressing this badly, and now > is a chance to get it right. It's clear at the point where it's > introduced in RFC4291 that it's a floating boundary: > > "A slightly sophisticated host (but still rather simple) may > additionally be aware of subnet prefix(es) for the link(s) it is > attached to, where different addresses may have different values for > n: > > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+" > > but later in the same document we state that (128-n) == 64. That is > inconsistent; what we're trying to do now is fix that inconsistency > in a way that is *also* consistent with running code, SLAAC, and the > newly important privacy issues that require long, unpredictable IIDs. > Ah, I see the disconnect here: you're talking about the addressing architecture, and I'm talking about unicast addresses assigned to actual networks. Those addresses are called "all global unicast addresses except the ones that start with binary 000" in 3513 and 4291, and "aggregatable global unicast addresses" (specifically, 2000::/3) in 2373. What I'm saying is that for that latter type of address, the IID length has always been fixed to 64, and should continue to be. --001a1142f178c950700549a82360 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 1, 2017 at 4:56 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
> I really don't understand this s= tatement. How can you say that it's a
> parameter, given that every RFC that has been published on this topic<= br> > starting from 1998 states that (most) IIDs are 64 bits long?

Yes, I think we have a long tradition of expressing this badly, and = now
is a chance to get it right. It's clear at the point where it's
introduced in RFC4291 that it's a floating boundary:

=C2=A0 "A slightly sophisticated host (but still rather simple) may =C2=A0 =C2=A0additionally be aware of subnet prefix(es) for the link(s) it = is
=C2=A0 =C2=A0attached to, where different addresses may have different valu= es for
=C2=A0 =C2=A0n:

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n bits=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0128-n bits=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-------------------------------+------------------------= ---------+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0subnet prefix=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface ID= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-------------------------------+------------------------= ---------+"

but later in the same document we state that (128-n) =3D=3D 64. That is
inconsistent; what we're trying to do now is fix that inconsistency
in a way that is *also* consistent with running code, SLAAC, and the
newly important privacy issues that require long, unpredictable IIDs.

Ah, I see the disconnect here: you'= re talking about the addressing architecture, and I'm talking about uni= cast addresses assigned to actual networks. Those addresses are called &quo= t;all global unicast addresses except the ones that start with binary 000&q= uot; in 3513 and 4291, and=C2=A0"aggregatable global unicast addresses= " (specifically, 2000::/3) in 2373.

Wha= t I'm saying is that for that latter type of address, the IID length ha= s always been fixed to 64, and should continue to be.
--001a1142f178c950700549a82360-- From nobody Wed Mar 1 01:51:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0941298C0 for ; Wed, 1 Mar 2017 01:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Rco8wFjnwQDv for ; Wed, 1 Mar 2017 01:51:54 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8311298A9 for ; Wed, 1 Mar 2017 01:51:54 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id x75so6355049vke.2 for ; Wed, 01 Mar 2017 01:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pd40y9JgV/txQdRMXaFUgai7ZIBVh1rqaSW58XvN+mE=; b=Wjmz1j9uK6UmFK4uuO5vrsx1kbTIAc6rTXtCBbIegTnfNQTA33zyawmhcpiys86qSz 3CrG5JmvhdI75COgVRYAZ0BWyF/BYz+7e941dNA8y3CiuWZ1H76s0OYUrYMHXeFhHQeC lhYIK9vQuK0AoIbGv2Zi7lUdIuTflXH4/SAl9NqQNoLX+x05o6tY5GiKnSwKIQJRboR5 aq2v8l+A7FmMxQSOV+hjhk/AAIni887c3o5S86Z1W7cXnOo7F4N1UcnB1ISNLmlugM7q r8X9ERPBdzpxHg49mNGzqNffHJVRF3dXlyyG9uxV1cw3Zyv/3C68KH7CBEZand6T3dMZ MDEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pd40y9JgV/txQdRMXaFUgai7ZIBVh1rqaSW58XvN+mE=; b=qyIU5kW4OtVgIfMAmdoA+/oEqD6HWrnkS/Mpma9owtFJfxxIYA2GcikjleuDfQbnGF oN8F3IkBHYHlIRvO+vxGtEB/mAj3B7jWGfeweAvFqIrZ5sAwbUVq26hdKOxu2GO4v8im U1BXlEzkLQZX5+KuF9vr63mgs8Nt/iTOVDztYI73upEZeQUa4dFDRSCTk9diF5QcHPgO L9DmDeZ1XVL3PXwsFxr7r5ZyT3Y0wuKhAauQ1Im2UBGmk4qQW0Gt8HNu0HIJKpymwmHw FMZHeMcvkIn68kBiLSqsSLXbX2r6DokNmSgK89dvigoV5hrfvXC1Mv6r94tvI2kn8zwy Kt4A== X-Gm-Message-State: AMke39lJtvj899rdHQrlb2349R03UlrleW9mMXkEdrofKo4e9McDjZLG26PjJHFA0E/THMhTXujQeXejd9GHDxjW X-Received: by 10.31.150.134 with SMTP id y128mr2898816vkd.102.1488361913341; Wed, 01 Mar 2017 01:51:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 1 Mar 2017 01:51:32 -0800 (PST) In-Reply-To: References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> From: Lorenzo Colitti Date: Wed, 1 Mar 2017 18:51:32 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: David Farmer Content-Type: multipart/alternative; boundary=001a1141d60024ba920549a84307 Archived-At: Cc: james woodyatt , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:51:56 -0000 --001a1141d60024ba920549a84307 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 5:33 AM, David Farmer wrote: > However many OSes also allow configurations other than just /64, is this >>> OK? Is that how RFC4291 should be interpreted? Honestly, I don't read it >>> that way, >>> >> >> IMO the important question is not "should an OS refuse to configure a /65 >> when manually configuring an address". I think the much more important >> questions are, "can the OS assume that it can use the full 64 bits to form >> an IID", and "will this link ever run out of IPv6 addresses". The answers >> to those should be yes and no. >> > > I don't disagree with your answers, and you may not think the manual > config question is important, but others seem too. > FWIW I wouldn't oppose an exception for manually-configured addresses on routers. And you don't have too. But, your saying no one else can ever have a > reason to do that, and I'm not so sure about that. And something on the > other side of the Internet can't make any assumption about what I'm doing > anyway. You are saying it can't be done because the 64 bit boundary is > even more important than CIDR and addresses on the other side of the > Internet are supposed to be opaque. Where as I disagree, CIDR and the > opaqueness of addresses across the Internet are more fundamental properties > than 64 bit boundary. Which is why I say the 64 bit boundary is really a > RECOMMENDATION. And CIDR and the opaqueness of addresses across the > Internet are REQUIREMENTS. > Let's see if there is common ground here. I agree that routers should forward on arbitrary prefix lengths. It's probably reasonable that hosts should not make assumptions about other host's IP addresses (except if they are on the same subnet). But I think a host should be allowed to assume that its own subnet and its own IID are 64 bits long. > > >> Another thing I think we should avoid is to remove the fixed 64 barrier >> and open the door to having this debate again and again, once for every new >> IPv6-over-foo document and once for every new address configuration >> protocol (today we have SLAAC and DHCPv6, who knows what we'll have in the >> future). >> > > Which is why it time to get this right and saying it is now and forever 64 > isn't right. > Do you agree that a fixed boundary is useful or not? For 20 years the standards have guaranteed that 64 bits of IIDs were available to hosts that wanted to use them. If we make that barrier mobile, there will be no guarantee in the standards any more. Who should be allowed to set the boundary? An IPv6-over-foo document? An address configuration technology such as SLAAC? An ISP that wants to charge you $1 for every /128 you use? --001a1141d60024ba920549a84307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 1, 2017 at 5:33 AM, David Farmer <farmer@umn.edu> wrote= :
Howe= ver many OSes also allow configurations other than just /64, is this OK? Is= that how RFC4291 should be interpreted? Honestly, I don't read it that= way,

IMO th= e important question is not "should an OS refuse to configure a /65 wh= en manually configuring an address". I think the much more important q= uestions are, "can the OS assume that it can use the full 64 bits to f= orm an IID", and "will this link ever run out of IPv6 addresses&q= uot;. The answers to those should be yes and no.

I don't disagree with your answers= , and you may not think the manual config question is important, but others= seem too.

FWIW I w= ouldn't oppose an exception for manually-configured addresses on router= s.

And you don't ha= ve too.=C2=A0 But, your saying no one else can ever have a reason to do tha= t, and I'm not so sure about that.=C2=A0 And something on the other sid= e of the Internet can't make any assumption about what I'm doing an= yway.=C2=A0 You are saying it can't be done because the 64 bit boundary= is even more important than CIDR and addresses on the other side of the In= ternet are supposed to be opaque.=C2=A0 Where as I disagree, CIDR and the o= paqueness of addresses across the Internet are more fundamental properties = than 64 bit boundary.=C2=A0 Which is why I say the 64 bit boundary is reall= y a RECOMMENDATION.=C2=A0 And CIDR and the opaqueness of addresses across t= he Internet are REQUIREMENTS.

=
Let's see if there is common ground here. I agree that route= rs should forward on arbitrary prefix lengths. It's probably reasonable= that hosts should not make assumptions about other host's IP addresses= (except if they are on the same subnet). But I think a host should be allo= wed to assume that its own subnet and its own IID are 64 bits long.
=C2=A0
=C2=A0
Another thing I think= we should avoid is to remove the fixed 64 barrier and open the door to hav= ing this debate again and again, once for every new IPv6-over-foo document = and once for every new address configuration protocol (today we have SLAAC = and DHCPv6, who knows what we'll have in the future).
=

Which is why it time to get t= his right and saying it is now and forever 64 isn't right.
<= /div>

Do you agree that a fixed bound= ary is useful or not? For 20 years the standards have guaranteed that 64 bi= ts of IIDs were available to hosts that wanted to use them. If we make that= barrier mobile, there will be no guarantee in the standards any more. Who = should be allowed to set the boundary? An IPv6-over-foo document? An addres= s configuration technology such as SLAAC? An ISP that wants to charge you $= 1 for every /128 you use?
--001a1141d60024ba920549a84307-- From nobody Wed Mar 1 01:59:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F111298CE for ; Wed, 1 Mar 2017 01:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 NYinndCCuWch for ; Wed, 1 Mar 2017 01:59:48 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC2E1298CC for ; Wed, 1 Mar 2017 01:59:48 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id f54so37734823uaa.1 for ; Wed, 01 Mar 2017 01:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OnHC8YMqg9uV41jPDQx7IhqIad4dTJwHCB4Jt6SEVOA=; b=jpE/s3OCSBd3PJvckLpV5rwza0Dj61mVGv//QEotNm7fOvcYCorJBfPHYF/WxUK5l3 m8XtlLN4tHfE1233CvBPquonMaCdai5LZO81MkeSd/pGRuv9uZJFbc1URobpZOLsla97 BApmyUp4D3e8jtpeTqqFcMkFTjBBlX7+bkYaadNx2zav8vAai0JKwwzbcFRsh0/8WoTF KfRDOxnbhXvN+DaFCn3A1BDdH7U49na4t97EOvg9hgSZ8ern6OtxGubtm0Xnu4k2YMhC P3sr9oqdWYHRTVl0pVqs29Vay0sUGCOxnogAfYxyPYrctrV2pR7kV84mVSAAQlbwC+Wm hKMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OnHC8YMqg9uV41jPDQx7IhqIad4dTJwHCB4Jt6SEVOA=; b=gYOILMj9J3lNCScBkJoSgQ3AiNPYfgoaVSLLybOqvTzckDgU0bM9Rv/+8OwOyELALH mQJ8Kev0N2Ahr0SDRpQt8DAQRDIBVhr/ypd3ZqszFpsFQk2nK6RwvqLMSVzqsnr5L//f 0v33H+T0e0dpUNZWGCaIn/nZxLg+yN4MTKZCTfOMjLV9lMC0wm6c8RScF5mNz8qzFYQH DaNlV1iKmaaFaWjlWfaPTfap28I1WQPLFkYCPuQcYnFNqbts7UF0aTcQtFbiGcYQZnni 1fTwiitj3Mt6uV//cmhjTjiPy+8RVIg1Ug/MOSTHMwVdt38rkRxKN05AUABjP5fxqBTv rBTQ== X-Gm-Message-State: AMke39kpvvB8hTHvPNDjeI2SEThMvmua1sbcpvVvfsCF4iiV9wlra8f+Br+hsBOn+eWWRgkk+YvU1aZwrLMIF3s9 X-Received: by 10.176.2.71 with SMTP id 65mr1038892uas.155.1488362387566; Wed, 01 Mar 2017 01:59:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 1 Mar 2017 01:59:26 -0800 (PST) In-Reply-To: <20170301072747.GA10187@nokia.com> References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170301072747.GA10187@nokia.com> From: Lorenzo Colitti Date: Wed, 1 Mar 2017 18:59:26 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Greg Hankins Content-Type: multipart/alternative; boundary=001a11428a3668cc710549a85f4e Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:59:50 -0000 --001a11428a3668cc710549a85f4e Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 4:27 PM, Greg Hankins wrote: > > We can never change our > implementation to be compliant with the proposed text because of the > operational havoc it would create for our customers. It's simply > infeasible > to impose these kind of addressing restrictions. The word "change" is incorrect here, because the standard that was current when Nokia wrote its implementation had pretty much exactly the same requirement. (The reason for that is that *all* past standards have contained this language except for RFC 1884, which specified /80, which won't work in the real world.) Could you reword your position to take into account that fact? --001a11428a3668cc710549a85f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 1, 2017 at 4:27 PM, Greg Hankins <ghankins@mindspring.com> wrote:
We can= never change our
implementation to be compliant with the proposed text because of the
operational havoc it would create for our customers.=C2=A0 It's simply = infeasible
to impose these kind of addressing restrictions.

The word "change" is incorrect here, because the standard t= hat was current when Nokia wrote its implementation had pretty much exactly= the same requirement. (The reason for that is that *all* past standards ha= ve contained this language except for RFC 1884, which specified /80, which = won't work in the real world.)

Could you rewor= d your position to take into account that fact?
--001a11428a3668cc710549a85f4e-- From nobody Wed Mar 1 02:04:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0517412940C for ; Wed, 1 Mar 2017 02:04:47 -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 autolearn_force=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 eNQ1ryaGz_J2 for ; Wed, 1 Mar 2017 02:04:45 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 08F851298CC for ; Wed, 1 Mar 2017 02:04:45 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 846E9E6067; Wed, 1 Mar 2017 11:04:43 +0100 (CET) Date: Wed, 01 Mar 2017 11:04:43 +0100 (CET) Message-Id: <20170301.110443.71171106.sthaug@nethelp.no> To: lorenzo@google.com Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt From: sthaug@nethelp.no In-Reply-To: References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@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 Archived-At: Cc: jhw@google.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:04:47 -0000 > Ah, I see the disconnect here: you're talking about the addressing > architecture, and I'm talking about unicast addresses assigned to actual > networks. Those addresses are called "all global unicast addresses except > the ones that start with binary 000" in 3513 and 4291, and "aggregatable > global unicast addresses" (specifically, 2000::/3) in 2373. > > What I'm saying is that for that latter type of address, the IID length has > always been fixed to 64, and should continue to be. Which, as pointed out repeatedly in this discussion, means ignoring the real world cases of non 64 bit IIDs. Thus I completely disagree with the "should continue to be". Steinar Haug, AS2116 From nobody Wed Mar 1 02:09:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A349129951 for ; Wed, 1 Mar 2017 02:09:29 -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 autolearn_force=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 hgwCekXrZiAU for ; Wed, 1 Mar 2017 02:09:28 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC171294A1 for ; Wed, 1 Mar 2017 02:09:28 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 2C476E6065; Wed, 1 Mar 2017 11:09:27 +0100 (CET) Date: Wed, 01 Mar 2017 11:09:27 +0100 (CET) Message-Id: <20170301.110927.104116623.sthaug@nethelp.no> To: lorenzo@google.com Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt From: sthaug@nethelp.no In-Reply-To: References: 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 Archived-At: Cc: ipv6@ietf.org, jhw@google.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:09:29 -0000 > >> IMO the important question is not "should an OS refuse to configure a /65 > >> when manually configuring an address". I think the much more important > >> questions are, "can the OS assume that it can use the full 64 bits to form > >> an IID", and "will this link ever run out of IPv6 addresses". The answers > >> to those should be yes and no. > >> > > > > I don't disagree with your answers, and you may not think the manual > > config question is important, but others seem too. > > FWIW I wouldn't oppose an exception for manually-configured addresses on > routers. But you would oppose it for hosts? Then I don't think we're any further. Steinar Haug, AS2116 From nobody Wed Mar 1 02:10:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45998129956 for ; Wed, 1 Mar 2017 02:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 OJYrdxEinyPa for ; Wed, 1 Mar 2017 02:10:15 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA95F126D74 for ; Wed, 1 Mar 2017 02:10:14 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id t8so6518497vke.3 for ; Wed, 01 Mar 2017 02:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iHtGWgvFirjTvz1z5Kr1G9vUfflxBnf1iw35t8Hnff0=; b=gdNtMCPUtzAlmbikB1eSugcuDNf3wCXNuHAAjHQ0ZvIMAtgf+fQWM0fTtXbfC+vUXX L9CqnCDcYjnB2pkId4yb0MwHKx4q2kdRTw0ym7UpbE/+48bMM3M5tEasOJBIGuPXHju4 rcJVDa6CEC/OVJjPmjfPkfkjYqL0QwGTeiEYj068/YZlmWEQgjVAxX1QNzWGDYKq7fB+ CHjpeiTIMKVptqIC9SVRUY69tNL0lW3d5f9bi2O1AOpWV8Lf45Y7ENld8psre/lHzWuG SKFFKAeKClYIUwglGAKNkP4oEnXwt5z5+/xcq1j3VQebmP4bqt5yJEVHVofePLCCtDWA JgeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iHtGWgvFirjTvz1z5Kr1G9vUfflxBnf1iw35t8Hnff0=; b=OfSQoepF4DKLAu6vMlF8OF95vL5ULsmt9MzQg7M97pdUaKTIN4qt4zlf92s0lQwTCb yZuO6el/ZJQsLg3sy7iw7tb5chzgqqsPlsmgpxKUwXA7hWaUJWR9m0ysPc7wL9yHARMp Iic8U7emTyUAIf2xfI3jhZTkjlKdiqc6h2u7nyqn1dLPjtslzI7wPSHaZ7qZo4mqr2jT TB9VkGssu1rSaNJ0zNiJCoHWZc5ogQIJTr9VSdpeHQBtinVshq/VYteZpwJpHK7mB+S/ hXtcp88FBdc+6IE4X0CRt/tvhKgnc4W4sFmibTMiPSwd6Ql9l+hdBF4j7r++D78E/rVi eMWQ== X-Gm-Message-State: AMke39nA9JpCrwywTgDuBKJZjtnd+7Zc4rAesm4KP+SJ5ctyQ0ssnf+9S77Q5VBBsegx/+Ke8jGwuflj5Kb5optn X-Received: by 10.31.170.15 with SMTP id t15mr20498vke.6.1488363013824; Wed, 01 Mar 2017 02:10:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 1 Mar 2017 02:09:52 -0800 (PST) In-Reply-To: <20170301.110443.71171106.sthaug@nethelp.no> References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> From: Lorenzo Colitti Date: Wed, 1 Mar 2017 19:09:52 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=001a11432250bcd24d0549a8841a Archived-At: Cc: James Woodyatt , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:10:16 -0000 --001a11432250bcd24d0549a8841a Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 7:04 PM, wrote: > Which, as pointed out repeatedly in this discussion, means ignoring > the real world cases of non 64 bit IIDs. Thus I completely disagree > with the "should continue to be". > Ok, I'll bite. In all seriousness, what are the concrete use cases of limiting subnet sizes? So far I've heard: - "I only need 3 addresses" (but not "I only need 3 addresses and here's why I can't accept 2^64 instead of 3") - ND exhaustion attacks What else? You don't have to list them here, a pointer to a previous message will do. --001a11432250bcd24d0549a8841a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 1, 2017 at 7:04 PM, <sthaug@nethelp.no> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Which, as pointed out repeatedly in this disc= ussion, means ignoring
the real world cases of non 64 bit IIDs. Thus I completely disagree
with the "should continue to be".

=
Ok, I'll bite. In all seriousness, what are the concrete use cases= of limiting subnet sizes? So far I've heard:
  • "I= only need 3 addresses" (but not "I only need 3 addresses and her= e's why I can't accept 2^64 instead of 3")
  • ND exha= ustion attacks
What else? You don't have to list th= em here, a pointer to a previous message will do.
--001a11432250bcd24d0549a8841a-- From nobody Wed Mar 1 02:13:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6B7126D74 for ; Wed, 1 Mar 2017 02:13:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 wPfL0eK0Hj8s for ; Wed, 1 Mar 2017 02:13:39 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCB312994F for ; Wed, 1 Mar 2017 02:13:39 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id 72so38020409uaf.3 for ; Wed, 01 Mar 2017 02:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HRH3riJG1AKskHkMocF5Hf4du0evPIvnxa+4smi+Ybs=; b=QhKU4geSHu2jm11WmJWx5EHfbykzSW71nXaV8Ds9LpoRnRUt2lQGOoeuFPar5vIDE/ Z8g/29cG6SQv464GUo5ARl9/ewRYoncUP8PKbqv6O1uGjRsmEfxJccAv+hnGlxDWqHu+ GPlsVltt/xwZCoVcSXoVnIXCzlB7PNQOPJjzrtRBdtNoHAuwM8bHKF+8h2FEmvStYi+n 58Hqhs1FAWmBaikd3EGTmQ6BGSSMdnXsRfAR0Xna3+VxPVm00LJWtL2tF70Hf+2/h86r w/EJ4kAhVuAHwMeAjW+jny2z44YYw/Su+1cN8tQADktEjTLZeE4DVrHF6DdBVKBxCHIG DoNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HRH3riJG1AKskHkMocF5Hf4du0evPIvnxa+4smi+Ybs=; b=cLziW+UlNxjJS4dfyieCu2HVrmnvtaP1gwoJrQPsl9PfvPr4ZV1wnwZ0mVOwTZ6Xn0 TkviSgVeMS+uL80lHSb+KLJcZUwwKZMVDjgcZwvk+GzEN3NU8KsBwSL6W1PbHRchHGHk 0tlJwj7xzDILR1/sM8xeZPG579pnpmTgxl1PYMwIrmx5JX3qFAIUYO8gN0n3GlyybB4V mCwZ3vunj2ywI0xgJ9tb8EDJvYLHTZW0pyDZM2sqUvEW++K/T+GZjYqEKBghhVomEssT p0ecIhY2gFJAtmwNDpRHOyrb+Vzv2xvoAloxNC8dSb8zM/Zu9uDVwhLq/85NxrqUV29J 4Q3w== X-Gm-Message-State: AMke39n76fca8xRmZkMn49WAClqkua1INRkQpVmmSS0qTn+mbnegL8dPS5kpulP9AvObO5ogEM+dJ8g7mmuPjnZF X-Received: by 10.159.56.193 with SMTP id w1mr3620619uaf.72.1488363218210; Wed, 01 Mar 2017 02:13:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 1 Mar 2017 02:13:17 -0800 (PST) In-Reply-To: <20170301.110927.104116623.sthaug@nethelp.no> References: <20170301.110927.104116623.sthaug@nethelp.no> From: Lorenzo Colitti Date: Wed, 1 Mar 2017 19:13:17 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=f403045f4162eb651c0549a89015 Archived-At: Cc: IETF IPv6 Mailing List , James Woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:13:40 -0000 --f403045f4162eb651c0549a89015 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 7:09 PM, wrote: > > FWIW I wouldn't oppose an exception for manually-configured addresses on > > routers. > > But you would oppose it for hosts? Then I don't think we're any > further. > Not sure about that. I suppose it also depends on what manual means. If it's literally just operators configuring them manually by editing configuration files that's probably fine, but that's not what you want to do, is it? --f403045f4162eb651c0549a89015 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 1, 2017 at 7:09 PM, <sthaug@nethelp.no> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> FWIW I wouldn't opp= ose an exception for manually-configured addresses on
> routers.

But you would oppose it for hosts? Then I don't think we're = any
further.

Not sure about that. I suppose= it also depends on what manual means. If it's literally just operators= configuring them manually by editing configuration files that's probab= ly fine, but that's not what you want to do, is it?
--f403045f4162eb651c0549a89015-- From nobody Wed Mar 1 02:19:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A587128824 for ; Wed, 1 Mar 2017 02:19:38 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GD4w-pfvovUo for ; Wed, 1 Mar 2017 02:19:36 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCE512940C for ; Wed, 1 Mar 2017 02:19:36 -0800 (PST) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v21AJRm7081753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2017 10:19:27 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local Message-ID: <58B6A02E.50501@foobar.org> Date: Wed, 01 Mar 2017 10:19:26 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.10 (Macintosh/20170123) MIME-Version: 1.0 To: Lorenzo Colitti Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:19:38 -0000 Lorenzo Colitti wrote: > * "I only need 3 addresses" (but not "I only need 3 addresses and > here's why I can't accept 2^64 instead of 3") > * ND exhaustion attacks > > What else? You don't have to list them here, a pointer to a previous > message will do. * established practice since the 1990s, suggesting that any attempt to un-ring this particular bell is likely not to succeed. Nick From nobody Wed Mar 1 02:28:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2E2129970 for ; Wed, 1 Mar 2017 02:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 euCt7pXqNcNy for ; Wed, 1 Mar 2017 02:27:58 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDB712996B for ; Wed, 1 Mar 2017 02:27:57 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id d1so28062808ywd.2 for ; Wed, 01 Mar 2017 02:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e8h0xLK1joMnKekrwX3hxY7Pev3nnwBXT7P+jBf4l9M=; b=KctBhqvANxP7Siox544rznd3ufzl0Zi6jt7Mc+z4zk2adsXZGy58r9cqFMeNqawTZy A8y2qe7gEAlTVAtDSE/ocAMcJh0pHtZyDBGBHzZHpLYORhG7MSUnZNi1sNVF0MY0v34u WyoYitLPy1FjdcaX2vk/qwowdyiDhZeqhh2QHqGG/qz5QIe1wdkz9mT5tN+TDNyR+r5J TIjrs9yTPsVUgzdSjl/6v1KohaGEaScEgM8fnaTovQhRrDp4Tzb9Hqh8n/ra8zjWwDnN X5FRzzNysdCtusvKC+qDTLLIBcxC2AeWnyOClKdznDiFwhJz8ubAP+0fkIQk+VqMvE/9 oirQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e8h0xLK1joMnKekrwX3hxY7Pev3nnwBXT7P+jBf4l9M=; b=keRBk63VX1E5SpZW40yH0bnZHVSgFe+c7QAoUa+OQ0W3Td6Cc/M0B33sb5rcC8oLm3 zf0UR3J5O8PKIT5Z4RESp67wH+K7orgbtXdlxBxDNZ3dZ1RCW87HXPh9if2fR0iAnMGl IiPfj7TTRh9eFy0shHOBCllKFYYsassGU9CTr3c1/oTGR3ZkgXu/wiMvzzowi8TFYMnr 8X/lZhhMtOsrPKlViOaawvJLt9YvQ/Xb8CGWa1eFw33JbGRX0hULFaHwm9M2L1U8aTA0 IOwO7lELJ2YL77UutF79p3biZcoZXUD1T3hnEW+2Y9d5TAwc2vzoATLEKktqQycb5eZy v6Aw== X-Gm-Message-State: AMke39m93BhYWxtyRsbOMTA/7TK7luS7QZDFULKPpcizZjIgXQw4i8YyLOpcuCc7f5cm3f6zegTmsl8eZfUffNvT X-Received: by 10.37.17.65 with SMTP id 62mr898149ybr.8.1488364076929; Wed, 01 Mar 2017 02:27:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.4 with HTTP; Wed, 1 Mar 2017 02:27:36 -0800 (PST) In-Reply-To: <90F2B6EE-E8DB-4204-95DD-712E1EE828E8@employees.org> References: <90F2B6EE-E8DB-4204-95DD-712E1EE828E8@employees.org> From: Erik Kline Date: Wed, 1 Mar 2017 19:27:36 +0900 Message-ID: Subject: Re: 6MAN IETF98 Call for agenda items To: Ole Troan Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113e612620bfca0549a8c451" Archived-At: Cc: 6man WG , 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:27:59 -0000 --001a113e612620bfca0549a8c451 Content-Type: multipart/alternative; boundary=001a113e61261a856b0549a8c446 --001a113e61261a856b0549a8c446 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole, It's on me to get a -02 of PIO-X written and uploaded. Might it be possible to get 5 minutes on that? -ek On 27 February 2017 at 06:16, wrote: > The 6MAN chairs are planning the meeting in Chicago at IETF98. > > If you have a draft you would like to discuss, please send your request > for agenda time to the 6man chairs. Please include in the request, the > title of the presentation, file name of the draft, the speaker's name (an= d > email), and how much time you would like. > > We will prioritise drafts that are working group items and drafts that > have been actively discussed on the list. > > We expect at least half of each talk=E2=80=99s presentation time to be us= ed for > open discussion, > please plan your presentation accordingly. > > New drafts not discussed on the mailing list prior to the meeting, > or drafts that do not appear to have support from the working group are > unlikely to get time at the meeting. > > Please have agenda items to us by 2017-03-15. > > Regards, > > Bob & Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --001a113e61261a856b0549a8c446 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ole,

It's on me to get a -02 of PIO= -X written and uploaded.=C2=A0 Might it be possible to get 5 minutes on tha= t?

-ek

<= div class=3D"gmail_quote">On 27 February 2017 at 06:16, = <otroan@employ= ees.org> wrote:
The 6MAN ch= airs are planning the meeting in Chicago at IETF98.

If you have a draft you would like to discuss, please send your request for= agenda time to the 6man chairs.=C2=A0 =C2=A0Please include in the request,= the title of the presentation, file name of the draft, the speaker's n= ame (and email), and how much time you would like.

We will prioritise drafts that are working group items and drafts that have= been actively discussed on the list.

We expect at least half of each talk=E2=80=99s presentation time to be used= for open discussion,
please plan your presentation accordingly.

New drafts not discussed on the mailing list prior to the meeting,
or drafts that do not appear to have support from the working group are unl= ikely to get time at the meeting.

Please have agenda items to us by 2017-03-15.

Regards,

Bob & Ole

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


--001a113e61261a856b0549a8c446-- --001a113e612620bfca0549a8c451 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgBTRNa9xkJj+/Kc2xOpEyZuHe35fk+yc6 d4PoN0zQPU4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzAx MTAyNzU3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAEmFmhl4esVuIpuXQuGlrbhk9frknXwOr1GXXIe+GYUu0E19LVHu UztmgMugekLid+WMEEk0t/gx8FfXzsvAlQzJwfCdy+JvsEtJ1SXhel/zVyUlCj2xD7uafYv1enGS H909di/swrCqzXduKuJW5tUh57f7J2aJjLICjjKOnryRgL2HeJfUaRucX+k6pCGxXG3pb+Jr3scu jhUYeCl/oNjj741rRuUydURPSwPOqXATHfzwxgbrst+WzRYwuxN+/XXRwnpYZaBGgvQ46UpZWWY/ 2mq8LiUcoyU0qmvNsOE5ZtOyRA1TIjjGM8VKn1c6nlBkTUE4yuAQqaeO0y/N31M= --001a113e612620bfca0549a8c451-- From nobody Wed Mar 1 02:40:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E641294F2; Wed, 1 Mar 2017 02:40:02 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 4zoUpyFWVsl8; Wed, 1 Mar 2017 02:40:00 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A41301294A1; Wed, 1 Mar 2017 02:40:00 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 01 Mar 2017 10:40:00 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id AD2B3D788F; Wed, 1 Mar 2017 02:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=mqmelMPb9IIE8SqnvmPn1dE7tmM=; b= okKeUjMtXRI/C+yRDn/K3mlgApl2/Ga5iv7cTcTYdmUY/8cflR6Xh2/ktGJTXVQE WBDmBS1wfeClu/JjV0/JynM+h7Y9Umu5aWn/5npCRvJq/QZc4QvL/q9kq4OX9G5p I4jKGwv2Wp3AOAbmB3KScD4jxixqANe0IwRP8ZVOLyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=JgCw2aGQ/WfrZvf6CrRdXbT QuA1h8Ax/zoniCm9mVTOjMttpG20KF27vgcxW61sP3P764zmJ4BIHoArYmaQTS31 3kWK+RrttMGz2U238ZQhMjLPWrKxXkycMVlmuQmyzvRVS3mQWT+SbGBeNupQZYb+ efQ6r5yA6fNEQvWOfhPQ= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 81E3AD788A; Wed, 1 Mar 2017 02:39:59 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 080C391921D1; Wed, 1 Mar 2017 11:39:58 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_524F81B4-5A0A-4DEE-BFBD-11966981FE62"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: 6MAN IETF98 Call for agenda items Date: Wed, 1 Mar 2017 11:39:57 +0100 In-Reply-To: To: Erik Kline References: <90F2B6EE-E8DB-4204-95DD-712E1EE828E8@employees.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:40:02 -0000 --Apple-Mail=_524F81B4-5A0A-4DEE-BFBD-11966981FE62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Erik, > It's on me to get a -02 of PIO-X written and uploaded. Might it be = possible to get 5 minutes on that? Thank you. To get any real work done on it, 5 minutes is probably too = short. Best regards, Ole >=20 > -ek >=20 > On 27 February 2017 at 06:16, wrote: > The 6MAN chairs are planning the meeting in Chicago at IETF98. >=20 > If you have a draft you would like to discuss, please send your = request for agenda time to the 6man chairs. Please include in the = request, the title of the presentation, file name of the draft, the = speaker's name (and email), and how much time you would like. >=20 > We will prioritise drafts that are working group items and drafts that = have been actively discussed on the list. >=20 > We expect at least half of each talk=E2=80=99s presentation time to be = used for open discussion, > please plan your presentation accordingly. >=20 > New drafts not discussed on the mailing list prior to the meeting, > or drafts that do not appear to have support from the working group = are unlikely to get time at the meeting. >=20 > Please have agenda items to us by 2017-03-15. >=20 > Regards, >=20 > Bob & Ole >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 --Apple-Mail=_524F81B4-5A0A-4DEE-BFBD-11966981FE62 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYtqT9AAoJEL7aWKiYQt92VVkP/3LhnfKHfBfuh9017TgaBgW7 oE9gdpxvLPKFc1JxpVI/bwX3kmN0/oidcxe4nCUfYspCGGPSDX6y47v40ENuzLSM 9FGYqbGWq0slIM6NohPc+7OkwbJAKiW7+wPRNWsyGyIgVeKG8ujk4y0dafG4j/EP csS1o+6DFJsDcQCBuqbcgJ/OPq+CY3zsk6wsDgN/eStfMdI6M41OD2uiM0C8o+5W QBpEit3NldAS08FmcQ2HdNk29oKkgDFVskL7+KWgUpCqsZKDn/xxWyVgTGYb94Dm FiGqajpBst/loWq+VX/YqRitAQwSXdDUTYNQ2XhfnErU4/RDRdNid58MB7Jz9WE1 vNLrqGbiLxSeTEjVDB7Hu+rR58Re6EldJVvL7FCFsuSZ82oqdAR+jfBz1b0cSKQb w1ANIp3xcqDlynArbSXP38PRaFxAQiB8UZXykHNfdFurHkG6qFtU3bLtRh8tcb4P RlflgGbRQioRJdjcZiamkaj+ip+C3QbpkyLYXomfHfwKJcwy/poJ1GBfLs7AW2j9 cmP+HvnemSB/JFYAS/WErc8fAe+f28cByrozHOnYML3KPD1EwmI+8G8RVBjWfeB2 DryAdj5EPV5wBhCdXkPK/PcYw2GZWAGFVEy8eBICz0vrDPslQzz8xouRd/87e2cf k3s/Bk2b7M4JcHq8hvXl =QNqo -----END PGP SIGNATURE----- --Apple-Mail=_524F81B4-5A0A-4DEE-BFBD-11966981FE62-- From nobody Wed Mar 1 02:45:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A22129964 for ; Wed, 1 Mar 2017 02:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=ghankins@mindspring.com header.d=mindspring.com 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 QeOHxPpv9Rt8 for ; Wed, 1 Mar 2017 02:45:14 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FCE1294F4 for ; Wed, 1 Mar 2017 02:45:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QTfsr5jVIvK5i2pzSfcR0qN8kNrRaZ0OcXY9yRKGALHIyqaFn0XXVCl0V6c/iebL; h=X-Authentication-Warning:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:X-ELNK-Trace:X-Originating-IP; Received: from [66.201.62.254] (helo=doom.twoguys.org) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1cj1kp-0006qC-8v; Wed, 01 Mar 2017 05:45:08 -0500 Received: from doom.twoguys.org (localhost.twoguys.org [127.0.0.1]) by doom.twoguys.org (8.14.4/8.12.11) with ESMTP id v21AiwLt015248; Wed, 1 Mar 2017 05:44:58 -0500 Received: (from ghankins@localhost) by doom.twoguys.org (8.14.4/8.14.4/Submit) id v21AivdI015244; Wed, 1 Mar 2017 05:44:57 -0500 X-Authentication-Warning: doom.twoguys.org: ghankins set sender to ghankins@mindspring.com using -f Date: Wed, 1 Mar 2017 05:44:57 -0500 From: Greg Hankins To: Lorenzo Colitti Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Message-ID: <20170301104457.GA14420@nokia.com> References: <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170301072747.GA10187@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-ELNK-Trace: 176464c9115cf5b39c7f779228e2f6aeda0071232e20db4dbd5bef21beed6ab1afeda6acc077ee9b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.201.62.254 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:45:16 -0000 On Wed, Mar 01, 2017 at 06:59:26PM +0900, Lorenzo Colitti wrote: On Wed, Mar 1, 2017 at 4:27 PM, Greg Hankins wrote: >> We can never change our >> implementation to be compliant with the proposed text because of the >> operational havoc it would create for our customers. It's simply >> infeasible >> to impose these kind of addressing restrictions. > >The word "change" is incorrect here, because the standard that was current >when Nokia wrote its implementation had pretty much exactly the same >requirement. (The reason for that is that *all* past standards have >contained this language except for RFC 1884, which specified /80, which >won't work in the real world.) > >Could you reword your position to take into account that fact? Call it whatever you want, the point again is that we have customers who have deployed whatever addressing architecture meets their requirements, and we can't force them to change it. It's their network and their address space. You are correct that other standards had the same requirement, which my current and all of my former employer's* implementations also ignored for the same reasons that have been mentioned. This is a good opportunity for the -bis revision to reflect the state of operational deployments that have proven the assumptions in the original standard to be impractical. Is anyone aware of any implementations that comply with this requirement? Greg * Riverstone, Force10, Brocade -- Greg Hankins From nobody Wed Mar 1 02:58:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678611294BE for ; Wed, 1 Mar 2017 02:58:23 -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 autolearn_force=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 TlXwdNP1w8nH for ; Wed, 1 Mar 2017 02:58:21 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BBC129495 for ; Wed, 1 Mar 2017 02:58:21 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 10E65E6065; Wed, 1 Mar 2017 11:58:20 +0100 (CET) Date: Wed, 01 Mar 2017 11:58:19 +0100 (CET) Message-Id: <20170301.115819.78792371.sthaug@nethelp.no> To: lorenzo@google.com Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt From: sthaug@nethelp.no In-Reply-To: References: <20170301.110927.104116623.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org, jhw@google.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:58:23 -0000 > > > FWIW I wouldn't oppose an exception for manually-configured addresses on > > > routers. > > > > But you would oppose it for hosts? Then I don't think we're any > > further. > > > > Not sure about that. I suppose it also depends on what manual means. If > it's literally just operators configuring them manually by editing > configuration files that's probably fine, but that's not what you want to > do, is it? Yes, that is exactly what I want to do. I want to be able to use the ifconfig command to set an IPv6 address with a netmask different from 64, and to have the corresponding config file entry take effect when the box is booted or the service restarted. Steinar Haug, AS2116 From nobody Wed Mar 1 02:58:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F2B1298D3 for ; Wed, 1 Mar 2017 02:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 7A5feRv8bj9d for ; Wed, 1 Mar 2017 02:58:54 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 91B101298D0 for ; Wed, 1 Mar 2017 02:58:54 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 01 Mar 2017 10:58:54 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 54997D788D; Wed, 1 Mar 2017 02:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=5OU3MpwBbQ0PAgUI1ND/iEiJiCU=; b= Em6r6kxAOOwoiSGnwVVm094XCUbB5hRloorBmEWL9uhxoazOcplV/N1oAVqhDSra y++tlCmF1hdw9b5OrfmQqa5Hq4gbEzPJf+ztyrk9ZRT/+i/+4JxMOBThk1Mg/GxJ P8LX5PHWSyRU/ZzBERyn9URM4PCMRlUdbu1sQP4ILsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=dQRwxxlQ29ZKMx8XE2oqG7+ NcI+8MRF3JICaZNB4CqCKkhtwE3OKogHj1vdNrG5QEVLbOebT4kJnXoJ/UJG4paC oFZZOPtFvatUjJobm/TXE0XXYEpvXK2qUxgE+DmdADw7+g8e/mGzOKCZnC2njfTJ tUrUCkiyLaL+cwNdY7/4= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id D4418D788A; Wed, 1 Mar 2017 02:58:53 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 47B9A9198679; Wed, 1 Mar 2017 11:58:52 +0100 (CET) From: otroan@employees.org Message-Id: <6F4AE5AF-D626-471D-B853-F4C004B19620@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_2F7BC571-A93A-4BFE-BC50-4468B31C2779"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Date: Wed, 1 Mar 2017 11:58:51 +0100 In-Reply-To: <20170301104457.GA14420@nokia.com> To: Greg Hankins References: <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170301072747.GA10187@nokia.com> <20170301104457.GA14420@nokia.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:58:56 -0000 --Apple-Mail=_2F7BC571-A93A-4BFE-BC50-4468B31C2779 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greg, >>> We can never change our >>> implementation to be compliant with the proposed text because of the >>> operational havoc it would create for our customers. It's simply >>> infeasible >>> to impose these kind of addressing restrictions. >>=20 >> The word "change" is incorrect here, because the standard that was = current >> when Nokia wrote its implementation had pretty much exactly the same >> requirement. (The reason for that is that *all* past standards have >> contained this language except for RFC 1884, which specified /80, = which >> won't work in the real world.) >>=20 >> Could you reword your position to take into account that fact? >=20 > Call it whatever you want, the point again is that we have customers = who have > deployed whatever addressing architecture meets their requirements, = and we > can't force them to change it. It's their network and their address = space. >=20 > You are correct that other standards had the same requirement, which = my > current and all of my former employer's* implementations also ignored = for > the same reasons that have been mentioned. This is a good opportunity > for the -bis revision to reflect the state of operational deployments = that > have proven the assumptions in the original standard to be = impractical. >=20 > Is anyone aware of any implementations that comply with this = requirement? There might be some misunderstanding here. This last call is about a document requested to be elevated from draft = standard (deprecated) to Internet standard. This document cannot be elevated to Internet standard if we added a = change that would affect interoperability or require changes in = implementations. What we are arguing over is finding text that balances between ensuring = that implementations do the right thing (support all prefix lengths) and = allowing existing (SLAAC, NPT66, ILNP) and new mechanisms that assume = the 64 bit boundary to exist / be invented. Combine that with trying to = enforce the policy boundary of giving half the bits to the network and = the other half of bits to the users. Best regards, Ole --Apple-Mail=_2F7BC571-A93A-4BFE-BC50-4468B31C2779 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYtqlsAAoJEL7aWKiYQt921KUP/0+6/Z588TqAXh8Xr69O3Lho Az67xtOiLHKqSOR7TijoLS5Ih/8zhXQ378SUsjNLtwkQjU5s0iJofUvd+YiOx4Y3 4LE6lLtc1NVdGYb2ZKJtCMyh1jjDSvHo3xIkxNPF1urJDztImN4qG76rYW1JpqgC d4ILSz3k/f6Ywu7ftcw5+Co/UufdPB9wCAICn2pZPlMMcx4oxrwbfDS64Mo1GUCo KXYTxMRKi/+Bp/y8s8dCcqjghbqcVhRnjqZaYgi6yb41D71P2ntBTOp595PZCPwZ 2nftib0g+L5glsHx1sB5y3vbJUvTY5s4BAZQpjXj7PBTeDB+EXLEe7C+1CPbKrdG aSM8p6VhU57vHnpzmfKYTD5DuYNYE6DUnRQEn4v5NP+0IK+STsAFWcU+m0IbhUlT pGUNd1I25sI5nHi3WiVbLdU2fsWK5T+34q2dNAtRwAkYT6oe/jhqeGG6DKPT4Z8V uuxcMAehPk8VHCCc37hiNS66gFKn0F+T5OxlguYMqpZcmucMFjTOgqe/jBOMSF8K FxrA6cKb/Cbmn1iKlPAr0vjGBbuu7RynfM3FlvFst8sas0aTTSDngM2TSBkud5TP rl3QQdBaPuSLv6ly7Ty4rJLIgw7LOrnX/MKHR5C3/xrU2cvNLOBueU7hXvQhZWIU 1PeD0npSXtNQQeYDdHdc =zOcH -----END PGP SIGNATURE----- --Apple-Mail=_2F7BC571-A93A-4BFE-BC50-4468B31C2779-- From nobody Wed Mar 1 03:04:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EB2129495 for ; Wed, 1 Mar 2017 03:04:06 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 soDD0IkUORUD for ; Wed, 1 Mar 2017 03:04:04 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D5D071293DF for ; Wed, 1 Mar 2017 03:04:04 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 01 Mar 2017 11:04:04 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 856CED788B; Wed, 1 Mar 2017 03:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=64DFbhTtgJtNsB4ioLplK97mFa4=; b= UkzMHLVLlE+yvq9d0W1Hi6b6MuiyQejgreoHXLx36rffEMV2Dd3p13/mkEd/DVa5 SdlbvACZd6MpDodhQ8kPAieMtvpikuYrBbY4SMlRN+Dgl/vkVnHEdRAJSSmAVtIV JkdRQ6HSXVR3EWowB7OubbfNg3cZ64BOoFbRAhP2YNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=Tutgfcfo1hxfsLcQYt9+8Hy hNS07Blur/6jpWCVPLjpU8yki75WQwtf8s/wQKqRDRe7nv69gEzp+iNLVGwkM38k 1GfckUZdtQyO6D6VDbQbQn2tx2J4yjFT9mGjuwYe4ksWXn7ZVHPQUEISV0qXuzJ0 1MQaG+C7djqP1gopuFdQ= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 4F08FD788A; Wed, 1 Mar 2017 03:04:04 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BD326919A0C2; Wed, 1 Mar 2017 12:04:02 +0100 (CET) From: otroan@employees.org Message-Id: <4E8CA778-9DFA-4B4E-88B1-ED9DF1AB982E@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_94390720-1F50-4F4C-A135-7A4DCF397204"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Date: Wed, 1 Mar 2017 12:04:02 +0100 In-Reply-To: <20170301.115819.78792371.sthaug@nethelp.no> To: sthaug@nethelp.no References: <20170301.110927.104116623.sthaug@nethelp.no> <20170301.115819.78792371.sthaug@nethelp.no> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: jhw@google.com, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 11:04:06 -0000 --Apple-Mail=_94390720-1F50-4F4C-A135-7A4DCF397204 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 1 Mar 2017, at 11:58, sthaug@nethelp.no wrote: >=20 >>>> FWIW I wouldn't oppose an exception for manually-configured = addresses on >>>> routers. >>>=20 >>> But you would oppose it for hosts? Then I don't think we're any >>> further. >>>=20 >>=20 >> Not sure about that. I suppose it also depends on what manual means. = If >> it's literally just operators configuring them manually by editing >> configuration files that's probably fine, but that's not what you = want to >> do, is it? >=20 > Yes, that is exactly what I want to do. I want to be able to use the > ifconfig command to set an IPv6 address with a netmask different from > 64, and to have the corresponding config file entry take effect when > the box is booted or the service restarted. And that clearly always have been permitted. E.g. how would you = otherwise configure a /128 loopback. I agree that current text have always been at best ambiguous on this = point. Best regards, Ole --Apple-Mail=_94390720-1F50-4F4C-A135-7A4DCF397204 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYtqqiAAoJEL7aWKiYQt924QoP/j8C5QS8u+8brs7sr5PqQLRb LFRFqx9V7zxh0XdOJoNOpzXIxttd6IanOHIQMEFPjpSdrWnk0WYhMwW/8NaHb+f+ LAVaRxaFCsWJAhHPf+7tlqaKZCBrePlebymf28Pf3fedN0a3cYN2y0VXayWD+Suw nJxEv4vw6B6AVVTu5Q7dfOz0awYQKF1KkoEpRtZiq+UapYjc+D+a0/pqHHH4R4xJ KTOuh6xgWJZjEVGgPeFoPp2dLqcCv12tCmdgAwsAuNuEPEYpQpREHfFoGcCJeKBU BN9a535Vtn+NTpOftaUa3z+0YvZUUTMfFRnyptWLniLNaG4g7clpynEdd+0Nl4fl AxlJfC5azrvO+2HjwSTKDVx5irVMiUCww/bBae66o2tWqhqRIqKbWf+vyMj/i/e3 O2PeBpfPpoQWE4EapkEN4ahUmPgPVGDq7aEXAcwmrNipOJDVh5XiktXDg4ibBm2V DisRi0CAS2RrIH/viXKKLvPpOyvZ87FZ+va0/+LMag74ndCDhoxWatOxefFKNw5K FLH0aqilJ5P7saURfV8ZSQcOR+n9WGj1coB2VKyXqUREm4eGSvTKtB+RByc0Lris d02ARsesq+C6Nnn5/os5ZO6ycIA/4P5iRXJlq9YMUoY/sXlN5Y58ZkOz9FAx4kpS 92iT6e7PhxqyFW+EGaWs =IQ2L -----END PGP SIGNATURE----- --Apple-Mail=_94390720-1F50-4F4C-A135-7A4DCF397204-- From nobody Wed Mar 1 03:23:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F666129980 for ; Wed, 1 Mar 2017 03:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=danrl.com 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 l3kB1qSIc2bj for ; Wed, 1 Mar 2017 03:23:38 -0800 (PST) Received: from mx.cakelie.net (mx.cakelie.net [45.76.39.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA09129512 for ; Wed, 1 Mar 2017 03:23:38 -0800 (PST) Received: from p20030086461bf7fd05d36bdaa28f7d94.dip0.t-ipconnect.de (p20030086461BF7FD05D36BDAA28F7D94.dip0.t-ipconnect.de [IPv6:2003:86:461b:f7fd:5d3:6bda:a28f:7d94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.cakelie.net (Postfix) with ESMTPSA id 0F794BE809; Wed, 1 Mar 2017 12:23:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=danrl.com; s=default; t=1488367412; bh=aieP8wsq8WVIE37Jf+obDC83y1j9L3VkzddKteTeax0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DWPwqPWhN7m/nK053L8YD2QlLpmBvIoWSWuHKS+s70ziI6Q03oqu6Y5tSV3xQlxdi C35qnh7GBUzHyB36F7FT5vMyB5N9+lEX4PhbCAz6XuCLIBNWNGYFYBke+dPS/xEFtj bZXbfEq1ZFShqdiLVtbBkaTPoe8Q0ZjIlqqfOB5RuICMGmz9nTWJu7/2nudaOGMQAh k+S5jw6nsk99i9qb5tpISXgb1vjwtuT2ZuEGR4DFa1aAm/vCkmW4d3lsDI9MTVUbvW AkCte0Aw1ryOUC/2gokJqKedvzkMbiHgTjXdNCoa88A+ZVz41Rd9KrCMnOvVKCpWZq 6JdPolHUNLmXA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt From: =?utf-8?Q?Dan_L=C3=BCdtke?= In-Reply-To: Date: Wed, 1 Mar 2017 12:23:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92160C59-79EC-4EB0-BFD5-69697A5E1306@danrl.com> References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 11:23:39 -0000 > On 28 Feb 2017, at 13:04, Alexandre Petrescu = wrote: >=20 > Finally, there is no advice of what bits to put between fe80:: and a > 64bit the Interface ID - zeros or ones? linux says it's a fe80::/64 = and > IIRC BSD says it's a fe80::/10. The routing entries based on that can > make for interop problems. I think there is advice. As I understand, /10 is reserved but only /64 = is specified. RFC 4291 IP Version 6 Addressing Architecture 2.5.6. Link-Local IPv6 Unicast Addresses Link-Local addresses are for use on a single link. Link-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ Cheers, Dan= From nobody Wed Mar 1 05:45:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BD01295F3 for ; Wed, 1 Mar 2017 05:45:07 -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 autolearn_force=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 TTcNuSvplyp7 for ; Wed, 1 Mar 2017 05:45:05 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC50129491 for ; Wed, 1 Mar 2017 05:45:05 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 5EF35E6065; Wed, 1 Mar 2017 14:45:03 +0100 (CET) Date: Wed, 01 Mar 2017 14:45:03 +0100 (CET) Message-Id: <20170301.144503.74665389.sthaug@nethelp.no> To: ghankins@mindspring.com Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt From: sthaug@nethelp.no In-Reply-To: <20170301104457.GA14420@nokia.com> References: <20170301072747.GA10187@nokia.com> <20170301104457.GA14420@nokia.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 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 13:45:07 -0000 > Call it whatever you want, the point again is that we have customers who have > deployed whatever addressing architecture meets their requirements, and we > can't force them to change it. It's their network and their address space. > > You are correct that other standards had the same requirement, which my > current and all of my former employer's* implementations also ignored for > the same reasons that have been mentioned. And will presumably continue to do so, because customers will demand this functionality in the form of RFPs etc. We are certainly planning demand this in RFPs. Steinar Haug, AS2116 From nobody Wed Mar 1 06:36:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B083112954C for ; Wed, 1 Mar 2017 06:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 8LM2VjaqLCei for ; Wed, 1 Mar 2017 06:36:37 -0800 (PST) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F321294EC for ; Wed, 1 Mar 2017 06:36:36 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 67C5E5BB for ; Wed, 1 Mar 2017 14:36:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EdoXm991_GH for ; Wed, 1 Mar 2017 08:36:36 -0600 (CST) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 1DCB7CCF for ; Wed, 1 Mar 2017 08:36:36 -0600 (CST) Received: by mail-vk0-f70.google.com with SMTP id 130so7347474vkn.2 for ; Wed, 01 Mar 2017 06:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xx5NrV8mdxh6yGMe/XTGrHNegztQCox6n9IKW6GXcPQ=; b=n+uJXGUdf4+21l1ScVcxUsxkNg3xgjQaRiU+Y7EObkFbLmZn8rzdyhxEozWwlTFv2N kNBbICyKmkdL0Nr28MJawD0kdd+I/PsNX9ZETT/1lQRS/bBsFLUA8Yw16VLqU7A6xpXu V5qLC1j7VQ0Ges45tva0NjByOLeEEYu4B0cR20Vh7qxCCoS3REdmb286tysCsFxpopn3 Q/K6DEjIiHCSIfihzTdigtrvK9VzssH9M6BT4E4p8IJ0tY+ZsTeBqQeMa152HtlBv7Io T2/g94/VX7e5XPOiVXrAlbb8+Ihv0yV9iRFGK5s39zY+nSmqq1B+ZtD3j0Pn1xnT8JFN DhHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xx5NrV8mdxh6yGMe/XTGrHNegztQCox6n9IKW6GXcPQ=; b=tYC3EVcxaqNjrdonCs1ORH8eor5L0hr2A3M2ASNelo4rYhOdStWdezQbIx7P01K+mG uxBHZfxejtID+VeFKwaNHw72ojdJD+V+EV9GXSUnxaFQacceDsyEu2ibL7XRB/hFiN/i OunaJzgZMZueftAfKjXn47OSiqEr5f2+Ow4mdNwK7icj3YoN1t/9PaBjTEdhuzk/qJBj wMPh6MWoHe/knXUrBucVnHkiwXS4LpfpR7eGgz+OITc7zOmcVs6LCcPu8wlUC7tax0/7 UtwgYH2UtebeLSeVO/iSCDXmoPdCAQNml6wa6QOsiIfeaK2Du7ecHFn7ASZY0+/qVHk5 AM2Q== X-Gm-Message-State: AMke39l6Qli9ehDHkH1nyWZ1LkatPtQhXkHcW+amtL7+uxEpntms065AFry+8tnuYbRl/cISVw9IvSkZ9QGvl6cXcf4KLQmN7lXwNlyjV5WzWN1reBTasF+uJBTdyEqfW00fopcXFtXu7XA5X0k= X-Received: by 10.31.192.204 with SMTP id q195mr508170vkf.155.1488378995492; Wed, 01 Mar 2017 06:36:35 -0800 (PST) X-Received: by 10.31.192.204 with SMTP id q195mr508152vkf.155.1488378995199; Wed, 01 Mar 2017 06:36:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.89.71 with HTTP; Wed, 1 Mar 2017 06:36:34 -0800 (PST) In-Reply-To: References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> From: David Farmer Date: Wed, 1 Mar 2017 08:36:34 -0600 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a114388cc4d40490549ac3d70 Archived-At: Cc: james woodyatt , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 14:36:39 -0000 --001a114388cc4d40490549ac3d70 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 3:51 AM, Lorenzo Colitti wrote: > On Wed, Mar 1, 2017 at 5:33 AM, David Farmer wrote: > >> However many OSes also allow configurations other than just /64, is this >>>> OK? Is that how RFC4291 should be interpreted? Honestly, I don't read it >>>> that way, >>>> >>> >>> IMO the important question is not "should an OS refuse to configure a >>> /65 when manually configuring an address". I think the much more important >>> questions are, "can the OS assume that it can use the full 64 bits to form >>> an IID", and "will this link ever run out of IPv6 addresses". The answers >>> to those should be yes and no. >>> >> >> I don't disagree with your answers, and you may not think the manual >> config question is important, but others seem too. >> > > FWIW I wouldn't oppose an exception for manually-configured addresses on > routers. > I think manually configuration should be OPTION for all hosts , and I'd RECOMMEND it for routers, but i wouldn't REQUIRE or even necessary RECOMMEND it for general host. It would be my personal preference that all host have a way to be manually configured, but OPTIONAL is good enough for the standard I think. > And you don't have too. But, your saying no one else can ever have a >> reason to do that, and I'm not so sure about that. And something on the >> other side of the Internet can't make any assumption about what I'm doing >> anyway. You are saying it can't be done because the 64 bit boundary is >> even more important than CIDR and addresses on the other side of the >> Internet are supposed to be opaque. Where as I disagree, CIDR and the >> opaqueness of addresses across the Internet are more fundamental properties >> than 64 bit boundary. Which is why I say the 64 bit boundary is really a >> RECOMMENDATION. And CIDR and the opaqueness of addresses across the >> Internet are REQUIREMENTS. >> > > Let's see if there is common ground here. I agree that routers should > forward on arbitrary prefix lengths. It's probably reasonable that hosts > should not make assumptions about other host's IP addresses (except if they > are on the same subnet). But I think a host should be allowed to assume > that its own subnet and its own IID are 64 bits long. > A host has to actually look at the RA to determine it, and can't just assume. I'd concede that an RA set to and other than /64 with the "a" flag set SHOULD be considered a misconfiguration, but it is possible to set RAs with other than /64, especially if you don't set the "A" flag. And if you manually set set the 128 address and it's within the range defined by the RA then the host SHOULD use it as excepted. Furthermore, I think a host configured with an 128 address via DHCPv6 SHOULD work much the same way, but I'm willing to be convinced otherwise on that. Now to me that says RAs with /64 are REQUIRED iff (if and only if) the "A" flag is set. Otherwise RAs with /64 are RECOMMENDED, but other lengths are allowed. Also you MAY manually configure a host with a subnet length in addition to manually configuring a 128 address, and only in the case were a host is manually configured with a 128 bit address and there is not associated manually configured subnet length or there is no associated RA is it ever ok to assume /64. Another thing I think we should avoid is to remove the fixed 64 barrier and >>> open the door to having this debate again and again, once for every new >>> IPv6-over-foo document and once for every new address configuration >>> protocol (today we have SLAAC and DHCPv6, who knows what we'll have in the >>> future). >>> >> >> Which is why it time to get this right and saying it is now and forever >> 64 isn't right. >> > > Do you agree that a fixed boundary is useful or not? For 20 years the > standards have guaranteed that 64 bits of IIDs were available to hosts that > wanted to use them. If we make that barrier mobile, there will be no > guarantee in the standards any more. Who should be allowed to set the > boundary? An IPv6-over-foo document? An address configuration technology > such as SLAAC? An ISP that wants to charge you $1 for every /128 you use? > I'll agree there is a 64 bit boundary, I don't conceded it's fixed, it's only been considered fixed but cause we errantly allow the word required in RFC4291 and its predecessors, CIDR and the opaqueness of addresses across the Internet are more fundamental principles than the 64 bit boundary. The 64 bit boundary is a convenience, a very important convenience, a very highly RECOMMENDED convenience, but only a convenience. It doesn't override CIDR and the opaqueness of addresses across the Internet. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114388cc4d40490549ac3d70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 1, 2017 at 3:51 AM, Lorenzo Colitti <<= a href=3D"mailto:lorenzo@google.com" target=3D"_blank">lorenzo@google.com> wrote:
<= div dir=3D"ltr">
On We= d, Mar 1, 2017 at 5:33 AM, David Farmer <farmer@umn.edu> wrote:=
However many OSes also allow configuration= s other than just /64, is this OK? Is that how RFC4291 should be interprete= d? Honestly, I don't read it that way,

IMO the important question is not "shou= ld an OS refuse to configure a /65 when manually configuring an address&quo= t;. I think the much more important questions are, "can the OS assume = that it can use the full 64 bits to form an IID", and "will this = link ever run out of IPv6 addresses". The answers to those should be y= es and no.

I= don't disagree with your answers, and you may not think the manual con= fig question is important, but others seem too.

FWIW I wouldn't oppose an exception for ma= nually-configured addresses on routers.

I think manually configuration should be OPTION for al= l hosts , and I'd RECOMMEND it for routers, but i wouldn't REQUIRE = or even necessary RECOMMEND it for general host. It would be my personal pr= eference that all host have a way to be manually configured, but OPTIONAL i= s good enough for the standard I think.=C2=A0
=C2=A0
And you don't have too.=C2=A0 But, your saying no one el= se can ever have a reason to do that, and I'm not so sure about that.= =C2=A0 And something on the other side of the Internet can't make any a= ssumption about what I'm doing anyway.=C2=A0 You are saying it can'= t be done because the 64 bit boundary is even more important than CIDR and = addresses on the other side of the Internet are supposed to be opaque.=C2= =A0 Where as I disagree, CIDR and the opaqueness of addresses across the In= ternet are more fundamental properties than 64 bit boundary.=C2=A0 Which is= why I say the 64 bit boundary is really a RECOMMENDATION.=C2=A0 And CIDR a= nd the opaqueness of addresses across the Internet are REQUIREMENTS.
<= /div>

Let's see if there is= common ground here. I agree that routers should forward on arbitrary prefi= x lengths. It's probably reasonable that hosts should not make assumpti= ons about other host's IP addresses (except if they are on the same sub= net). But I think a host should be allowed to assume that its own subnet an= d its own IID are 64 bits long.
A host has to actually look at the RA to determine it, and can= 't just assume. I'd concede that an RA set to and other than /64 wi= th the "a" flag set SHOULD be considered a misconfiguration, but = it is possible to set RAs with other than /64, especially if you don't = set the "A" flag.=C2=A0 And if you manually set set the 128 addre= ss and it's within the range defined by the RA then the host SHOULD use= it as excepted.=C2=A0 Furthermore, I think a host configured with an 128 a= ddress via DHCPv6 SHOULD work much the same way, but I'm willing to be = convinced otherwise on that.=C2=A0

Now to me t= hat says RAs with /64 are REQUIRED iff (if and only if) the "A" f= lag is set.=C2=A0 Otherwise RAs with /64 are RECOMMENDED, but other lengths= are allowed.=C2=A0 Also you MAY manually configure a host with a subnet le= ngth in addition to manually configuring a 128 address, and only in the cas= e were a host is manually configured with a 128 bit address and there is no= t associated manually configured subnet length or there is no associated RA= is it ever ok to assume /64. =C2=A0

Another thing I= think we should avoid is to remove the fixed 64 barrier and open the door = to having this debate again and again, once for every new IPv6-over-foo doc= ument and once for every new address configuration protocol (today we have = SLAAC and DHCPv6, who knows what we'll have in the future).
=

Which is why it time to= get this right and saying it is now and forever 64 isn't right.
<= /div>

Do you agree that a fixed= boundary is useful or not? For 20 years the standards have guaranteed that= 64 bits of IIDs were available to hosts that wanted to use them. If we mak= e that barrier mobile, there will be no guarantee in the standards any more= . Who should be allowed to set the boundary? An IPv6-over-foo document? An = address configuration technology such as SLAAC? An ISP that wants to charge= you $1 for every /128 you use?

I'll agree there is a 64 bit boundary, I don'= ;t conceded it's fixed, it's only been considered fixed but cause w= e errantly allow the word required in RFC4291 and its predecessors, CIDR an= d the opaqueness of addresses across the Internet are more fundamental prin= ciples than the 64 bit boundary.=C2=A0 The 64 bit boundary is a convenience= , a very important convenience, a very highly RECOMMENDED convenience, but = only a convenience.=C2=A0 It doesn't override CIDR and the opaqueness o= f addresses across the Internet. =C2=A0 =C2=A0 =C2=A0=C2=A0

Thanks.
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0 Email:farme= r@umn.edu
Networking & Telecommunication Services
Office of I= nformation Technology
University of Minnesota=C2=A0=C2=A0
2218 Unive= rsity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis,= MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a114388cc4d40490549ac3d70-- From nobody Wed Mar 1 07:08:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020F012953A for ; Wed, 1 Mar 2017 07:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 HXlRCyfJP88b for ; Wed, 1 Mar 2017 07:08:06 -0800 (PST) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0A912956F for ; Wed, 1 Mar 2017 07:08:06 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 34CE7C76 for ; Wed, 1 Mar 2017 15:08:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83eX0HkJi6Ka for ; Wed, 1 Mar 2017 09:08:06 -0600 (CST) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id D6716C6E for ; Wed, 1 Mar 2017 09:08:05 -0600 (CST) Received: by mail-vk0-f71.google.com with SMTP id n125so7846011vke.0 for ; Wed, 01 Mar 2017 07:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NiJwwyJwcVnLdJ599GC0H3HBVEhBdexyC/yNvJMPy3o=; b=XKSfyeZOgrQ8Ewl+dLweqXPrY134IUQknMWyQlSYPpdLa++5vVMMNu4NPqOXV1goFm xcPUOqQcPbTaXeMVNm3FuiQQVaoNjy6s9l3EXmZFQcgJvyC1R6xZLoEO8y+oAKRHgEeW bAizL0MQm7O3+KE+4/7uVwR3yA0HIFlyZ2QJ53iA5+vy6MrEnOHPKdJ0LUGCgItJhnBv UJ8SZAUxp5URaeGqOti6CwbEqSO2W+Id1LtbOO9Vv+GKBhTb7v844G+PA19eRdToUq50 9tQqxQGWBNF1TLejuAMUAw3woIuDP2lwiIOoojdR8RjHy553dhQ6zkFGqe13R1VCQPyW gPuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NiJwwyJwcVnLdJ599GC0H3HBVEhBdexyC/yNvJMPy3o=; b=ZUzk+1DfxFh/0AIXn+07rhunyejqSxmUsu5wQKDnu7cZMg/UNKiXvecQXsrMKPOqCA SyajAD8MtPfWOnJ3WbMsOe5MVNR3HFHo57j52mC8zxLwpXbXhVQAg/bF3CvcFp8UGcEr tqQcfJ8O1lEitWdNc4g2HfoIB6GsMq4Z8yC6F7LLWgMc7TKB35q/NFJmuS832oCm/PoL bghonw4wpNNGj7bw2eL3EDB/3vZczhoJ5LhMa6f/2CPuojJtHMqaJB98DlUCMbRjUe5+ Ep2mWUKx1EKKPCdtlEqzlqmGiSZqGtKv1wTq2x5uaqWG95jjJ3CeC9k9xNOm23cFcX6x fWzw== X-Gm-Message-State: AMke39nTnS8yP3uN5LbT0Uqk5gJOYXfkL1BxjeGAl5nNGh1u5pbopieVV88WvxVDtPwVxhC7TCT/9WGnNl7WszcT4jk+wmhu4yvJjRQp7M45ddUqcA+k0Dg45R3K1Vg7XsL6ruSJQRYFs9ryK8w= X-Received: by 10.176.5.136 with SMTP id e8mr4241434uae.108.1488380885140; Wed, 01 Mar 2017 07:08:05 -0800 (PST) X-Received: by 10.176.5.136 with SMTP id e8mr4241421uae.108.1488380884909; Wed, 01 Mar 2017 07:08:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.89.71 with HTTP; Wed, 1 Mar 2017 07:08:03 -0800 (PST) In-Reply-To: References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> From: David Farmer Date: Wed, 1 Mar 2017 09:08:03 -0600 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=94eb2c124874eff3540549acadd0 Archived-At: Cc: james woodyatt , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:08:09 -0000 --94eb2c124874eff3540549acadd0 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 8:36 AM, David Farmer wrote: > > > On Wed, Mar 1, 2017 at 3:51 AM, Lorenzo Colitti > wrote: > >> On Wed, Mar 1, 2017 at 5:33 AM, David Farmer wrote: >> >>> However many OSes also allow configurations other than just /64, is this >>>>> OK? Is that how RFC4291 should be interpreted? Honestly, I don't read it >>>>> that way, >>>>> >>>> >>>> IMO the important question is not "should an OS refuse to configure a >>>> /65 when manually configuring an address". I think the much more important >>>> questions are, "can the OS assume that it can use the full 64 bits to form >>>> an IID", and "will this link ever run out of IPv6 addresses". The answers >>>> to those should be yes and no. >>>> >>> >>> I don't disagree with your answers, and you may not think the manual >>> config question is important, but others seem too. >>> >> >> FWIW I wouldn't oppose an exception for manually-configured addresses on >> routers. >> > > I think manually configuration should be OPTION for all hosts , and I'd > RECOMMEND it for routers, but i wouldn't REQUIRE or even necessary > RECOMMEND it for general host. It would be my personal preference that all > host have a way to be manually configured, but OPTIONAL is good enough for > the standard I think. > > >> And you don't have too. But, your saying no one else can ever have a >>> reason to do that, and I'm not so sure about that. And something on the >>> other side of the Internet can't make any assumption about what I'm doing >>> anyway. You are saying it can't be done because the 64 bit boundary is >>> even more important than CIDR and addresses on the other side of the >>> Internet are supposed to be opaque. Where as I disagree, CIDR and the >>> opaqueness of addresses across the Internet are more fundamental properties >>> than 64 bit boundary. Which is why I say the 64 bit boundary is really a >>> RECOMMENDATION. And CIDR and the opaqueness of addresses across the >>> Internet are REQUIREMENTS. >>> >> >> Let's see if there is common ground here. I agree that routers should >> forward on arbitrary prefix lengths. It's probably reasonable that hosts >> should not make assumptions about other host's IP addresses (except if they >> are on the same subnet). But I think a host should be allowed to assume >> that its own subnet and its own IID are 64 bits long. >> > > A host has to actually look at the RA to determine it, and can't just > assume. I'd concede that an RA set to and other than /64 with the "a" flag > set SHOULD be considered a misconfiguration, but it is possible to set RAs > with other than /64, especially if you don't set the "A" flag. And if you > manually set set the 128 address and it's within the range defined by the > RA then the host SHOULD use it as excepted. Furthermore, I think a host > configured with an 128 address via DHCPv6 SHOULD work much the same way, > but I'm willing to be convinced otherwise on that. > > Now to me that says RAs with /64 are REQUIRED iff (if and only if) the "A" > flag is set. Otherwise RAs with /64 are RECOMMENDED, but other lengths are > allowed. Also you MAY manually configure a host with a subnet length in > addition to manually configuring a 128 address, and only in the case were a > host is manually configured with a 128 bit address and there is not > associated manually configured subnet length or there is no associated RA > is it ever ok to assume /64. > > Another thing I think we should avoid is to remove the fixed 64 barrier >>>> and open the door to having this debate again and again, once for every new >>>> IPv6-over-foo document and once for every new address configuration >>>> protocol (today we have SLAAC and DHCPv6, who knows what we'll have in the >>>> future). >>>> >>> >>> Which is why it time to get this right and saying it is now and forever >>> 64 isn't right. >>> >> >> Do you agree that a fixed boundary is useful or not? For 20 years the >> standards have guaranteed that 64 bits of IIDs were available to hosts that >> wanted to use them. If we make that barrier mobile, there will be no >> guarantee in the standards any more. Who should be allowed to set the >> boundary? An IPv6-over-foo document? An address configuration technology >> such as SLAAC? An ISP that wants to charge you $1 for every /128 you use? >> > > I'll agree there is a 64 bit boundary, I don't conceded it's fixed, it's > only been considered fixed but cause we errantly allow the word required in > RFC4291 and its predecessors, CIDR and the opaqueness of addresses across > the Internet are more fundamental principles than the 64 bit boundary. The > 64 bit boundary is a convenience, a very important convenience, a very > highly RECOMMENDED convenience, but only a convenience. It doesn't > override CIDR and the opaqueness of addresses across the Internet. > I'll add; It is so highly RECOMMENDED and so convenient we deluded ourselves into thinking it was actually a REQUIREMENT, that actually overdid the more important concepts of CIDR and the opaqueness of addresses across the Internet. The idea that the 64 bit boundary is fixed is a delusion, an appealing delusion, none the less a delusion. > Thanks. > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --94eb2c124874eff3540549acadd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 1, 2017 at 8:36 AM, David Farmer <farmer@umn.edu> wrote:

On Wed, Mar 1, 2= 017 at 3:51 AM, Lorenzo Colitti <lorenzo@google.com> wrote:=
On Wed, Mar 1, 2017 at 5:= 33 AM, David Farmer <farmer@umn.edu> wrote:
<= div class=3D"gmail_extra">
However many OSes also allow configu= rations other than just /64, is this OK? Is that how RFC4291 should be inte= rpreted? Honestly, I don't read it that way,

IMO the important question is not &quo= t;should an OS refuse to configure a /65 when manually configuring an addre= ss". I think the much more important questions are, "can the OS a= ssume that it can use the full 64 bits to form an IID", and "will= this link ever run out of IPv6 addresses". The answers to those shoul= d be yes and no.

=
I don't disagree with your answers, and you may not think the manu= al config question is important, but others seem too.

FWIW I wouldn't oppose an exception = for manually-configured addresses on routers.

I think manually configuration should be OPTION = for all hosts , and I'd RECOMMEND it for routers, but i wouldn't RE= QUIRE or even necessary RECOMMEND it for general host. It would be my perso= nal preference that all host have a way to be manually configured, but OPTI= ONAL is good enough for the standard I think.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
And you don't have too.=C2=A0 But, your saying no= one else can ever have a reason to do that, and I'm not so sure about = that.=C2=A0 And something on the other side of the Internet can't make = any assumption about what I'm doing anyway.=C2=A0 You are saying it can= 't be done because the 64 bit boundary is even more important than CIDR= and addresses on the other side of the Internet are supposed to be opaque.= =C2=A0 Where as I disagree, CIDR and the opaqueness of addresses across the= Internet are more fundamental properties than 64 bit boundary.=C2=A0 Which= is why I say the 64 bit boundary is really a RECOMMENDATION.=C2=A0 And CID= R and the opaqueness of addresses across the Internet are REQUIREMENTS.

Let's see if there= is common ground here. I agree that routers should forward on arbitrary pr= efix lengths. It's probably reasonable that hosts should not make assum= ptions about other host's IP addresses (except if they are on the same = subnet). But I think a host should be allowed to assume that its own subnet= and its own IID are 64 bits long.

A host has to actually look at the RA to determine it, and = can't just assume. I'd concede that an RA set to and other than /64= with the "a" flag set SHOULD be considered a misconfiguration, b= ut it is possible to set RAs with other than /64, especially if you don'= ;t set the "A" flag.=C2=A0 And if you manually set set the 128 ad= dress and it's within the range defined by the RA then the host SHOULD = use it as excepted.=C2=A0 Furthermore, I think a host configured with an 12= 8 address via DHCPv6 SHOULD work much the same way, but I'm willing to = be convinced otherwise on that.=C2=A0

Now to m= e that says RAs with /64 are REQUIRED iff (if and only if) the "A"= ; flag is set.=C2=A0 Otherwise RAs with /64 are RECOMMENDED, but other leng= ths are allowed.=C2=A0 Also you MAY manually configure a host with a subnet= length in addition to manually configuring a 128 address, and only in the = case were a host is manually configured with a 128 bit address and there is= not associated manually configured subnet length or there is no associated= RA is it ever ok to assume /64. =C2=A0

Another thi= ng I think we should avoid is to remove the fixed 64 barrier and open the d= oor to having this debate again and again, once for every new IPv6-over-foo= document and once for every new address configuration protocol (today we h= ave SLAAC and DHCPv6, who knows what we'll have in the future).

Which is why it tim= e to get this right and saying it is now and forever 64 isn't right.

Do you agree that a f= ixed boundary is useful or not? For 20 years the standards have guaranteed = that 64 bits of IIDs were available to hosts that wanted to use them. If we= make that barrier mobile, there will be no guarantee in the standards any = more. Who should be allowed to set the boundary? An IPv6-over-foo document?= An address configuration technology such as SLAAC? An ISP that wants to ch= arge you $1 for every /128 you use?

I'll agree there is a 64 bit boundary, I don'= ;t conceded it's fixed, it's only been considered fixed but cause w= e errantly allow the word required in RFC4291 and its predecessors, CIDR an= d the opaqueness of addresses across the Internet are more fundamental prin= ciples than the 64 bit boundary.=C2=A0 The 64 bit boundary is a convenience= , a very important convenience, a very highly RECOMMENDED convenience, but = only a convenience.=C2=A0 It doesn't override CIDR and the opaqueness o= f addresses across the Internet. =C2=A0 =C2=A0 =C2=A0=C2=A0

I'll add; =C2=A0It is so highly RECOMMENDE= D and so convenient we deluded ourselves into thinking it was actually a RE= QUIREMENT, that actually overdid the more important concepts of CIDR and th= e opaqueness of addresses across the Internet.=C2=A0 The idea that the 64 b= it boundary is fixed is a delusion, an appealing delusion, none the less a = delusion. =C2=A0
=C2=A0
T= hanks.
--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &a= mp; Telecommunication Services
Office of Information Technology
Unive= rsity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 Email= :farmer@umn.edu
Networking & Telecommunication Services
Offic= e of Information Technology
University of Minnesota=C2=A0=C2=A0
2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--94eb2c124874eff3540549acadd0-- From nobody Wed Mar 1 07:54:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8C71294E3 for ; Wed, 1 Mar 2017 07:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 h3q_kCedNY0Z for ; Wed, 1 Mar 2017 07:54:11 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031C81294C0 for ; Wed, 1 Mar 2017 07:54:10 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id r136so11491969vke.1 for ; Wed, 01 Mar 2017 07:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p2bwCme1YgqIWRFaYPC8gpOND6eTMTkLfQAmqKr8zR8=; b=f7oZnPCJ4S0VfFAckKSD55xbk31Li0gPF6oJQ8YOAE+ODPkR0tcuZHrcI0eilxYCVU FHVypEr5iy787aSU/OFrkeK7gvv7dR+V6l8WVbt1dOnlVmeMZx0e9lvHARqys2EAvdvB rUo4HzRU8yWAf/YxSWsIZA0ZgzofO2SelQUm1481ICA9l1qqagyc0U7PxzQbbznXJt1s bW7CP3MwNLv5sfGTfr9vXPfR3j68agS3m1/QgutkE04nZrjbqzEmeCIdCaeWE9kuZbmk FOi4KOiR06mfKis8YNjdye/jqkyadiZc/k5tseMapQXDekqYrBb9qbVFfH5shcGDTPRk 2hdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p2bwCme1YgqIWRFaYPC8gpOND6eTMTkLfQAmqKr8zR8=; b=XOgQZxaeRwvylx0LdHLwzHiLQb1Sq0dyJiUkgBl/UIvDFfg6zfUtSMjpKzE4Dq7fr2 i8VRfgjJu9qgOT3Fz+wEsZL8g8L+h3gpPHatifNVgBthxqGYlavvPk4FhTF/Ihvq7R4I Y6gawBEUqrVPYh1PzrnkSsq18ewSAG4jZIACAN4etcGaQuOWKN9iSQ0fYk2BhxEAK8ne wD18abY+PVgWP0DKQy3Z77FXGtzuTT2Wdq3W9+UM0Es4I3KNMn69V7/uew0UXpaRTNxQ y92p7WQTLnrcyjSNeYFaQeJwqJqkqYu8DbQxMrTleewq+hf2XJ9bfw46SUgooXGwYkdn GHKg== X-Gm-Message-State: AMke39nnBgfKeVvDUbES+/PxXPQjN6Co3Y4kD3ENsFibv2HdFuDvDShXgg+6wvBD6pedzJwEZRKXqze4XgwXDZcW X-Received: by 10.31.142.68 with SMTP id q65mr759638vkd.83.1488383649963; Wed, 01 Mar 2017 07:54:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 1 Mar 2017 07:53:49 -0800 (PST) In-Reply-To: <58B6A02E.50501@foobar.org> References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> From: Lorenzo Colitti Date: Thu, 2 Mar 2017 00:53:49 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a1143703abf43df0549ad5222 Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:54:13 -0000 --001a1143703abf43df0549ad5222 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 7:19 PM, Nick Hilliard wrote: > > What else? You don't have to list them here, a pointer to a previous > > message will do. > > * established practice since the 1990s, suggesting that any attempt to > un-ring this particular bell is likely not to succeed. > Can you explain the difference between your reply and "we've been doing it for 20 years therefore it must be the right thing to do"? The latter is a a) not a technical argument, and b) not a useful argument if most of that operational knowledge was formed using IPv4. Given that for most of the 1990s IPv6 had not been designed, much less operationally deployed, I assume that you do indeed mean IPv4. The reason why IPv4 addressing practiced don't necessarily apply in IPv6 is the protocols are completely different in terms of address availability. Example: in IPv4, CIDR is an absolute necessity in order not to run out of space. In IPv6, it's not. --001a1143703abf43df0549ad5222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 1, 2017 at 7:19 PM, Nick Hilliard <nick@foobar.org> wr= ote:
> What else? You don't have to list them here, a pointer to a = previous
> message will do.

* established practice since the 1990s, suggesting that any attempt = to
un-ring this particular bell is likely not to succeed.

Can you explain the difference between your reply and "= ;we've been doing it for 20 years therefore it must be the right thing = to do"?

The latter is a a) not a technica= l argument, and b) not a useful argument if most of that operational knowle= dge was formed using IPv4. Given that for most of the 1990s IPv6 had not be= en designed, much less operationally deployed, I assume that you do indeed = mean IPv4.

The reason why IPv4 addressing practice= d don't necessarily apply in IPv6 is the protocols are completely diffe= rent in terms of address availability. Example: in IPv4, CIDR is an absolut= e necessity in order not to run out of space. In IPv6, it's not.
<= /div>
--001a1143703abf43df0549ad5222-- From nobody Wed Mar 1 07:56:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC711295A7 for ; Wed, 1 Mar 2017 07:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 NoO3rqPLEc32 for ; Wed, 1 Mar 2017 07:56:56 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E82A1295A4 for ; Wed, 1 Mar 2017 07:56:56 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id t8so11521633vke.3 for ; Wed, 01 Mar 2017 07:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bxh98UZd2KZz/WkG40R4ETNrXJzcdHN+pHl7C1n9Fvg=; b=E4aO1Dxg16XQt3qmuPBAhFFpoAJlhwl62bWRteXEpLF+f0KM9S3Bf0MrPVvMeZD6Z2 drqEmFMo2mXQHkMjkr+vCfs7YT8CWxDdYFekpJhSPr6FUpN3iYP9fgSUHSDBHwXcw0Vd f2B86uqXcKdFGsR4MEkEgXA946rSvpSSJskiNTOg66jpMv7irwA8rSl7+9ejbY0qlBN7 g2zRpjVAh9EG/zSEFZN9mIpee8ZBak37bzHpa+rBb/hrVJRN17ps6800EofyhJzGbJvA lSCDgKB9gjJ5uPrpdU3Gm+XkYlawb+TErtPP8vWIeeN0ue1EcyeKFpdQcHMpAn8w6pOO bn1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bxh98UZd2KZz/WkG40R4ETNrXJzcdHN+pHl7C1n9Fvg=; b=rK6CV3mXW87C5SFeTx2EsCG2ypCQzu1eORfbyGPTLZzii/8bqGIphOccRwKiyh5UhC tZb1HhZNEXOn4p2/GNrYTv3dbA9F6ngRiE9mH07PVaaUcrtfH5BXf6n4LBfdw/oWBIKE ZTGCZQdEStrwnTbSggh6luK2yIKZGQZEty7BcIW7KsSlMQBO3usSo6SOS9YHV3EMvf6r vFJHAMS5/B+srw4MAOeVCzlg6ijA/cJuhLK1ECDS6t0wiStJMNEUG6D7M0p9uJvYc3mz TNb2b76t5KCE+RryAuWmvvcsji0A77KMCGPIpEklmgQWpq2t8nFvayhOa4ErigCY3zs/ 21OA== X-Gm-Message-State: AMke39mPVLfWWFBf1sOR6F0FFmrxBXc0Ri+08oFH4D5pRnHGUsy8JFoAMLd6lQWhfF9qw83pJjdK/kHzDztfwbDI X-Received: by 10.31.5.13 with SMTP id 13mr745894vkf.156.1488383815097; Wed, 01 Mar 2017 07:56:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 1 Mar 2017 07:56:34 -0800 (PST) In-Reply-To: <20170301104457.GA14420@nokia.com> References: <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170301072747.GA10187@nokia.com> <20170301104457.GA14420@nokia.com> From: Lorenzo Colitti Date: Thu, 2 Mar 2017 00:56:34 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Greg Hankins Content-Type: multipart/alternative; boundary=001a1143d9c69725830549ad5c77 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:56:57 -0000 --001a1143d9c69725830549ad5c77 Content-Type: text/plain; charset=UTF-8 Yes, there are implementations that rely on the fact that IIDs are specified to be 64 bits to provide useful functionality. And they are widely deployed. I have no objection to a router accepting a /117 prefix length when configuring an IPv6 address. I do object to making host code that relies on /64 noncompliant. On Wed, Mar 1, 2017 at 7:44 PM, Greg Hankins wrote: > On Wed, Mar 01, 2017 at 06:59:26PM +0900, Lorenzo Colitti wrote: > On Wed, Mar 1, 2017 at 4:27 PM, Greg Hankins > wrote: > >> We can never change our > >> implementation to be compliant with the proposed text because of the > >> operational havoc it would create for our customers. It's simply > >> infeasible > >> to impose these kind of addressing restrictions. > > > >The word "change" is incorrect here, because the standard that was current > >when Nokia wrote its implementation had pretty much exactly the same > >requirement. (The reason for that is that *all* past standards have > >contained this language except for RFC 1884, which specified /80, which > >won't work in the real world.) > > > >Could you reword your position to take into account that fact? > > Call it whatever you want, the point again is that we have customers who > have > deployed whatever addressing architecture meets their requirements, and we > can't force them to change it. It's their network and their address space. > > You are correct that other standards had the same requirement, which my > current and all of my former employer's* implementations also ignored for > the same reasons that have been mentioned. This is a good opportunity > for the -bis revision to reflect the state of operational deployments that > have proven the assumptions in the original standard to be impractical. > > Is anyone aware of any implementations that comply with this requirement? > > Greg > > * Riverstone, Force10, Brocade > > -- > Greg Hankins > --001a1143d9c69725830549ad5c77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, there are implementations that rely on the fact that = IIDs are specified to be 64 bits to provide useful functionality. And they = are widely deployed.

I have no objection to a router acc= epting a /117 prefix length when configuring an IPv6 address. I do object t= o making host code that relies on /64 noncompliant.

On Wed, Mar 1, 2017 at 7:44= PM, Greg Hankins <ghankins@mindspring.com> wrote:
=
On W= ed, Mar 01, 2017 at 06:59:26PM +0900, Lorenzo Colitti wrote:
On Wed, Mar 1, 2017 at 4:27 PM, Greg Hankins <ghankins@mindspring.com> wrote:
>> We can never change our
>> implementation to be compliant with the proposed text because of t= he
>> operational havoc it would create for our customers.=C2=A0 It'= s simply
>> infeasible
>> to impose these kind of addressing restrictions.
>
>The word "change" is incorrect here, because the standard tha= t was current
>when Nokia wrote its implementation had pretty much exactly the same >requirement. (The reason for that is that *all* past standards have
>contained this language except for RFC 1884, which specified /80, which=
>won't work in the real world.)
>
>Could you reword your position to take into account that fact?

Call it whatever you want, the point again is that we have cust= omers who have
deployed whatever addressing architecture meets their requirements, and we<= br> can't force them to change it.=C2=A0 It's their network and their a= ddress space.

You are correct that other standards had the same requirement, which my
current and all of my former employer's* implementations also ignored f= or
the same reasons that have been mentioned.=C2=A0 This is a good opportunity=
for the -bis revision to reflect the state of operational deployments that<= br> have proven the assumptions in the original standard to be impractical.

Is anyone aware of any implementations that comply with this requirement?
Greg

* Riverstone, Force10, Brocade

--
Greg Hankins <ghankins@mindsp= ring.com>

--001a1143d9c69725830549ad5c77-- From nobody Wed Mar 1 08:11:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD541295C0 for ; Wed, 1 Mar 2017 08:11:17 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fundacionsadosky.org.ar 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 8PzyH1Iy8qoG for ; Wed, 1 Mar 2017 08:11:15 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644C21295B3 for ; Wed, 1 Mar 2017 08:11:15 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id n186so75372239qkb.3 for ; Wed, 01 Mar 2017 08:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fundacionsadosky.org.ar; s=google; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=+WGw/ghoqO9vO3AuUk5cA9PNVph877o/6jK9fE3nhQ0=; b=gQuemay+rNLy562+xZAFI2jK+tAiVU1w2yjrXrJDNYO/ryuWniIn0zjYkYA4B1e+Ne m7miJwYEaPxs0BW1QyaQpSZSrguFm1rvejAMf0hPsMnXj7u0u+4P06Me1eXq5Ky8mKNq 9fdQew0Rmb/vSSgtCImGyIWrHC+Rzu820uB8Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+WGw/ghoqO9vO3AuUk5cA9PNVph877o/6jK9fE3nhQ0=; b=tr4xkQfKdhotVx2AamI888w+46tgS0IRweGiuTNYraEjb8MSJB5NgQgGYswG52Q5Do WSNRAmbRAATdkZVgjI2jQKmRMncJGmNsmYMw4TbD6Nd6srL8cD05lEmH9DKQIslQkigD XeoqKcGmvSc/SUIBKUrsHfxHnhRIDxLNQRDIKCI9RpYPRkZ2ht9KvrYGVivdTjxWXaD9 x1tAIdjREkr/hpUvEnx9tQcjYlhSGqL3ha82LNYO7vWLjGWSkbOrXzrQ1k4H4mSkJvWH qrUjbgB6Qy3GbvuFaZhnPeqv2NGcfW/qrM7zIjcbBuLoqtMC4XAnPT88qeweiGKiyAC+ nByw== X-Gm-Message-State: AMke39kBrMGy8qibRGZMXuJG1mz1kUt1C9vGszTSOgsJau9LRnVCxf8SFoK8qvVjjTGsXA== X-Received: by 10.55.75.2 with SMTP id y2mr10127510qka.39.1488384674184; Wed, 01 Mar 2017 08:11:14 -0800 (PST) Received: from [192.168.100.103] ([186.158.218.178]) by smtp.googlemail.com with ESMTPSA id u43sm3421429qtc.11.2017.03.01.08.11.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 08:11:13 -0800 (PST) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: 6man WG References: <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170301072747.GA10187@nokia.com> <20170301104457.GA14420@nokia.com> From: =?UTF-8?Q?Iv=c3=a1n_Arce?= Organization: =?UTF-8?Q?Fundaci=c3=b3n_Dr._Manuel_Sadosky?= Message-ID: Date: Wed, 1 Mar 2017 13:11:09 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Lightning/4.7.7 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:11:18 -0000 El 1/3/17 a las 12:56, Lorenzo Colitti escribió: > Yes, there are implementations that rely on the fact that IIDs are > specified to be 64 bits to provide useful functionality. And they are > widely deployed. > I keep reading this on the list and wonder. What are these implementations? Can we actually enumerate implementations that rely and dont' rely on a fixed plen of 64 bits? Does a survey about that specific claim already exist? FTR: I believe RFC 4291bis SHOULD NOT mandate a fixed 64 bit plen in general. I think any specific exceptions should be enumerated explicitly and justified, and that existing behavior of some host OS that does not adhere to spec should be described in an Informational I-D. -ivan > -- Iván Arce Director del Programa STIC Fundación Dr. Manuel Sadosky http://www.fundacionsadosky.org.ar TE: (+54-11) 4328-5164 GPG fingerprint: 4D97 3003 76C9 9DA4 7209 7982 0A1D 10BE CEA9 1B6E From nobody Wed Mar 1 09:03:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1B4129617 for ; Wed, 1 Mar 2017 09:03: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fundacionsadosky.org.ar 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 YpZHbewuSaHm for ; Wed, 1 Mar 2017 09:03:13 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BDC129616 for ; Wed, 1 Mar 2017 09:03:13 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id n186so77828395qkb.3 for ; Wed, 01 Mar 2017 09:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fundacionsadosky.org.ar; s=google; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=v4LFLRLJ72Gt83Sm3Q/lEV4qMqADUuBbRTvkpbEqd+8=; b=G7IGj+2Rp3kUL625dHX/1x3FDFXMkYZB1ZXGgX+5Mz7iQhPsmfutIhH1kpznLKVFtb 9/emJQJSobPcJcU1muBEGo9TblGAqWWJgiABFsMm+/YoBMkfbRbG/oMazfQOVs0OPpjk 53KLaX8aG83aSJqkqXDMCLJEiHDC3A1I873TA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=v4LFLRLJ72Gt83Sm3Q/lEV4qMqADUuBbRTvkpbEqd+8=; b=mmQ/eRs2lOOYWbd+bsm0YJZVhNeoOpNwBxaxXluD7CRqF7OyCbuCljqYP878FbOntq OKl4Dz1JQJ0D1YTonOpGkos8zET7GUrzeoithgitWuFvIj/XATbgKqwqtZB4bM5RJONZ yrF18jAhzx1ooQWhud0vwre5EtSU95x0iCeKyzqgLg3fWw5d7SBoyP+73zpxDRuJcYjP REV5oS6DuOa9kkbAk5NVQgplLRGno+xS5H8dwwaQa94R/UM+QVEJQ516OM0DD5v0Ln78 DPzmQabu3ZGFKy0lR4sRHgSpcQnfsdvMnKNNhQPO2a0pZYnAH3gRluHVVzoRdQ4yAhnJ XzxA== X-Gm-Message-State: AMke39l2SzewQyQG1K4QRN0M0K0qmKmN5IzSgpRn5gyFfNUgpe48YJ/0Nks9wzutqJEX5w== X-Received: by 10.55.217.134 with SMTP id q6mr11763629qkl.52.1488387791686; Wed, 01 Mar 2017 09:03:11 -0800 (PST) Received: from [192.168.100.103] ([186.158.218.178]) by smtp.googlemail.com with ESMTPSA id j11sm3495968qta.39.2017.03.01.09.03.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 09:03:10 -0800 (PST) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: 6man WG References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> From: =?UTF-8?Q?Iv=c3=a1n_Arce?= Organization: =?UTF-8?Q?Fundaci=c3=b3n_Dr._Manuel_Sadosky?= Message-ID: <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> Date: Wed, 1 Mar 2017 14:03:08 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Lightning/4.7.7 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 17:03:15 -0000 El 1/3/17 a las 6:51, Lorenzo Colitti escribió: > > Another thing I think we should avoid is to remove the fixed 64 > barrier and open the door to having this debate again and again, > once for every new IPv6-over-foo document and once for every new > address configuration protocol (today we have SLAAC and DHCPv6, > who knows what we'll have in the future). > > > Which is why it time to get this right and saying it is now and > forever 64 isn't right. > > > Do you agree that a fixed boundary is useful or not? For 20 years the > standards have guaranteed that 64 bits of IIDs were available to hosts > that wanted to use them. If we make that barrier mobile, there will be > no guarantee in the standards any more. Who should be allowed to set the > boundary? An IPv6-over-foo document? An address configuration technology > such as SLAAC? The last paragraph of section "2.5.1 Interface identifiers" in 4291 said: The details of forming interface identifiers are defined in the appropriate "IPv6 over " specification, such as "IPv6 over Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]. The corresponding paragraph in rfc4291bis is: The details of forming interface identifiers are defined in other specifications, such as "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in appropriate "IPv6 over " specifications, such as "IPv6 over Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T G.9959 Networks" [RFC7428]. The security and privacy considerations for IPv6 address generation is described in [RFC7721]. Don't you agree with that? -ivan -- Iván Arce Director del Programa STIC Fundación Dr. Manuel Sadosky http://www.fundacionsadosky.org.ar TE: (+54-11) 4328-5164 GPG fingerprint: 4D97 3003 76C9 9DA4 7209 7982 0A1D 10BE CEA9 1B6E From nobody Wed Mar 1 11:38:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA63D129683 for ; Wed, 1 Mar 2017 11:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=unavailable autolearn_force=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 2C365bzJxQcT for ; Wed, 1 Mar 2017 11:38:06 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08E1129676 for ; Wed, 1 Mar 2017 11:30:19 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v21JUHWN031223 for ; Wed, 1 Mar 2017 20:30:17 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C8F4620BC3E for ; Wed, 1 Mar 2017 20:30:17 +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 B60C02099DC for ; Wed, 1 Mar 2017 20:30:17 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v21JUHdi031004 for ; Wed, 1 Mar 2017 20:30:17 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: ipv6@ietf.org References: <20170223134026.GI5069@gir.theapt.org> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> From: Alexandre Petrescu Message-ID: <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> Date: Wed, 1 Mar 2017 20:30:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 19:38:07 -0000 Let me add one more point here I just tried: Le 28/02/2017 à 13:04, Alexandre Petrescu a écrit : [...] > Finally, there is no advice of what bits to put between fe80:: and a > 64bit the Interface ID - zeros or ones? linux says it's a fe80::/64 > and IIRC BSD says it's a fe80::/10. The routing entries based on > that can make for interop problems. For information, today on linux a /65 RA is called "illegal" and a /63 RA makes a Host to _not_ configure an address. What linux wants is a 64 and nothing else. This is not normal, and it's not programmer's fault. Alex From nobody Wed Mar 1 11:42:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8455129676 for ; Wed, 1 Mar 2017 11:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bsjuVQt8lbAT for ; Wed, 1 Mar 2017 11:41:58 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3365D1298B5 for ; Wed, 1 Mar 2017 11:41:58 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v21Jft0C002806 for ; Wed, 1 Mar 2017 20:41:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DE9DE20CE1E for ; Wed, 1 Mar 2017 20:41:55 +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 CA14B20BC80 for ; Wed, 1 Mar 2017 20:41:55 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v21JftRo003444 for ; Wed, 1 Mar 2017 20:41:55 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: ipv6@ietf.org References: <20170301.110927.104116623.sthaug@nethelp.no> <20170301.115819.78792371.sthaug@nethelp.no> <4E8CA778-9DFA-4B4E-88B1-ED9DF1AB982E@employees.org> From: Alexandre Petrescu Message-ID: Date: Wed, 1 Mar 2017 20:42:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <4E8CA778-9DFA-4B4E-88B1-ED9DF1AB982E@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 19:42:03 -0000 Le 01/03/2017 à 12:04, otroan@employees.org a écrit : > >> On 1 Mar 2017, at 11:58, sthaug@nethelp.no wrote: >> >>>>> FWIW I wouldn't oppose an exception for manually-configured >>>>> addresses on routers. >>>> >>>> But you would oppose it for hosts? Then I don't think we're >>>> any further. >>>> >>> >>> Not sure about that. I suppose it also depends on what manual >>> means. If it's literally just operators configuring them manually >>> by editing configuration files that's probably fine, but that's >>> not what you want to do, is it? >> >> Yes, that is exactly what I want to do. I want to be able to use >> the ifconfig command to set an IPv6 address with a netmask >> different from 64, and to have the corresponding config file entry >> take effect when the box is booted or the service restarted. > > And that clearly always have been permitted. In a sense yes, but in the sense of the longest-match algorithm this permission is not that clearcut, because it is over-ridden. Let me explain an example. I am permitted to freely add a fe80::1/63 on my linux but the longest-match algorithm will over-ride my fe80::/63 intention because the kernel over-rides it with a _by_default_ fe80::/64 prefix it added there without me asking it. That _by_default_ is also resisting reboots. So - yes, it is permitted, but only to be over-ridden by the 64. In other words: I am permitted to add a fe80::1/63 and I will be succsefull in my intention _if_ I also delete the kernel's intention which is there by default, and that after each reboot. (in Windows there is a similar thing). In that sense, I agree with you. > E.g. how would you otherwise configure a /128 loopback. In linux /128 is a particular case. It pops up after an ifconfig if that ifconfig did not specify a plen parameter. There are /128s on other interfaces than loopbacks. There may be a confusion in considering that /128 is a prefix length, or it just means an address. DHCPv6 people think a /128 means just one address, whereas RA people think /128 is something that could be put in an RA. > I agree that current text have always been at best ambiguous on this > point. I agree. Alex > > Best regards, Ole > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Mar 1 11:47:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7082F129676 for ; Wed, 1 Mar 2017 11:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 ZPQM1Y37nDTU for ; Wed, 1 Mar 2017 11:47:55 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18CE12967F for ; Wed, 1 Mar 2017 11:47:54 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v21JliAT004523; Wed, 1 Mar 2017 20:47:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 82864203393; Wed, 1 Mar 2017 20:47: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 716AC209990; Wed, 1 Mar 2017 20:47:44 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v21JliMD006999; Wed, 1 Mar 2017 20:47:44 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: =?UTF-8?Q?Dan_L=c3=bcdtke?= References: <20170223134026.GI5069@gir.theapt.org> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <92160C59-79EC-4EB0-BFD5-69697A5E1306@danrl.com> From: Alexandre Petrescu Message-ID: Date: Wed, 1 Mar 2017 20:47:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <92160C59-79EC-4EB0-BFD5-69697A5E1306@danrl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 19:47:56 -0000 Le 01/03/2017 à 12:23, Dan Lüdtke a écrit : > >> On 28 Feb 2017, at 13:04, Alexandre Petrescu wrote: >> >> Finally, there is no advice of what bits to put between fe80:: and a >> 64bit the Interface ID - zeros or ones? linux says it's a fe80::/64 and >> IIRC BSD says it's a fe80::/10. The routing entries based on that can >> make for interop problems. > > I think there is advice. As I understand, /10 is reserved but only /64 is specified. Sorry, I dont understand that? What is the difference? Why reserving X if only specifying Y? What other concept is similar: is there some other number which is reserved and only number+1 is specified? Why couldnt we just reserve without specifying? Or specifying without reserving? If we continue with reserving _and_ specifying we continue wasting these 54bits there. What are these 54bits for? Alex > > > RFC 4291 IP Version 6 Addressing Architecture > 2.5.6. Link-Local IPv6 Unicast Addresses > > Link-Local addresses are for use on a single link. Link-Local > addresses have the following format: > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ > > > Cheers, > > Dan > From nobody Wed Mar 1 11:48:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A5F129676 for ; Wed, 1 Mar 2017 11:48: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KUUEX4Q7kfT0 for ; Wed, 1 Mar 2017 11:48:39 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE219129684 for ; Wed, 1 Mar 2017 11:48:38 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id p5so23460008pga.1 for ; Wed, 01 Mar 2017 11:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=DtIz+jEckJR0o1W4PyI/l46Euba+ksLrCKUcZChUmJQ=; b=qgzoCMN/oI6JTc12PPLMZPcet6zrPGT/cq+lfkSAxndZLXf11xAvT5jwFKJ0sqTq9Z Wki4kBrgTjRNjnVYf50wRxgFhjdl5d74DPsZSqT31hIwuSB55PEhCyiNm+9PAR+TqFFb iDpltESMNKD8oM58lPoLWrVo1yd03wVU1weYoeBosgx5vgU3oFQLKm7yN8EwxqHuO0PQ AEOBTXd5L3o2paaQjVE1fVTx4/FiSRAIW/Tw1ElFxhviV407p3YwkeZhdA0al2Tv4J2w aYqkev9B8Ly8bRKlTvSEt9y01V5TxGdIUS1GZIme9W2co6MCEwf4iTOfdorZ/Y66s8jl 590w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DtIz+jEckJR0o1W4PyI/l46Euba+ksLrCKUcZChUmJQ=; b=Jm4DUSFugn8EoxhznVCG9QMjdntRGh+TFIGz8VbT1ZzMi3e3n+7r06yck5/6867A5z olF9eW2WdeA6LY3N5tkseBURgmCZ/j7Fgo4XmBWlw2ietHXQHjI/bGF5sYqCeFGmEZkP YRuLbnYMe2pEP8AzYFRaV5EFY9sO/JvyUgz3DQ7JzWp8Ss2soNk/9FTybxqJCzVlvoCR f3RaXxyZ4+osK9lonI3s9OH694vGTlBEWE68IRNnhLhE5GSmkU00L2FSgYjCR7XQ43zs X5fCzVHk5+1AJpDZom8sUhTacXGcs6goQJnzybs8k0kkAKAFAf5OQJw+bTwoDUCCqOw9 B0ZQ== X-Gm-Message-State: AMke39lYVCpl6ojXOIWH8gqIkSRmAj3UuJu7VNwcnZUl+qaLviD5i/aRhVDBUq9dKTRy6g== X-Received: by 10.99.152.10 with SMTP id q10mr10573935pgd.192.1488397718437; Wed, 01 Mar 2017 11:48:38 -0800 (PST) Received: from ?IPv6:2406:e007:6663:1:28cc:dc4c:9703:6781? ([2406:e007:6663:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y21sm12225096pgh.52.2017.03.01.11.48.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 11:48:37 -0800 (PST) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: =?UTF-8?Q?Iv=c3=a1n_Arce?= , 6man WG References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> Date: Thu, 2 Mar 2017 08:48:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 19:48:42 -0000 On 02/03/2017 06:03, Iv=C3=A1n Arce wrote: > El 1/3/17 a las 6:51, Lorenzo Colitti escribi=C3=B3: >=20 >> >> Another thing I think we should avoid is to remove the fixed 6= 4 >> barrier and open the door to having this debate again and agai= n, >> once for every new IPv6-over-foo document and once for every n= ew >> address configuration protocol (today we have SLAAC and DHCPv6= , >> who knows what we'll have in the future). >> >> >> Which is why it time to get this right and saying it is now and >> forever 64 isn't right. >> >> >> Do you agree that a fixed boundary is useful or not? For 20 years the >> standards have guaranteed that 64 bits of IIDs were available to hosts= >> that wanted to use them. If we make that barrier mobile, there will be= >> no guarantee in the standards any more. Who should be allowed to set t= he >> boundary? An IPv6-over-foo document? An address configuration technolo= gy >> such as SLAAC?=20 >=20 > The last paragraph of section "2.5.1 Interface identifiers" in 4291 sai= d: >=20 > The details of forming interface identifiers are defined in the > appropriate "IPv6 over " specification, such as "IPv6 over > Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]. >=20 > The corresponding paragraph in rfc4291bis is: >=20 > The details of forming interface identifiers are defined in other > specifications, such as "Privacy Extensions for Stateless Address > Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating > Semantically Opaque Interface Identifiers with IPv6 Stateless Addres= s > Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described i= n > appropriate "IPv6 over " specifications, such as "IPv6 over > Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T > G.9959 Networks" [RFC7428]. The security and privacy considerations= > for IPv6 address generation is described in [RFC7721]. >=20 > Don't you agree with that? Iv=C3=A1n, That is the basis for Alexandre's suggestion to simply drop the mention of 64 from the architecture: because it's an implementation parameter. With my Computer Scientist hat on, I think that's the right thing to do. With my Pragmatist hat on, I think stating that /64 is recommended is a more practical approach. Stating that it's required is plain wrong. Brian From nobody Wed Mar 1 11:53:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7689129673 for ; Wed, 1 Mar 2017 11:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 NBjGZkrnNFHu for ; Wed, 1 Mar 2017 11:53:49 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F9B1295DE for ; Wed, 1 Mar 2017 11:53:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 884D9A5; Wed, 1 Mar 2017 20:53:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1488398026; bh=kwnHmNnTB4HYLUL+xwS50UnFo+xiCJptoSzAby7zu3Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=yF+Coyh3KsFfWdXWdMdBBJDitePZ+9UxcmZUhjpbT3rtywtK/x7OdTtKRquffRrUH mQKZX8X8oDCVkoKt7/2OB3YBPormSSYtYhjF2uGggnI9nli/qNEstpZpkL4x5tG5Hi iDHTs8X8fp3D20eNWGYyt8vOJObKNpzmwGvRoP1M= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6EEFFA4; Wed, 1 Mar 2017 20:53:46 +0100 (CET) Date: Wed, 1 Mar 2017 20:53:46 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux In-Reply-To: <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> Message-ID: References: <20170223134026.GI5069@gir.theapt.org> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.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; charset=US-ASCII; format=flowed Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 19:53:51 -0000 On Wed, 1 Mar 2017, Alexandre Petrescu wrote: > For information, today on linux a /65 RA is called "illegal" and a /63 > RA makes a Host to _not_ configure an address. What linux wants is a 64 > and nothing else. This is not normal, and it's not programmer's fault. Could you please elaborate on the last sentence. What do you mean by "not normal"? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Mar 1 12:10:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17C712968C for ; Wed, 1 Mar 2017 12:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0Lo2LR89F6VF for ; Wed, 1 Mar 2017 12:10:37 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D49812968A for ; Wed, 1 Mar 2017 12:10:37 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id 72so52575330uaf.3 for ; Wed, 01 Mar 2017 12:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wtMn7t65kMJz+eTzLTQKzQOXJvOuHzL1YjxuYmRtEKs=; b=Lk3fgkf6GPTC6gm+7FocIhxcTBC5qKQ2cV9V9RaJukncAmSg/c3dngni47qtHNN/2K 4GBWbsfAe1BdgwZ8PDXsXFK5MDk+eg40dszkh9SG+bDyIj0JC0WTeRLFOYZeLWXXgbD2 uT13YVbU4/aoJ/d5YgyHBaUhYBM3gu9DBf8c1CncH9pznwkA4CUDUqAo75+vjolcZS5Z 9ZcbKqadJ6x7gk7qEBBYQPdyjmGXz0AEISc+5n98Cb1i4lEaaq6Z2Q5r0USihsXjfgvz 8pkLYzxoQ7UMm871N7/1mA4AKGumtHhaBrPV6dvv09Bhu2RuO9H2eaBym1WQXzUWkT3H 7Ckw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wtMn7t65kMJz+eTzLTQKzQOXJvOuHzL1YjxuYmRtEKs=; b=IQQ3cSx5CxMkwWwF/fv0xfUYg7GNWpqjqpmNZGYrlV2gwm8Mm2JwOlI5mZtMVHbC6+ /40HYxROBYfL8qpTWiutU5P29Xy7V2L8FB3Gw18MLlarVR7DahmoEgn2u2ngmTYEuHKn T8KBLWNg3fG5pkNLpI1mT1YtaWNjNyCU5s1Qlvwo0Q3i0rOB7CwYnK53cUE3VcNx0xwV GEku3e+dCDLOjm+PDcVLq0CIzM7l+IIVGjh0un0+JRaTtjcAbyYSVUSi95l7Nfob4jWK b0eeyypxqzadz5Gfexmun3qpWVQQHaWqAfifjPWzkF3FHxuf0rOR1dWqaQHHLuTuGu2N uzAw== X-Gm-Message-State: AMke39mgVk3phfi8UkZaIS2qR/rrIUZzWoVkTMpigrnUo1XIctPLGof30adWIfk/z7keT//QAsDLxTo+B7jGuQ== X-Received: by 10.176.25.29 with SMTP id v29mr4887551uag.157.1488399036544; Wed, 01 Mar 2017 12:10:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.2 with HTTP; Wed, 1 Mar 2017 12:10:05 -0800 (PST) In-Reply-To: <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> From: Mark Smith Date: Thu, 2 Mar 2017 07:10:05 +1100 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 20:10:39 -0000 On 2 March 2017 at 06:48, Brian E Carpenter w= rote: > On 02/03/2017 06:03, Iv=C3=A1n Arce wrote: >> El 1/3/17 a las 6:51, Lorenzo Colitti escribi=C3=B3: >> >>> >>> Another thing I think we should avoid is to remove the fixed 64 >>> barrier and open the door to having this debate again and again= , >>> once for every new IPv6-over-foo document and once for every ne= w >>> address configuration protocol (today we have SLAAC and DHCPv6, >>> who knows what we'll have in the future). >>> >>> >>> Which is why it time to get this right and saying it is now and >>> forever 64 isn't right. >>> >>> >>> Do you agree that a fixed boundary is useful or not? For 20 years the >>> standards have guaranteed that 64 bits of IIDs were available to hosts >>> that wanted to use them. If we make that barrier mobile, there will be >>> no guarantee in the standards any more. Who should be allowed to set th= e >>> boundary? An IPv6-over-foo document? An address configuration technolog= y >>> such as SLAAC? >> >> The last paragraph of section "2.5.1 Interface identifiers" in 4291 said= : >> >> The details of forming interface identifiers are defined in the >> appropriate "IPv6 over " specification, such as "IPv6 over >> Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]. >> >> The corresponding paragraph in rfc4291bis is: >> >> The details of forming interface identifiers are defined in other >> specifications, such as "Privacy Extensions for Stateless Address >> Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating >> Semantically Opaque Interface Identifiers with IPv6 Stateless Address >> Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in >> appropriate "IPv6 over " specifications, such as "IPv6 over >> Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T >> G.9959 Networks" [RFC7428]. The security and privacy considerations >> for IPv6 address generation is described in [RFC7721]. >> >> Don't you agree with that? > > Iv=C3=A1n, > > That is the basis for Alexandre's suggestion to simply drop the mention > of 64 from the architecture: because it's an implementation parameter. > With my Computer Scientist hat on, I think that's the right thing to do. > With my Pragmatist hat on, I think stating that /64 is recommended is > a more practical approach. "Anything that can be configured can be misconfigured." https://www.ietf.org/rfc/rfc5505.txt > Stating that it's required is plain wrong. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Mar 1 13:20:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0011296C4 for ; Wed, 1 Mar 2017 13:20:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eyENxZcksgJS for ; Wed, 1 Mar 2017 13:20:27 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA6F127076 for ; Wed, 1 Mar 2017 13:20:27 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id p5so24150637pga.1 for ; Wed, 01 Mar 2017 13:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=btOlQlU/2EZzHTEo8+k19WLbF6469exXy5BLzAl8C58=; b=aqDJavFLinc3gy9jd3gPLjd1V1TDjkSfVCBVyq3RriErgInF9/Hfhvsf33hlzI1YLx 1IvKlrCoEh/r516TjBk/vU7PcaL/kttTBMeTPUZ3jE7NsKFcwJNF0uI15uhMwMLK6oqm w07/R6Fp2CPohBGsJ3tx6TlwU9F94y0KxYtguY2RCmTQeTp1Sh4TmjqzWb+wCkxyVhW0 8MVx4qgkL6Puz+/6cZ5aI3EDtnVtzrpcTI/U/FQmh7LOhAjbVFkWs73wteRtYNunlv/i L0CI4YZDgO1gsdf4rXGp2HtGHiyWMjtEcnykE6JRcfnPuoAaSC0r/cZRdgI9dT4mFYjs k/Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=btOlQlU/2EZzHTEo8+k19WLbF6469exXy5BLzAl8C58=; b=HxcBZjcyu+6OycCFl+k3DEGQ3o3CV7UvRdEG+RmKTYRVSw3VjvCL49WzbeOzbkXnww YkBmzU5xr3fvt/zLLLs8WnUTatu/BAlRXp9L6e+NfTDrneN6XzqBIODSQYX7h4HRq2Vn C5s4uCCFDnP7VGJngULQVNrorq6brunvjfdIoe5Lo00oUs9XWHTw12nt9bMQKuoAdGTy wk+JEdL99jwWdnxuz2JMYgV9Kr5B7fSsu27DHVRuqEBJP6+iFrdBDtlYkhe2CPItalAt PiV6+pbUand16/yXghAkyAdKVU3h1cBS6BVMLtzlxqaqd97Qx3TFb/WIT9syZOCc3HZU aEuQ== X-Gm-Message-State: AMke39mZyZ2Bhn3ZVeOhswH77GHRxTBpGch0twe15icigaxdpxx4SrqH2L09m53wKDDviA== X-Received: by 10.99.199.69 with SMTP id v5mr11307845pgg.90.1488403227119; Wed, 01 Mar 2017 13:20:27 -0800 (PST) Received: from ?IPv6:2406:e007:6663:1:28cc:dc4c:9703:6781? ([2406:e007:6663:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q73sm12337938pfa.129.2017.03.01.13.20.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 13:20:26 -0800 (PST) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Alexandre Petrescu , =?UTF-8?Q?Dan_L=c3=bcdtke?= References: <20170223134026.GI5069@gir.theapt.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <92160C59-79EC-4EB0-BFD5-69697A5E1306@danrl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4ee56eb1-81f1-54bc-99ff-86aaa816aae5@gmail.com> Date: Thu, 2 Mar 2017 10:20:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 21:20:29 -0000 On 02/03/2017 08:47, Alexandre Petrescu wrote: >=20 >=20 > Le 01/03/2017 =C3=A0 12:23, Dan L=C3=BCdtke a =C3=A9crit : >> >>> On 28 Feb 2017, at 13:04, Alexandre Petrescu wrote: >>> >>> Finally, there is no advice of what bits to put between fe80:: and a >>> 64bit the Interface ID - zeros or ones? linux says it's a fe80::/64 = and >>> IIRC BSD says it's a fe80::/10. The routing entries based on that ca= n >>> make for interop problems. >> >> I think there is advice. As I understand, /10 is reserved but only /64= is specified. >=20 > Sorry, I dont understand that? >=20 > What is the difference? Why reserving X if only specifying Y? What=20 > other concept is similar: is there some other number which is reserved = > and only number+1 is specified? >=20 > Why couldnt we just reserve without specifying? Or specifying without = > reserving? >=20 > If we continue with reserving _and_ specifying we continue wasting thes= e=20 > 54bits there. >=20 > What are these 54bits for? Nothing. They are reserved and must be zero. That's quite common in=20 protocol design. Link-local is a special case, because it must be possible to create an address with absolutely no prior information. Brian >=20 > Alex >=20 >> >> >> RFC 4291 IP Version 6 Addressing Architecture >> 2.5.6. Link-Local IPv6 Unicast Addresses >> >> Link-Local addresses are for use on a single link. Link-Local >> addresses have the following format: >> >> | 10 | >> | bits | 54 bits | 64 bits = | >> +----------+-------------------------+---------------------------= -+ >> |1111111010| 0 | interface ID = | >> +----------+-------------------------+---------------------------= -+ >> >> >> Cheers, >> >> Dan >> >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Wed Mar 1 14:37:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E6F12950C for ; Wed, 1 Mar 2017 14:37:31 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ne-7wxt7eYOl for ; Wed, 1 Mar 2017 14:37:29 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EDB127ABE for ; Wed, 1 Mar 2017 14:37:28 -0800 (PST) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v21MbNBf069251 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2017 22:37:23 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58B74D22.5010104@foobar.org> Date: Wed, 01 Mar 2017 22:37:22 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.10 (Macintosh/20170123) MIME-Version: 1.0 To: Lorenzo Colitti Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 22:37:31 -0000 Lorenzo Colitti wrote: > Can you explain the difference between your reply and "we've been doing > it for 20 years therefore it must be the right thing to do"? > > The latter is a a) not a technical argument, and b) not a useful > argument if most of that operational knowledge was formed using IPv4. > Given that for most of the 1990s IPv6 had not been designed, much less > operationally deployed, I assume that you do indeed mean IPv4. Kindly stop throwing straw men into this discussion. This is extremely unhelpful and is not going to result in anything useful. Nick From nobody Wed Mar 1 15:07:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C91D129412 for ; Wed, 1 Mar 2017 15:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fundacionsadosky.org.ar 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 zxMCpTNgQVKa for ; Wed, 1 Mar 2017 15:07:55 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67AE3129578 for ; Wed, 1 Mar 2017 15:07:55 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id n127so96835210qkf.0 for ; Wed, 01 Mar 2017 15:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fundacionsadosky.org.ar; s=google; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=w4Leyv93zkFelbtA4/JbVMXC3O+xPi5FQfyDkHhEAb0=; b=L/YjZVF1JvrawGKsAKY6Ok/Lv8h2X927EdmqWV+8hYzNqVwvP3K8Ja+AocYmaiNdZG Fmy+JqqAqIlVWfhXRyjGC3U7RM8Daf235HbRoS691WQ6RR+ZncBeSpBN/Nsu2+4dCB1s xC2YNq9B4t/bVIdVByhxj//xTCaTYMsddRO1E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=w4Leyv93zkFelbtA4/JbVMXC3O+xPi5FQfyDkHhEAb0=; b=tKn6/aDRDQ35MTxcCdChbI252iPsF1ivFw8Zp0DZjPuTivlvLI078/yZ0R7bI/ZDId 7isOAaPRfpq/mcDBtdHsqv9hLkc8lGGtISFCz5tG1x9Bt2JPw8fgIZnH0B0R4Ski5wDF l7Pqkdu2Km6XkHWhiHaxpJMEAYk34+78n1kteuqKVac+bhR2ATR7N5V6zRcAE8HXzW0f 54UWi8eewHZGMxHM7w0A7lZNfcmlUlx+r2JMHeWhurMosXH+oyF18m9tyby6BJVFmw17 xbg/pINEtnC9osYnfXc9H/d1M4yctqlSHexndg3yMg4rz018rmV0xOkfkQjudqQcTuqB raGQ== X-Gm-Message-State: AMke39mY1jhsk8foJA6MoyOBwyPqm7H4x2Uw6BaLZAWNCq3oIMm+LIorTZwv2F1g5kVTDw== X-Received: by 10.200.34.144 with SMTP id f16mr14068101qta.186.1488409674160; Wed, 01 Mar 2017 15:07:54 -0800 (PST) Received: from [192.168.100.103] ([186.158.218.178]) by smtp.googlemail.com with ESMTPSA id f126sm4140640qkc.47.2017.03.01.15.07.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 15:07:53 -0800 (PST) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: 6man WG References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> From: =?UTF-8?Q?Iv=c3=a1n_Arce?= Organization: =?UTF-8?Q?Fundaci=c3=b3n_Dr._Manuel_Sadosky?= Message-ID: Date: Wed, 1 Mar 2017 20:07:50 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Lightning/4.7.7 MIME-Version: 1.0 In-Reply-To: <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 23:07:57 -0000 El 1/3/17 a las 16:48, Brian E Carpenter escribió: > On 02/03/2017 06:03, Iván Arce wrote: >> El 1/3/17 a las 6:51, Lorenzo Colitti escribió: >> >>> >>> Another thing I think we should avoid is to remove the fixed 64 >>> barrier and open the door to having this debate again and again, >>> once for every new IPv6-over-foo document and once for every new >>> address configuration protocol (today we have SLAAC and DHCPv6, >>> who knows what we'll have in the future). >>> >>> >>> Which is why it time to get this right and saying it is now and >>> forever 64 isn't right. >>> >>> >>> Do you agree that a fixed boundary is useful or not? For 20 years the >>> standards have guaranteed that 64 bits of IIDs were available to hosts >>> that wanted to use them. If we make that barrier mobile, there will be >>> no guarantee in the standards any more. Who should be allowed to set the >>> boundary? An IPv6-over-foo document? An address configuration technology >>> such as SLAAC? >> >> The last paragraph of section "2.5.1 Interface identifiers" in 4291 said: >> >> The details of forming interface identifiers are defined in the >> appropriate "IPv6 over " specification, such as "IPv6 over >> Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]. >> >> The corresponding paragraph in rfc4291bis is: >> >> The details of forming interface identifiers are defined in other >> specifications, such as "Privacy Extensions for Stateless Address >> Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating >> Semantically Opaque Interface Identifiers with IPv6 Stateless Address >> Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in >> appropriate "IPv6 over " specifications, such as "IPv6 over >> Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T >> G.9959 Networks" [RFC7428]. The security and privacy considerations >> for IPv6 address generation is described in [RFC7721]. >> >> Don't you agree with that? > > Iván, > > That is the basis for Alexandre's suggestion to simply drop the mention > of 64 from the architecture: because it's an implementation parameter. > With my Computer Scientist hat on, I think that's the right thing to do. > With my Pragmatist hat on, I think stating that /64 is recommended is > a more practical approach. Stating that it's required is plain wrong. > > Brian I agree. Either not mentioning /64 at all or just saying it is recommended but leaving the specifics to a "IPv6 over X" specification is better than bolting a fixed prefix len in the standard. Incidentally, I think this should have been deprecated in RFC 7136 when EUI-64 was (sortof) killed. -ivan -- Iván Arce Director del Programa STIC Fundación Dr. Manuel Sadosky http://www.fundacionsadosky.org.ar TE: (+54-11) 4328-5164 GPG fingerprint: 4D97 3003 76C9 9DA4 7209 7982 0A1D 10BE CEA9 1B6E From nobody Wed Mar 1 20:36:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815BF129492 for ; Wed, 1 Mar 2017 20:36:28 -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_PASS=-0.001] autolearn=ham autolearn_force=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 DnueC96uV2Lh for ; Wed, 1 Mar 2017 20:36:26 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BE012947C for <6man@ietf.org>; Wed, 1 Mar 2017 20:36:26 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C53BD8036F; Thu, 2 Mar 2017 05:36:22 +0100 (CET) Subject: IPv6 address usage recommendations (Fwd: New Version Notification for draft-gont-6man-address-usage-recommendations-01.txt) References: <148828249984.30681.13615226213384277314.idtracker@ietfa.amsl.com> To: "6man@ietf.org" <6man@ietf.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <148828249984.30681.13615226213384277314.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 2 Mar 2017 01:35:15 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148828249984.30681.13615226213384277314.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 04:36:28 -0000 Folks, FYI: Your feedback will be appreciated. Our plan is to publish yeat another rev soon, hopefully before the I-D submission cut-off. Thanks! Best regards, Fernando (and co-authors) -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-6man-address-usage-recommendations-01.txt Date: Tue, 28 Feb 2017 03:48:19 -0800 From: internet-drafts@ietf.org To: Fernando Gont , Madeleine Garcia Corbo , Madelen Corbo , Guillermo Gont A new version of I-D, draft-gont-6man-address-usage-recommendations-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-6man-address-usage-recommendations Revision: 01 Title: IPv6 Address Usage Recommendations Document date: 2017-02-28 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-gont-6man-address-usage-recommendations-01.txt Status: https://datatracker.ietf.org/doc/draft-gont-6man-address-usage-recommendations/ Htmlized: https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-6man-address-usage-recommendations-01 Abstract: This document analyzes the security and privacy implications of IPv6 addresses based on a number of properties such as address scope, stability, and usage type. It analyzes what properties are desirable for some popular scenarios, and provides advice regarding the configuration and usage of such addresses. 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 From nobody Wed Mar 1 21:10:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A927D1296F8 for ; Wed, 1 Mar 2017 21:10:05 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tHXR4i5xiLgN for ; Wed, 1 Mar 2017 21:10:04 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88261296D3 for ; Wed, 1 Mar 2017 21:10:02 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0E792801F3; Thu, 2 Mar 2017 06:09:59 +0100 (CET) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: =?UTF-8?Q?Iv=c3=a1n_Arce?= , 6man WG References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <084963a6-d68e-3a41-109e-90f4e9adb439@si6networks.com> Date: Thu, 2 Mar 2017 02:08:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 05:10:05 -0000 On 03/01/2017 02:03 PM, Iván Arce wrote: > El 1/3/17 a las 6:51, Lorenzo Colitti escribió: > >> >> Another thing I think we should avoid is to remove the fixed 64 >> barrier and open the door to having this debate again and again, >> once for every new IPv6-over-foo document and once for every new >> address configuration protocol (today we have SLAAC and DHCPv6, >> who knows what we'll have in the future). >> >> >> Which is why it time to get this right and saying it is now and >> forever 64 isn't right. >> >> >> Do you agree that a fixed boundary is useful or not? For 20 years the >> standards have guaranteed that 64 bits of IIDs were available to hosts >> that wanted to use them. If we make that barrier mobile, there will be >> no guarantee in the standards any more. Who should be allowed to set the >> boundary? An IPv6-over-foo document? An address configuration technology >> such as SLAAC? > > The last paragraph of section "2.5.1 Interface identifiers" in 4291 said: > > The details of forming interface identifiers are defined in the > appropriate "IPv6 over " specification, such as "IPv6 over > Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]. > > The corresponding paragraph in rfc4291bis is: > > The details of forming interface identifiers are defined in other > specifications, such as "Privacy Extensions for Stateless Address > Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating > Semantically Opaque Interface Identifiers with IPv6 Stateless Address > Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in > appropriate "IPv6 over " specifications, such as "IPv6 over > Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T > G.9959 Networks" [RFC7428]. The security and privacy considerations > for IPv6 address generation is described in [RFC7721]. > > Don't you agree with that? To add to what Ivan said, the only text in the "IPv6 over " documents that has anything to do with the 64-bit IIDs is the description of how to come up with Modified-EUI64 identifiers. RFC7217, the recommended algorithm for forming IIDs, does not employ Modified EUI64 format identifiers, and formally updates all such RFCs. For instance, RFC7217 explicitly says: 2. The Interface Identifier is finally obtained by taking as many bits from the RID value (computed in the previous step) as necessary, starting from the least significant bit. We note that [RFC4291] requires that the Interface IDs of all unicast addresses (except those that start with the binary value 000) be 64 bits long. However, the method discussed in this document could be employed for generating Interface IDs of any arbitrary length, albeit at the expense of reduced entropy (when employing Interface IDs smaller than 64 bits). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Mar 2 00:11:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19425129469 for ; Thu, 2 Mar 2017 00:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 iaiM59Q7luzw for ; Thu, 2 Mar 2017 00:11:29 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36E512941E for ; Thu, 2 Mar 2017 00:11:25 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v228BNxv003781; Thu, 2 Mar 2017 09:11:23 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B36B42036A1; Thu, 2 Mar 2017 09:11:23 +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 A630C203310; Thu, 2 Mar 2017 09:11:23 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v228BN4i024217; Thu, 2 Mar 2017 09:11:23 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: Mikael Abrahamsson References: <20170223134026.GI5069@gir.theapt.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 2 Mar 2017 09:11:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:11:31 -0000 Le 01/03/2017 à 20:53, Mikael Abrahamsson a écrit : > On Wed, 1 Mar 2017, Alexandre Petrescu wrote: > >> For information, today on linux a /65 RA is called "illegal" and a >> /63 RA makes a Host to _not_ configure an address. What linux >> wants is a 64 and nothing else. This is not normal, and it's not >> programmer's fault. > > Could you please elaborate on the last sentence. What do you mean by > "not normal"? It is not normal for linux kernel to complain about a plen==65 in the RA - it should not complain. Do you think it is normal? It is not normal for a linux kernel to _not_ form an IPv6 address when it receives a plen==63. It would have been normal to append the IID to it. Do you think it is abnormal for a linux kernel to form an IPv6 address when it receives a plen==63? Alex > From nobody Thu Mar 2 00:23:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7172112941E for ; Thu, 2 Mar 2017 00:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 kQjGnBAv7BGz for ; Thu, 2 Mar 2017 00:23:06 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F62012942F for ; Thu, 2 Mar 2017 00:15:16 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id s15so28245880ywg.0 for ; Thu, 02 Mar 2017 00:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pLCA0oEKHK3JLGo/U4QHIphsD0OWbEA+wJQxoM0s7vg=; b=dq/6AnCdBdPxgcuhuF6Lq68AqLo48oSFs6lr8iiGU0Bh0EZtDtA/PSbznJ9bRP0JN1 F8NehcYKnLhXrYN9jeZXcPykaNL8haWFc0P/pu7vtHIOllJFDFGHWLos06N2w9yIoTpY iSyrVXJEVrXoG9/+39MjJxvx0JdbMBS0ufK+7xyNIBG7TWwhVoXIunwLbBbI75iqe5XJ B9MM8G572JaSPRwztmY1c/LY+4aVovWYGfvB3gw/JuRG9YYez7U1hZg1b39hpfmYg2sA ozUsbvm9PvVI4CYCq7czALwgf4jDKcxq7caJQjzPcfZO2SNhYe/TqrcO4XM3iOreqXo+ GKKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pLCA0oEKHK3JLGo/U4QHIphsD0OWbEA+wJQxoM0s7vg=; b=CRIQcN1f2ZtpJ4ebdCJ5tYgLc8qdzl7KMHU303gPWVzn3oy8HMSuFLQFDt1w2TIMJX 81nc1ZHQ530QiM4s2zTUjymybtpVrasS7em51MyTOwGamscGa1PEbFRTVEZEYrhz/msy Vf54YkR9gqk/kNzHOEH/Lfrqv+3sDbJAJzI8+IRt5FY1ryCgd32D2iaMcqnUQsB0TX3m lw6i6Rd0H/fnEwo5w58Ekyvw5qwRx5uOAqPl7F7hZdYrt8PwGBIS7jBt10ehN5ZdA8/E YIO+JhpzarFlZrt1m7H73VKMz+ioNchdUqMGirs3bgH2BTfa0K2TivDfy0jY8+lPtGOt 7Qwg== X-Gm-Message-State: AMke39lp4vfdAFHazlaiRJqN5MI/ZGryUTu76CFd09u/dtopturObKuf8vWjPfI7ytmIWVP6PbjONR2i2kxsxEzW X-Received: by 10.129.41.69 with SMTP id p66mr4024273ywp.223.1488442515166; Thu, 02 Mar 2017 00:15:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.4 with HTTP; Thu, 2 Mar 2017 00:14:54 -0800 (PST) In-Reply-To: References: <20170223134026.GI5069@gir.theapt.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> From: Erik Kline Date: Thu, 2 Mar 2017 17:14:54 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: Alexandre Petrescu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114160ba6b36e40549bb07f9" Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:23:07 -0000 --001a114160ba6b36e40549bb07f9 Content-Type: multipart/alternative; boundary=001a114160ba62f29c0549bb0740 --001a114160ba62f29c0549bb0740 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 March 2017 at 17:11, Alexandre Petrescu wrote: > > > Le 01/03/2017 =C3=A0 20:53, Mikael Abrahamsson a =C3=A9crit : > >> On Wed, 1 Mar 2017, Alexandre Petrescu wrote: >> >> For information, today on linux a /65 RA is called "illegal" and a >>> /63 RA makes a Host to _not_ configure an address. What linux >>> wants is a 64 and nothing else. This is not normal, and it's not >>> programmer's fault. >>> >> >> Could you please elaborate on the last sentence. What do you mean by >> "not normal"? >> > > It is not normal for linux kernel to complain about a plen=3D=3D65 in the= RA > - it should not complain. Do you think it is normal? > > It is not normal for a linux kernel to _not_ form an IPv6 address when > it receives a plen=3D=3D63. It would have been normal to append the IID = to > it. Do you think it is abnormal for a linux kernel to form an IPv6 > address when it receives a plen=3D=3D63? > These statements have zero basis in fact. The Linux kernel is behaving according to all currently available (proposed) standards. --001a114160ba62f29c0549bb0740 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 March 2017 at 17:11, Alexandre Petrescu <alexandre.pet= rescu@gmail.com> wrote:


Le 01/03/2017 =C3=A0 20:53, Mikael Abrahamsson a =C3=A9crit :
On Wed, 1 Mar 2017, Alexandre Petrescu wrote:

For information, today on linux a /65 RA is called "illegal" and = a
/63 RA makes a Host to _not_ configure an address.=C2=A0 What linux
wants is a 64 and nothing else.=C2=A0 This is not normal, and it's not<= br> programmer's fault.

Could you please elaborate on the last sentence. What do you mean by
"not normal"?

It is not normal for linux kernel to complain about a plen=3D=3D65 in the R= A
- it should not complain.=C2=A0 Do you think it is normal?

It is not normal for a linux kernel to _not_ form an IPv6 address when
it receives a plen=3D=3D63.=C2=A0 It would have been normal to append the I= ID to
it.=C2=A0 Do you think it is abnormal for a linux kernel to form an IPv6 address when it receives a plen=3D=3D63?


These statements have zero basis in fact.=C2=A0 The Linux = kernel is behaving according to all currently available (proposed) standard= s.
--001a114160ba62f29c0549bb0740-- --001a114160ba6b36e40549bb07f9 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgWFSPSuA79Yu3LwaE81mPZR4je+4UxXiM ENS4hDu7cuIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzAy MDgxNTE1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBALeV31kX70gAVNcD+4vr4IiXGCQdB4AhiaBvVF7n5thdiZjmcZET XOBr1mwo8JnGjnAGErB8CG/sv9yfq4heIwVtNdQB78/57ZFaJaPuxfiW6r2+itly5kpXboglmFGu zbVnYSmy6h9q1ej3eVrAfFllpdVpUwPe0DL1woYyw4DuZ/V7ZC2TGbgFPg3e77hEct/tpz2oY5vg eh2JePDBtaTkA6s3OSVOVzR3S3WoOfeeI74upCSRuGEeAqu+xh6p5uTtHNiqHf7uTC5oQpGaat5C aw6AcBc09Er0npE4l6YKNFM0Y2I2q9ifuBbwZK0xRZESA5+JQZk8BziP6dAw3SI= --001a114160ba6b36e40549bb07f9-- From nobody Thu Mar 2 00:24:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843DF1294B2 for ; Thu, 2 Mar 2017 00:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 AkmgV1vKkF7M for ; Thu, 2 Mar 2017 00:24:19 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21401294AE for ; Thu, 2 Mar 2017 00:24:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v228O898010850; Thu, 2 Mar 2017 09:24:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5E483200ED5; Thu, 2 Mar 2017 09:24:08 +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 4E51E200B5D; Thu, 2 Mar 2017 09:24:08 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v228O7WJ032302; Thu, 2 Mar 2017 09:24:08 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Brian E Carpenter , =?UTF-8?Q?Dan_L=c3=bcdtke?= References: <20170223134026.GI5069@gir.theapt.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <92160C59-79EC-4EB0-BFD5-69697A5E1306@danrl.com> <4ee56eb1-81f1-54bc-99ff-86aaa816aae5@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 2 Mar 2017 09:24:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <4ee56eb1-81f1-54bc-99ff-86aaa816aae5@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:24:20 -0000 Le 01/03/2017 à 22:20, Brian E Carpenter a écrit : > On 02/03/2017 08:47, Alexandre Petrescu wrote: >> >> >> Le 01/03/2017 à 12:23, Dan Lüdtke a écrit : >>> >>>> On 28 Feb 2017, at 13:04, Alexandre Petrescu >>>> wrote: >>>> >>>> Finally, there is no advice of what bits to put between fe80:: >>>> and a 64bit the Interface ID - zeros or ones? linux says it's >>>> a fe80::/64 and IIRC BSD says it's a fe80::/10. The routing >>>> entries based on that can make for interop problems. >>> >>> I think there is advice. As I understand, /10 is reserved but >>> only /64 is specified. >> >> Sorry, I dont understand that? >> >> What is the difference? Why reserving X if only specifying Y? >> What other concept is similar: is there some other number which is >> reserved and only number+1 is specified? >> >> Why couldnt we just reserve without specifying? Or specifying >> without reserving? >> >> If we continue with reserving _and_ specifying we continue wasting >> these 54bits there. >> >> What are these 54bits for? > > Nothing. They are reserved and must be zero. That's quite common in > protocol design. If so, then it's not a fe80::/10, but an fe80::/64, and we should refrain from writing fe80::/10 anywhere. Which brings back the question of why 64? > Link-local is a special case, because it must be possible to create > an address with absolutely no prior information. I agree, an LL should be created w/o prior info coming out of the computer. But, among other requirements, that address should have less privacy issues too. In an LL a longer IID (e.g. a 108bit IID) would have better privacy characteristics than a 64bit IID - resist longer to brute force attacks. By the fe80::/10 definition it is allowed to set a 108bit IID in LL, but by fe80::/64 definition it is not. In other settings with less computers on a subnet (less privacy concerns), or less interfaces on a computer (IoT), an IID of length 1 for a LL address would be sufficient, which would make an fe80::/127 relevant as well. Why must they support fe80::/64 when they dont need that much? These questions are all the more important when knowing that many IP stacks make these numerous fe80::/64 entries in the rt table, by default. In IPv4 computers their rt table is a clean slate after boot... no need to clean. Alex > > Brian > >> >> Alex >> >>> >>> >>> RFC 4291 IP Version 6 Addressing Architecture 2.5.6. Link-Local >>> IPv6 Unicast Addresses >>> >>> Link-Local addresses are for use on a single link. Link-Local >>> addresses have the following format: >>> >>> | 10 | | bits | 54 bits | 64 >>> bits | >>> +----------+-------------------------+----------------------------+ >>> >>> |1111111010| 0 | interface ID | >>> +----------+-------------------------+----------------------------+ >>> >>> >>> >>> Cheers, >>> >>> Dan >>> >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > >> > From nobody Thu Mar 2 00:30:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173E9129469 for ; Thu, 2 Mar 2017 00:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 pTCDOaz4QHHM for ; Thu, 2 Mar 2017 00:29:59 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F8A129459 for ; Thu, 2 Mar 2017 00:29:58 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v228Tug8013843; Thu, 2 Mar 2017 09:29:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8CD36203B9A; Thu, 2 Mar 2017 09:29:56 +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 7CFC8203B83; Thu, 2 Mar 2017 09:29:56 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v228Tu5t006729; Thu, 2 Mar 2017 09:29:56 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: Erik Kline References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 2 Mar 2017 09:30:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:30:00 -0000 Le 02/03/2017 à 09:14, Erik Kline a écrit : > > > On 2 March 2017 at 17:11, Alexandre Petrescu > > wrote: > > > > Le 01/03/2017 à 20:53, Mikael Abrahamsson a écrit : > > On Wed, 1 Mar 2017, Alexandre Petrescu wrote: > > For information, today on linux a /65 RA is called "illegal" > and a > /63 RA makes a Host to _not_ configure an address. What linux > wants is a 64 and nothing else. This is not normal, and > it's not > programmer's fault. > > > Could you please elaborate on the last sentence. What do you mean by > "not normal"? > > > It is not normal for linux kernel to complain about a plen==65 in the RA > - it should not complain. Do you think it is normal? > > It is not normal for a linux kernel to _not_ form an IPv6 address when > it receives a plen==63. It would have been normal to append the IID to > it. Do you think it is abnormal for a linux kernel to form an IPv6 > address when it receives a plen==63? > > > > These statements have zero basis in fact. The Linux kernel is behaving > according to all currently available (proposed) standards. Well... do you have a standard for IPv6 over cellular links? Or IPv6 over USB? I dont. And I consider linux to act wrongly when being sent an RA plen==65 on these links and refusing them as "illegal". I think it should not refuse it on Ethernet either, but there you have a standard RFC2464. And for that I agree with you. Even though it should be perfectly fine to use that plen==65 to have an entry in the rt table, and use a manually configured address in that plen. I dont have a standard that tells that the computer is forbidden from introducing a 0 between 63 and 64 such that the plen==63 plus IID==64 make for 128. Alex From nobody Thu Mar 2 00:32:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F62C129469 for ; Thu, 2 Mar 2017 00:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no autolearn_force=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 TgbzgnMlyqKV for ; Thu, 2 Mar 2017 00:32:19 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EB4129459 for ; Thu, 2 Mar 2017 00:32:19 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 99E54801BD; Thu, 2 Mar 2017 09:32:15 +0100 (CET) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Brian E Carpenter , =?UTF-8?Q?Iv=c3=a1n_Arce?= , 6man WG References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> From: Fernando Gont Message-ID: Date: Thu, 2 Mar 2017 02:10:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:32:21 -0000 On 03/01/2017 04:48 PM, Brian E Carpenter wrote: > On 02/03/2017 06:03, Iván Arce wrote: >> El 1/3/17 a las 6:51, Lorenzo Colitti escribió: >> >>> >>> Another thing I think we should avoid is to remove the fixed 64 >>> barrier and open the door to having this debate again and again, >>> once for every new IPv6-over-foo document and once for every new >>> address configuration protocol (today we have SLAAC and DHCPv6, >>> who knows what we'll have in the future). >>> >>> >>> Which is why it time to get this right and saying it is now and >>> forever 64 isn't right. >>> >>> >>> Do you agree that a fixed boundary is useful or not? For 20 years the >>> standards have guaranteed that 64 bits of IIDs were available to hosts >>> that wanted to use them. If we make that barrier mobile, there will be >>> no guarantee in the standards any more. Who should be allowed to set the >>> boundary? An IPv6-over-foo document? An address configuration technology >>> such as SLAAC? >> >> The last paragraph of section "2.5.1 Interface identifiers" in 4291 said: >> >> The details of forming interface identifiers are defined in the >> appropriate "IPv6 over " specification, such as "IPv6 over >> Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]. >> >> The corresponding paragraph in rfc4291bis is: >> >> The details of forming interface identifiers are defined in other >> specifications, such as "Privacy Extensions for Stateless Address >> Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating >> Semantically Opaque Interface Identifiers with IPv6 Stateless Address >> Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in >> appropriate "IPv6 over " specifications, such as "IPv6 over >> Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T >> G.9959 Networks" [RFC7428]. The security and privacy considerations >> for IPv6 address generation is described in [RFC7721]. >> >> Don't you agree with that? > > Iván, > > That is the basis for Alexandre's suggestion to simply drop the mention > of 64 from the architecture: because it's an implementation parameter. > With my Computer Scientist hat on, I think that's the right thing to do. > With my Pragmatist hat on, I think stating that /64 is recommended is > a more practical approach. Stating that it's required is plain wrong. +1 Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Mar 2 00:32:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99C71294AC for ; Thu, 2 Mar 2017 00:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 thhb7SHxqMRx for ; Thu, 2 Mar 2017 00:32:28 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697F71296C8 for ; Thu, 2 Mar 2017 00:32:27 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 67D6B8035F; Thu, 2 Mar 2017 09:32:20 +0100 (CET) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: =?UTF-8?Q?Iv=c3=a1n_Arce?= , 6man WG References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 2 Mar 2017 02:15:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:32:29 -0000 On 03/01/2017 08:07 PM, Iván Arce wrote: [....] > > Either not mentioning /64 at all or just saying it is recommended but > leaving the specifics to a "IPv6 over X" specification is better than > bolting a fixed prefix len in the standard. > > Incidentally, I think this should have been deprecated in RFC 7136 when > EUI-64 was (sortof) killed. Modified EUI-64 should have been killed a long time ago. But Lorenzo has been very loud in keeping that flawed approach alive. For instance, RFC8064 recommends against its use for stable addresses, but leaves the door open for employing Modified EUI-64 if the underlying link-layer address has been randomized -- a scheme that is still flawed because, among other things, it unnecessarily wastes 18 bits of entropy and follows a well-known bad practice of re-using numeric IDs across different layers and contexts. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Mar 2 00:46:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4251294AC for ; Thu, 2 Mar 2017 00:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 siRd51M4btGs for ; Thu, 2 Mar 2017 00:46:45 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA97129459 for ; Thu, 2 Mar 2017 00:46:45 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 72so68753116uaf.3 for ; Thu, 02 Mar 2017 00:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4vI9EfmziKy6v4Tpeb/clwN8b2/nSi+uNLtZJvq9kCY=; b=qHgGeOt/DhXIfSmbCrRznLxxA7gDUkWbSoSlzst+On4/1sVu1fwNxd1UzigP4w/be3 00PgOh7/e4ZEcvJgmP+lkG4Xmi4ea3EMMxgTUy2hN/fluPTvRiTeWu8GfQsfAv/Dpk7w EERW+p5mNtfNbca+b9eaKgSGQkf/IkMVfdcBpeZ5fNnt4/v/iMST1+erhDPmUh/2Wb94 /P0eawvHsOaOmiJx7f/iO9+tXCiSnbVjDnIv50Xci760pIbwoftIpa0IRFediE371DnS jdVKzMJZj0b6WB+cY0L+RBLq2UABcQ810MCl4sqIMShL3vhoyugLlx9tbthgyfcBQI1Y CmAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4vI9EfmziKy6v4Tpeb/clwN8b2/nSi+uNLtZJvq9kCY=; b=SxkuS0STHP3d6oN7WdvFPyDY4v8dwDQwdK8ID2VBaX0Cm+f9QjYqS+70JLY49kRZH6 5/0GUDNVI3GNJibjm6hHL/9JeOlvaiU0iu0jGObRzFFPP+9zVS4oLmE8wSUd74rmUqTz Lbn1dvSH2hfuB112l035YGuBhIzNOqszBk0ZAg0w2DPdNtdTEZapOqbDRB9ixG/YW7cZ tH/ka9vFJRPgor0rwCBs9KQ8OqLrW7mT0ukZMFJQR/g9Oasfa8g8iRGHgcFiHPWcg6ZA 7fK+hNiH0T6O3KMbGfYMi5GA/tyubc1mnXIJQoA6kIUBtV4vn6mbqiydzJNWkARvkCVt NVYA== X-Gm-Message-State: AMke39mH4Tp1Yw0SuelpCIFKClffQr6LtDlMmeApTuTedbSMHMEYa9/Rh8yDprnIhCykQauW2JBWqWvzgHi9ie2G X-Received: by 10.159.40.202 with SMTP id d68mr6514204uad.122.1488444404397; Thu, 02 Mar 2017 00:46:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 00:46:23 -0800 (PST) In-Reply-To: <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> From: Lorenzo Colitti Date: Thu, 2 Mar 2017 17:46:23 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: =?UTF-8?Q?Iv=C3=A1n_Arce?= Content-Type: multipart/alternative; boundary=94eb2c12382efe88680549bb7765 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:46:47 -0000 --94eb2c12382efe88680549bb7765 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 2, 2017 at 2:03 AM, Iv=C3=A1n Arce wrote: > The last paragraph of section "2.5.1 Interface identifiers" in 4291 said: > > The details of forming interface identifiers are defined in the > appropriate "IPv6 over " specification, such as "IPv6 over > Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]. > > The corresponding paragraph in rfc4291bis is: > > The details of forming interface identifiers are defined in other > specifications, such as "Privacy Extensions for Stateless Address > Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating > Semantically Opaque Interface Identifiers with IPv6 Stateless Address > Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in > appropriate "IPv6 over " specifications, such as "IPv6 over > Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T > G.9959 Networks" [RFC7428]. The security and privacy considerations > for IPv6 address generation is described in [RFC7721]. > > Don't you agree with that? > Sure, but that text only specifies the details of how the IIDs are formed, not how long they are. Right now they are all 64 bits long because other text in RFC 4291 says that they are. --94eb2c12382efe88680549bb7765 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 2, 2017 at 2:03 AM, Iv=C3=A1n Arce <iarce@fundacionsad= osky.org.ar> wrote:
The last paragraph of section "2.5.1 Interface identi= fiers" in 4291 said:

=C2=A0 =C2=A0The details of forming interface identifiers are defined in th= e
=C2=A0 =C2=A0appropriate "IPv6 over <link>" specification, = such as "IPv6 over
=C2=A0 =C2=A0Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI].=

The corresponding paragraph in rfc4291bis is:

=C2=A0 =C2=A0The details of forming interface identifiers are defined in ot= her
=C2=A0 =C2=A0specifications, such as "Privacy Extensions for Stateless= Address
=C2=A0 =C2=A0Autoconfiguration in IPv6" [RFC4941] or "A Method fo= r Generating
=C2=A0 =C2=A0Semantically Opaque Interface Identifiers with IPv6 Stateless = Address
=C2=A0 =C2=A0Autoconfiguration (SLAAC)"[RFC7217].=C2=A0 Specific cases= are described in
=C2=A0 =C2=A0appropriate "IPv6 over <link>" specifications,= such as "IPv6 over
=C2=A0 =C2=A0Ethernet" [RFC2464] and "Transmission of IPv6 Packet= s over ITU-T
=C2=A0 =C2=A0G.9959 Networks" [RFC7428].=C2=A0 The security and privac= y considerations
=C2=A0 =C2=A0for IPv6 address generation is described in [RFC7721].

Don't you agree with that?

Sure, bu= t that text only specifies the details of how the IIDs are formed, not how = long they are. Right now they are all 64 bits long because other text in RF= C 4291 says that they are.
--94eb2c12382efe88680549bb7765-- From nobody Thu Mar 2 00:54:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22C51294BB for ; Thu, 2 Mar 2017 00:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 2TcW36Y5TFf9 for ; Thu, 2 Mar 2017 00:54:22 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9611294AC for ; Thu, 2 Mar 2017 00:54:22 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id q7so37185785uaf.2 for ; Thu, 02 Mar 2017 00:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=paOvnAAh+hUBOIb3ldkgqIpKpM/VpEmQVP3HUFH7oV8=; b=YY7uU5AkVaQ/EgkjnBj/KYgrNTCAVa0ZEY/3oVL1Ay1p8gPxby4oVeycBAeTjwPWgC caOo01wlHnjfoL2/NgPcGZWNNjdm85E4CUsHrpD28Mho+ZOMGDUHaOGuZplO11HMRbqT H8CLXE6YRodnpNT6lrrMivkol+6RcvORtxywaHx4XU4hX70UNh64mBPOM2HQyKXJ2aCY eI+V0HwnNwTUTxN4ZEfeCF/41Uq5nImuaiwGp/k/+lfbIt1WDWLx4t1BZJ3WTM40Uwz3 bsK7uMLMOLiUSgB8MqQniQpBr3idq1ckkFiXw+rF065vZlV9AbVrwClOk/9sBDlNBM9Q 7wnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=paOvnAAh+hUBOIb3ldkgqIpKpM/VpEmQVP3HUFH7oV8=; b=tkB5EoEHd686vE1/XxZ8GJnIfpwwiSqzHT4utCL7wEsVKOsMeYpNxJQ3nI4gKsde0H jkRDwyQT8STyqC5h6y9/vULUmuzvAqLinjSdSli+sIbUd+R06vMdJd0x1HC/YBwgVW6+ a0iOYY1VLapEZ7QJSd+R7i6/80CtszyAambc/1YxdWJLOOESHM9DWPno9vGDAETgJevl 9rIWk+m6xuhV/kdhzgPHbH+HLo0bw1kYSgxW3vlEeIz4h8U303y1Q7NQKZIfVfd58Rz1 qV+jC0+Lri8Gv+mMC6k47prdBqSpftMxkBTKd/bc42f033izJHy9KRl9DapNSQK1A5cB mjmA== X-Gm-Message-State: AMke39kPjGDBns6rhCaulHhOEbvSWZr2O1kTf6yLkBgSoZByy2B6GndyOAyBx3ibP5G2jf+sVXSmzM9K9+zM44Xj X-Received: by 10.176.2.71 with SMTP id 65mr3497673uas.155.1488444861159; Thu, 02 Mar 2017 00:54:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 00:54:00 -0800 (PST) In-Reply-To: <58B74D22.5010104@foobar.org> References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> <58B74D22.5010104@foobar.org> From: Lorenzo Colitti Date: Thu, 2 Mar 2017 17:54:00 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a11428a3638367b0549bb9329 Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:54:24 -0000 --001a11428a3638367b0549bb9329 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 7:37 AM, Nick Hilliard wrote: > > Can you explain the difference between your reply and "we've been doing > > it for 20 years therefore it must be the right thing to do"? > > > > The latter is a a) not a technical argument, and b) not a useful > > argument if most of that operational knowledge was formed using IPv4. > > Given that for most of the 1990s IPv6 had not been designed, much less > > operationally deployed, I assume that you do indeed mean IPv4. > > Kindly stop throwing straw men into this discussion. This is extremely > unhelpful and is not going to result in anything useful. > Let me rephrase the question. I asked for use cases for longer-than-/64 prefixes and listed the ones I have seen so far: - "I only need 3 addresses" (but not "I only need 3 addresses and here's why I can't accept 2^64 instead of 3") - ND exhaustion attacks Do you have additional use cases? "This is the way we've done it for 20 years" is not a use case. --001a11428a3638367b0549bb9329 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 2, 2017 at 7:37 AM, Nick Hilliard <nick@foobar.org> wr= ote:
> Can you explain the difference between your reply and "we&#= 39;ve been doing
> it for 20 years therefore it must be the right thing to do"?
>
> The latter is a a) not a technical argument, and b) not a useful
> argument if most of that operational knowledge was formed using IPv4.<= br> > Given that for most of the 1990s IPv6 had not been designed, much less=
> operationally deployed, I assume that you do indeed mean IPv4.

Kindly stop throwing straw men into this discussion.=C2=A0 This is e= xtremely
unhelpful and is not going to result in anything useful.

Let me rephrase the question. I asked for use cases for l= onger-than-/64 prefixes and listed the ones I have seen so far:
<= ul>
  • "I only need 3 addresses" (but not "I only need 3 add= resses and here's why I can't accept 2^64 instead of 3")
  • ND exhaustion attacks
    • Do you have additional= use cases? "This is the way we've done it for 20 years" is n= ot a use case.
    --001a11428a3638367b0549bb9329-- From nobody Thu Mar 2 00:57:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BA81294BB for ; Thu, 2 Mar 2017 00:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 nxr8CEtN-NcP for ; Thu, 2 Mar 2017 00:57:23 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D303F1294AC for ; Thu, 2 Mar 2017 00:57:22 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id q7so37256480uaf.2 for ; Thu, 02 Mar 2017 00:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KnpzPrwYLvfCEMZCgNP0ZXC5dW7BnD1uJML0+ou/uiU=; b=j/rezlFlXq0Bo903XJ3z5pd5riv2uDct9OiiwgUHcCKGHUI0A4YbEJeK6V+D4MzQNE PpzVEB5yqu+uP6zI40XVEVdHnrEM25mBgrMn2FxBdkPbZmLH/cdTyIvJClpIY9Izya6V zujt1I7+lmMMk4JEUBP3xsqLextGTULbTLBxrbO1HiQE6D6tISkHXbMhS9iRG0RrYLvh I6xuLTk90jJNkETV2rs2TvKVWmh+eiPgJrExcG5VTVv98Bon8zKM4xRYYKEluEesLVNz XvUoJDEGy/Cpjl0UOkhJFcdmkVEPUR2BAET2BUsJGuC3OvCzT16VeXYooIxY0b0Y8uyM lIkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KnpzPrwYLvfCEMZCgNP0ZXC5dW7BnD1uJML0+ou/uiU=; b=hDIRHXFw4EKbJKiXB3xRcjFoRzXOarXXfe9WPUH/nWAoEe3BM/mRF0CDEeSRr0VXmF nmsm3lCkUrXomn2MmLtzjEGwjcbNpWFkuuqm0yAymgfBK1EY/b0m/Fc3JqxnBkCtYXCI 6KCOMqgEcKaC7ZTL2Z4dRDy+yR9/b7iEx4yQizc+8VkPWyMLGfChTzWVb9ntchX4JKX3 kBKndnjh6r148NV4rjhmfHuUzLVkufuDL+eOPj+AIQrG7Tsrhnixqon7pAC22Aa3Ujkm l/w1YpzBTweK5qTzCGumpresQBjKvBeS6GPXMF3Gfy7Q2XHpAKlF29tCx8mFNCmDo2S9 h9vA== X-Gm-Message-State: AMke39lWu591z2p97mm5gUWS3Ko0pmoBLAtYoOLcv7Dze+Ti9ZSZn/SNPTpPn86qqxkzLITEdl6DTwoJ/jvmaGyu X-Received: by 10.176.1.5 with SMTP id 5mr5421486uak.30.1488445041737; Thu, 02 Mar 2017 00:57:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 00:57:00 -0800 (PST) In-Reply-To: References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> From: Lorenzo Colitti Date: Thu, 2 Mar 2017 17:57:00 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Fernando Gont Content-Type: multipart/alternative; boundary=001a113d058cfb53780549bb9ded Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:57:24 -0000 --001a113d058cfb53780549bb9ded Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 2:15 PM, Fernando Gont wrote: > among other things, it unnecessarily wastes 18 bits of entropy > If you ever want that argument to be convincing you'll need to explain by how much the additional 18 bits of entropy benefit real users in realistic situations. --001a113d058cfb53780549bb9ded Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Mar 2, 2017 at 2:15 PM, Fernando Gont <fgont@si6networks.com&g= t; wrote:
    among other things, it u= nnecessarily wastes 18 bits of entropy

    = If you ever want that argument to be convincing you'll need to explain = by how much the additional 18 bits of entropy benefit real users in realist= ic situations.
    --001a113d058cfb53780549bb9ded-- From nobody Thu Mar 2 01:31:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39C51294BB for ; Thu, 2 Mar 2017 01:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 6c_PF71ozJaR for ; Thu, 2 Mar 2017 01:31:11 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A47129459 for ; Thu, 2 Mar 2017 01:31:10 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D6C04A5; Thu, 2 Mar 2017 10:31:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1488447067; bh=p2fkus0mxcFjpquHGinPpZsZdtpQiXBNOsEOhec9xkc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TYCg/VHc19pp/Ukf+N5SW0+l9D3pwlPlsk3OGUFSucjqHH47BQSNJm30oEW93zUSg avER6lvejsYxWVBY2wl2mk/gCC4rbk4y4GZeoT6R+ki+uxBUkZaeOjHdTMpbPcg3Ay /VkJibVEb/fghr50KTgFiiLMEmxHN6QTfrhCQcCg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D349DA4; Thu, 2 Mar 2017 10:31:07 +0100 (CET) Date: Thu, 2 Mar 2017 10:31:07 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux In-Reply-To: Message-ID: References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.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; charset=US-ASCII; format=flowed Archived-At: Cc: Erik Kline , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 09:31:13 -0000 On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > perfectly fine to use that plen==65 to have an entry in the rt table, and use > a manually configured address in that plen. Linux does the right thing in not autoconfiguring itself address(es) when plen isn't 64. However, what does it do when it receives an PIO with plen of 65 and M=1 and then it gets an IA_NA and configures that on the interface? Doesn't it install the /65 in the routing table? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 2 01:44:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAC21294BF for ; Thu, 2 Mar 2017 01:44:09 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 r3bQOFX4-Q84 for ; Thu, 2 Mar 2017 01:44:07 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E20129459 for ; Thu, 2 Mar 2017 01:44:06 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9E01B8035F; Thu, 2 Mar 2017 10:44:02 +0100 (CET) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Lorenzo Colitti References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <9e211ff7-91df-a246-a2da-8da040ec8b28@si6networks.com> Date: Thu, 2 Mar 2017 06:39:59 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 09:44:09 -0000 On 03/02/2017 05:57 AM, Lorenzo Colitti wrote: > On Thu, Mar 2, 2017 at 2:15 PM, Fernando Gont > wrote: > > among other things, it unnecessarily wastes 18 bits of entropy > , and> > If you ever want that argument to be convincing you'll need to explain > by how much the additional 18 bits of entropy benefit real users in > realistic situations. It's the other way around: if you are randomizing IDs for the sake of privacy, you should make an argument for wasting 18 bits (other than "I do it because I can"). You should also make an argument for reusing IDs in different layers and contexts, something that is known to be a bad practice, and is the reason for which we have had to work on: RFC7721, RFC7707, RFC7217, RFC8064, besides patching/updating more than 14 standards. Besides, since we (IETF) do not specify how link-layer addresses are generated, it would be very bad to make the security/privacy properties of the addresses we do specify (IPv6) on the properties of those (link-layer) that we don't. That said, if you're keen to waste 18 bits of the address, you should probably write a draft to propose that the default subnet size/prefix be 82. Otherwise you're literally wasting 18 bits that could be used for something else. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Mar 2 01:50:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873421294D1 for ; Thu, 2 Mar 2017 01:50:11 -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_PASS=-0.001] autolearn=ham autolearn_force=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 D7bSWy4rsCsT for ; Thu, 2 Mar 2017 01:50:10 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6025C12947A for ; Thu, 2 Mar 2017 01:50:10 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0235580132; Thu, 2 Mar 2017 10:50:05 +0100 (CET) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Lorenzo Colitti , Nick Hilliard References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> <58B74D22.5010104@foobar.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <323d2e72-df42-43fb-c850-0021453a401e@si6networks.com> Date: Thu, 2 Mar 2017 06:49:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 09:50:11 -0000 On 03/02/2017 05:54 AM, Lorenzo Colitti wrote: > On Thu, Mar 2, 2017 at 7:37 AM, Nick Hilliard > wrote: > > > Can you explain the difference between your reply and "we've been doing > > it for 20 years therefore it must be the right thing to do"? > > > > The latter is a a) not a technical argument, and b) not a useful > > argument if most of that operational knowledge was formed using IPv4. > > Given that for most of the 1990s IPv6 had not been designed, much less > > operationally deployed, I assume that you do indeed mean IPv4. > > Kindly stop throwing straw men into this discussion. This is extremely > unhelpful and is not going to result in anything useful. > > > Let me rephrase the question. I asked for use cases for longer-than-/64 > prefixes and listed the ones I have seen so far: I could para-phrase you: because other prefixes longer than 64 are more than enough in all realistic situations. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Mar 2 01:52:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7DF1296A2 for ; Thu, 2 Mar 2017 01:52:13 -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 autolearn_force=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 M6HLklOovmcP for ; Thu, 2 Mar 2017 01:52:12 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFB71296B1 for ; Thu, 2 Mar 2017 01:52:12 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=49604 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cjNP4-0005lW-Op; Thu, 02 Mar 2017 10:52:06 +0100 Date: Thu, 2 Mar 2017 10:52:06 +0100 From: Tore Anderson To: Lorenzo Colitti Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Message-ID: <20170302105206.15fc3886@echo.ms.redpill-linpro.com> In-Reply-To: References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 09:52:14 -0000 * Lorenzo Colitti > Let's see if there is common ground here. I agree that routers should > forward on arbitrary prefix lengths. It's probably reasonable that > hosts should not make assumptions about other host's IP addresses > (except if they are on the same subnet). But I think a host should be > allowed to assume that its own subnet and its own IID are 64 bits > long. Such an assumption would fundamentally break SIIT [RFC7915]. Consider the following examples of IPv4-translatable IPv6 addresses [RFC6052] that might be assigned to hosts on different links in a vanilla SIIT (a.k.a. IVI) deployment: 1) 2001:db8::192.0.2.1/120 2) 2001:db8::198.51.100.1/120 3) 2001:db8::203.0.113.0/120 These are all in the same /64 but if these tree hosts assume the /120 prefix length is incorrect and "helpfully correct" it to /64, then they can no longer communicate with each other. Thus, if you want to give the host permission to make such an assumption of /64, you'd need to make exceptions for IPv4-translatable IPv6 addresses (or deprecate RFC7915 and possibly RFC6052). However, creating such an exception probably means in practise that implementations much apply it to the entire IPv6 address space, because there is no way for a host to determine whether or not, e.g., 2001:db8::c000:201 (host #1 above) is an IPv4-translatable IPv6 address or not (that I'm aware of, anyway). Tore From nobody Thu Mar 2 02:20:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66880129473 for ; Thu, 2 Mar 2017 02:19:58 -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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 4fI90ey9KRvr for ; Thu, 2 Mar 2017 02:19:56 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8480E129687 for ; Thu, 2 Mar 2017 02:19:56 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id q7so39314098uaf.2 for ; Thu, 02 Mar 2017 02:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uWDLw3w8YRgEf3vJmXmIchUaaZU7DxbEQ1YeuCvvRs4=; b=aurKZC4zoLBmXlPXqyi/TY/E3NWA1W18EVhX/uGjRURMIUvB4VSPxHtAR2g4LKq12r eSCH5ri+gn799S2kCLSyxRMLesDaS6lELcynJZqT/H0sv4ktNQGoL5v0O3uSXmJWRZXj KTtNd+5bDeMT2Ag8+njdnHGdE/6Iq6M6nKL2a6WxOaBAKo0uLTocuzaZXtAbW2bi3Qxd rhQvHzXFbwtjD+FHO34XONtI4APS6kOw6HvIcm6/Vmrc6Yq+nL+y8gtE+kFM9yLRu6SU ptmLmZfsXSoQhqqjz02liHEpIeGgX8T+O69gRZ8M5GieGOp6R6w7nsufCB0UuuicCUth EU7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uWDLw3w8YRgEf3vJmXmIchUaaZU7DxbEQ1YeuCvvRs4=; b=bLW5XR0Z+KJNGZAVWXZCqfpgg3I0eQzIDKXEYaRJgCoK6nkwQxRgyI4pe1DYgk7JA5 Ix4asrzugx2tqh+Tb7VqBmUQEdTohUMwwvVQAUdKkqUa0plLdNCMV2fDbGfqQWT4mLWA +e72gLbSU61Gw1SL5axSHmR5tAMyW9KUO8GEIfLLzIDWAchN2G+/pr+qd3Tv3EfQfQJh gJ+jSv2yHkTZOyys5a8lRr026YzHMvMZ1muw+I8LKZWt1S4WcDfNt/OT6Z87LZmbImlI n+DcgFI0a5pHkA3P7jM6MDVtm/R09fZ+NjnjPslzsxi7SM+WCfN4vdouYRyMC1Z/faru 000w== X-Gm-Message-State: AMke39nk7EvsPwB5jS3cZ5bJslw8x2xenrIjFlzcM+xYCZp2cc9MbO8gDTy5Z2TzdZdNflP3nKQW+9kdmtys33gS X-Received: by 10.176.8.4 with SMTP id a4mr6856568uaf.171.1488449995209; Thu, 02 Mar 2017 02:19:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 02:19:34 -0800 (PST) In-Reply-To: <20170302105206.15fc3886@echo.ms.redpill-linpro.com> References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> From: Lorenzo Colitti Date: Thu, 2 Mar 2017 19:19:34 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Tore Anderson Content-Type: multipart/alternative; boundary=f403045ee7783b4be60549bcc51b Archived-At: Cc: 6man WG , james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 10:19:58 -0000 --f403045ee7783b4be60549bcc51b Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 6:52 PM, Tore Anderson wrote: > 1) 2001:db8::192.0.2.1/120 > 2) 2001:db8::198.51.100.1/120 > 3) 2001:db8::203.0.113.0/120 > > These are all in the same /64 but if these tree hosts assume the /120 > prefix length is incorrect and "helpfully correct" it to /64, then they > can no longer communicate with each other. > I think you and I have already covered this case. I don't see how we can define the IID in any meaningful way for RFC 6052 addresses. In the limited case of /96 it might work, but in the general case it won't. Consider a translation prefix of 2001:db8::/56. In this case 192.0.2.1/24 becomes (I think) 2001:db8:0:c0:2:100::/80. But if you configure 2001:db8:0:c0:2:100::/80 on an interface, that really won't work the way you'd like it to. For example, suppose the node gets a packet whose destination address is 2001:db8:0:c0:2:100::1. It won't match any of the IP addresses configured it on the system. So it will either drop it, forward it on-link (if L=1) or forward it back to the router it came from, potentially causing a routing loop. So really, you can't express this type of configuration using only an IPv6 address and a prefix length, because they don't provide enough information to do that. "2001:db8:0:c0:2:100::/80" by itself is not enough: you need one more piece of information, which is the length of the NAT64 prefix. As I said before, I think we should have an exception for IPv6 addresses where the only non-zero bits in the IID are an IPv4 address. Those aren't really IPv6 addresses anyway, they're just convenient representations for IPv4 addresses. --f403045ee7783b4be60549bcc51b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Mar 2, 2017 at 6:52 PM, Tore Anderson <tore@fud.no> wrote:
    =
    1) 2001:db8::192.0.2.1/120=
    2) 2001:db8::198.51.100.1/120
    3) 2001:db8::203.0.113.0/120

    These are all in the same /64 but if these tree hosts assume the /120
    prefix length is incorrect and "helpfully correct" it to /64, the= n they
    can no longer communicate with each other.

    <= div>I think you and I have already covered this case. I don't see how w= e can define the IID in any meaningful way for RFC 6052 addresses. In the l= imited case of /96 it might work, but in the general case it won't.

    Consider a translation prefix of 2001:db8::/56. In th= is case 192.0.2.1/24 becomes (I think) = 2001:db8:0:c0:2:100::/80. But if you configure 2001:db8:0:c0:2:100::/80 on = an interface, that really won't work the way you'd like it to. For = example, suppose the node gets a packet whose destination address is 2001:d= b8:0:c0:2:100::1. It won't match any of the IP addresses configured it = on the system. So it will either drop it, forward it on-link (if L=3D1) or = forward it back to the router it came from, potentially causing a routing l= oop.

    So really, you can't express this type of= configuration using only an IPv6 address and a prefix length, because they= don't provide enough information to do that. "2001:db8:0:c0:2:100= ::/80" by itself is not enough: you need one more piece of information= , which is the length of the NAT64 prefix.

    As I sa= id before, I think we should have an exception for IPv6 addresses where the= only non-zero bits in the IID are an IPv4 address. Those aren't really= IPv6 addresses anyway, they're just convenient representations for IPv= 4 addresses.
    --f403045ee7783b4be60549bcc51b-- From nobody Thu Mar 2 02:51:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C246D1297CD for ; Thu, 2 Mar 2017 02:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fundacionsadosky.org.ar 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 P_NB4t1yo53D for ; Thu, 2 Mar 2017 02:51:39 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825DC1297CB for ; Thu, 2 Mar 2017 02:51:39 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id n127so116762347qkf.0 for ; Thu, 02 Mar 2017 02:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fundacionsadosky.org.ar; s=google; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=bTEyQiuhK2nackRT2oVbBleKzCIR2ZE0YE5OnO/CCNQ=; b=QCy19KiWZScJ1fCEe18QjItX02ioiBXY7wjdq4htxV4XEdsIYnDNeUmL0iIOt8ynzZ C7RrMaSS2w4lXuBjLPJpSK0XlgCWwSowdLpONEXmqYSKMhIg9NjbdEprFox4Ipax0p4a Ixk33xdNb+rr/IXq4KYU3S1oDZf9rdMLoMoL0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=bTEyQiuhK2nackRT2oVbBleKzCIR2ZE0YE5OnO/CCNQ=; b=UXi4jGJ0W7vZz/vcID3iBC/C7r5HjcigtFC0ILUxB8kqVqusxiP4kK5//YsOxoUf16 tl7Y2kHYnx93yHh70licg9lIX+OOG7BRbs8D6WnYsBFL98tACN3sdnwSxRBPddr5jmb1 ydPKnDZVRHM6+C1fcvCpP2qHNUPoNDHUtssFBasYnKPKS8AvdKNqMIyTI+y3gFfS8JYF qHbnycKsV1JUrxVb/flL2J16rMoM+SQGw/esaen9JkVEEP0duThhMM0WspMPYr3E0zW2 soDVtdM09M+AWF+t+Jzu3EElQXmC0eal9e7siQ8UsRm3vLPUe/2cYAb67Aumu662jOPm nCbQ== X-Gm-Message-State: AMke39nSI2t8FyHs6BoWzx/JDVl+h2Ip5QJdmzzFshGwojMlffpv4CdC0wgh6Covr1sTmA== X-Received: by 10.200.4.171 with SMTP id s43mr16610547qtg.150.1488451898441; Thu, 02 Mar 2017 02:51:38 -0800 (PST) Received: from [192.168.100.103] ([186.158.218.178]) by smtp.googlemail.com with ESMTPSA id h184sm5067307qkf.68.2017.03.02.02.51.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Mar 2017 02:51:37 -0800 (PST) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <8ce32e32-3f71-81fc-6bf5-763a4d85fed0@fundacionsadosky.org.ar> <0a3446a1-c7d2-a914-25c1-2c4cf11041b7@gmail.com> To: 6man WG From: =?UTF-8?Q?Iv=c3=a1n_Arce?= Organization: =?UTF-8?Q?Fundaci=c3=b3n_Dr._Manuel_Sadosky?= Message-ID: <71a00d57-67f6-5cc8-cd3e-06b7d0a7308a@fundacionsadosky.org.ar> Date: Thu, 2 Mar 2017 07:51:35 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Lightning/4.7.7 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 10:51:41 -0000 El 2/3/17 a las 5:57, Lorenzo Colitti escribió: > On Thu, Mar 2, 2017 at 2:15 PM, Fernando Gont > wrote: > > among other things, it unnecessarily wastes 18 bits of entropy > > > If you ever want that argument to be convincing you'll need to explain > by how much the additional 18 bits of entropy benefit real users in > realistic situations. No, its the other way around, really. But that is a discussion for a different thread. -ivan -- Iván Arce Director del Programa STIC Fundación Dr. Manuel Sadosky http://www.fundacionsadosky.org.ar TE: (+54-11) 4328-5164 GPG fingerprint: 4D97 3003 76C9 9DA4 7209 7982 0A1D 10BE CEA9 1B6E From nobody Thu Mar 2 03:06:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F441297EA for ; Thu, 2 Mar 2017 03:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 O21fKAe6QoVH for ; Thu, 2 Mar 2017 03:06:40 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DD61297BE for ; Thu, 2 Mar 2017 03:06:40 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v22B6bb6031208; Thu, 2 Mar 2017 12:06:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0C52820421E; Thu, 2 Mar 2017 12:06:37 +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 F1F3E20421C; Thu, 2 Mar 2017 12:06:36 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22B6aV5001530; Thu, 2 Mar 2017 12:06:36 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: Mikael Abrahamsson References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> From: Alexandre Petrescu Message-ID: <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> Date: Thu, 2 Mar 2017 12:06:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Erik Kline , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 11:06:42 -0000 Le 02/03/2017 à 10:31, Mikael Abrahamsson a écrit : > On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > >> perfectly fine to use that plen==65 to have an entry in the rt >> table, and use a manually configured address in that plen. > > Linux does the right thing in not autoconfiguring itself address(es) > when plen isn't 64. Whereas it is the right thing if on Ethernet (RFC2464) it is wrong on cellular links for which we have no RFC IPv6-over-foo. Same with USB and to a certain extent on WiFi. > However, what does it do when it receives an PIO with plen of 65 and > M=1 and then it gets an IA_NA and configures that on the interface? I dont know. But I guess it still calls that 65 plen "illegal". > Doesn't it install the /65 in the routing table? Dont know, but there is a need to check. How about the /63 case? Do you think it is normal that linux kernel does not configure an IP address on Ethernet when receiving a plen==63? Alex > From nobody Thu Mar 2 03:11:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3872A1297BE for ; Thu, 2 Mar 2017 03:11:12 -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 autolearn_force=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 Ss1yOTfeq6fG for ; Thu, 2 Mar 2017 03:11:10 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDBF128824 for ; Thu, 2 Mar 2017 03:11:10 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=51172 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cjOdV-0000f2-Bk; Thu, 02 Mar 2017 12:11:05 +0100 Date: Thu, 2 Mar 2017 12:11:04 +0100 From: Tore Anderson To: Lorenzo Colitti Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Message-ID: <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> In-Reply-To: References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG , james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 11:11:12 -0000 * Lorenzo Colitti > On Thu, Mar 2, 2017 at 6:52 PM, Tore Anderson wrote: >=20 > > 1) 2001:db8::192.0.2.1/120 > > 2) 2001:db8::198.51.100.1/120 > > 3) 2001:db8::203.0.113.0/120 > > > > These are all in the same /64 but if these tree hosts assume the /120 > > prefix length is incorrect and "helpfully correct" it to /64, then they > > can no longer communicate with each other. > > =20 >=20 > I think you and I have already covered this case. I don't see how we can > define the IID in any meaningful way for RFC 6052 addresses. Precisely. So if you build an host implementation that, quote, =C2=ABassume[s] that its own subnet and its own IID are 64 bits long=C2=BB,= as you suggested in your previous message, that would as I understand it break RFC7915/RFC6052 (the =C2=ABvanilla SIIT=C2=BB use case). > In the limited case of /96 it might work, but in the general case it > won't. >=20 > Consider a translation prefix of 2001:db8::/56. In this case > 192.0.2.1/24 becomes (I think) 2001:db8:0:c0:2:100::/80. But if you > configure 2001:db8:0:c0:2:100::/80 on an interface, that really won't > work the way you'd like it to. For example, suppose the node gets a > packet whose destination address is 2001:db8:0:c0:2:100::1. It won't > match any of the IP addresses configured it on the system. So it will > either drop it, forward it on-link (if L=3D1) or forward it back to the > router it came from, potentially causing a routing loop. This is somewhat besides my original point. However, it is no different from a non-SIIT situation you'd get with a subnet prefix of 2001:db8::/64, a host configured with 2001:db8::1, and a packet destined for 2001:db8::2. I'd imagine that in most deployments the packet destined for 2001:db8::2 / 2001:db8:0:c0:2:100::1 will never reach the node at 2001:db8::1 / 2001:db8:0:c0:2:100:: becuase the router or node attempting to deliver a packet to the latter address will first need to resolve it, but there's nobody on the link to answer the transmitting router/node's neighbour solicitations for those addresses and thus it will just be dropped (and possibly cause some ICMPv6 unreachables to be generated). Or if it is a ND-less PtP interface and the host is also behaving as a router you'd indeed get a loop. But again, that's no different than what would happen with any regular non-RFC6052 /64, as documented in RFC6164 section 5.1. > So really, you can't express this type of configuration using only an > IPv6 address and a prefix length, because they don't provide enough > information to do that. "2001:db8:0:c0:2:100::/80" by itself is not > enough: you need one more piece of information, which is the length > of the NAT64 prefix. I'm not exactly sure what you're saying here? RFC7915 does currently work, and hosts participating in a network using RFC7915 do not need to know the length of the translation prefix. Side note: NAT64 [RFC6146] does not have this issue because it does not use IPv4-translatable IPv6 addresses (the same goes for SIIT-DC). That is, saying that all IPv6 prefixes must be /64 and enforcing that in the host stacks would not prevent use of NAT64 (or SIIT-DC). The issue only arises for networks/technologies that are using IPv4-translatable IPv6 addresses such as (traditional) SIIT. > As I said before, I think we should have an exception for IPv6 > addresses where the only non-zero bits in the IID are an IPv4 > address. Those aren't really IPv6 addresses anyway, they're just > convenient representations for IPv4 addresses. Well, the point is that in order to ensure compatibility with SIIT such an =C2=ABexception=C2=BB would need to _always_ apply, and then it's not re= ally much of an exception anymore. At least I don't see how an IPv6 implementation could possibly distinguish between any arbitrary (non-IPv4-translatable) IPv6 address and IPv4-translatable IPv6 address? As an example, take "2001:db8:1:2:3:4:c000:201". This could be an IPv4-embedded IPv6 address where "c000:201" represents the IPv4 address 192.0.2.1, but it could also just be an arbitrary regular IPv6 address that someone configured. You can't know which it is just by looking at the address, right? And even if you did know, it wouldn't really match the =C2=ABonly non-zero bits in the IID are an IPv4 address=C2=BB, because if you either: 1) consider the IID to always be 64 bits, then there's some nonzero bits in there ("3:4") that are not part of the embedded IPv4 address, or 2) if you consider the IID to be the bits remaining after the subnet prefix has been stripped off, e.g., 2001:db8:1:2:3:4:c000:200/120 (representing 192.0.2.0/24), then the IID simply does not contain a complete IPv4 address as it's just 8 bits long. Tore From nobody Thu Mar 2 03:38:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D22F12986B for ; Thu, 2 Mar 2017 03:38:03 -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 autolearn_force=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 ndUfRv341Xhd for ; Thu, 2 Mar 2017 03:38:01 -0800 (PST) Received: from vps.baanhofman.nl (vps.baanhofman.nl [IPv6:2001:41d0:52:300::107c]) by ietfa.amsl.com (Postfix) with ESMTP id 53F411294A1 for ; Thu, 2 Mar 2017 03:38:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by vps.baanhofman.nl (Postfix) with ESMTP id 6F56F1041AD2 for ; Thu, 2 Mar 2017 12:38:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at vps.baanhofman.nl Received: from vps.baanhofman.nl ([127.0.0.1]) by localhost (vps.baanhofman.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn9k1oDdziyv for ; Thu, 2 Mar 2017 12:37:58 +0100 (CET) Received: from [IPv6:2a07:8500:120:e03a::1001] (unknown [IPv6:2a07:8500:120:e03a::1001]) (Authenticated sender: wilco) by vps.baanhofman.nl (Postfix) with ESMTPSA id F38C21041A88 for ; Thu, 2 Mar 2017 12:37:57 +0100 (CET) Subject: Consensus? (was Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux) To: ipv6@ietf.org References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> From: Wilco Baan Hofman Message-ID: Date: Thu, 2 Mar 2017 12:37:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gd7gaHq0LEm9Kuik1xXGG5NPirdooAwq0" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 11:38:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gd7gaHq0LEm9Kuik1xXGG5NPirdooAwq0 Content-Type: multipart/mixed; boundary="RP0S8C9Hh8o6sDon68oa2DbeMk7cDpcSw" From: Wilco Baan Hofman To: ipv6@ietf.org Message-ID: Subject: Consensus? (was Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux) References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> In-Reply-To: <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> --RP0S8C9Hh8o6sDon68oa2DbeMk7cDpcSw Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/03/17 12:06, Alexandre Petrescu wrote: > Le 02/03/2017 =E0 10:31, Mikael Abrahamsson a =E9crit : >> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: >> >>> perfectly fine to use that plen=3D=3D65 to have an entry in the rt >>> table, and use a manually configured address in that plen. >> >> Linux does the right thing in not autoconfiguring itself address(es) >> when plen isn't 64. > > Whereas it is the right thing if on Ethernet (RFC2464) it is wrong on > cellular links for which we have no RFC IPv6-over-foo. Same with USB > and to a certain extent on WiFi. > It is undefined on non-IEEE802 networks and /64 is the one thing that works for SLAAC, operationally. >> However, what does it do when it receives an PIO with plen of 65 and >> M=3D1 and then it gets an IA_NA and configures that on the interface? > > I dont know. But I guess it still calls that 65 plen "illegal". Which would be correct in the IEEE802 case, undefined in other cases, still not incorrect behaviour from Linux in this case. > >> Doesn't it install the /65 in the routing table? > > Dont know, but there is a need to check. > > How about the /63 case? Do you think it is normal that linux kernel > does not configure an IP address on Ethernet when receiving a plen=3D=3D= 63? > I would actually consider that normal, because the standard basically mandates /64 and configuring on /63 is undefined at this time. As implementer I would also reject such prefixes, because the code for generating the EUI-64 and the privacy extension address all (correctly) assume 64-bits of space, not 63, not 65. =3D=3D Summarizing: I think we can get consensus on: - Making a recommendation of /64 for end-user networks - Keep it required for things that depend on /64 (SLAAC, DHCPv6, ILNP, NPT66, etc) - Allow things like v4mapped address to use different subnet sizes, they don't configure via SLAAC or similar methods. This makes sure SIIT keeps working. - Make prefixes of /65-/126 allowed on fully statically configured interfaces, such as on routers =3D=3D I don't think we're going to get consensus on dropping /64 boundary entirely or on requiring the /64 boundary for everything. We can't drop it entirely, because it would break deployments at end user devices. And it is still a good recommendation to use /64 subnets on those networks. Conversely, we can't completely keep it, because it does not match the operational reality in point-to-point links between routers. Configuring /127 does not always work yet and does not cover the PTMP case (VRRP, multiple BGP sessions). Configuring /64 on those links would make the routers vulnerable to ND exhaustion. Kind regards, Wilco Baan Hofman --RP0S8C9Hh8o6sDon68oa2DbeMk7cDpcSw-- --gd7gaHq0LEm9Kuik1xXGG5NPirdooAwq0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJYuAQTAAoJENNgJ82k1pS9EtsQAJ5uaVsJVnd2yFv5Mn7RgooW f+mV2VSLE4+mehgGhapnr1Y++Azm/To6DzHU+bO6vsoBpqb5AB60Roygrt6aUYUY hn0KZWAGam8DlBnycVIrZbK9rr/vfL5EIYCaS6T42i96ujZxXqDbltu3bUGMHkJb HCdqbH6sGRU6fYyphWJKiISUeKqze6oXPWUlN2hwN++P/AX78sOh6BlqmjJPElHN REIKSodH9i49E9ngiu9PT9zwwqae3h/nLrfTqpCcstcbSEhy2brM0saAGrLasStR itMUKvVVHykyeLoN3DQ3PrvuOeJnnbLMEPGtH+kG5DLUyuZ+0kVJwACqyUg5X38I 10X50SdI4fCQocH0f+CWYHalFgJ3GNbJji/DaO5L4ePapbrtB3RARYJOxOT2CMrj f1MamNJ7doz/sytNZmf3TXpDnQUug0O3O3H4lr9bCNr8F4AMkvcARvkGKQZAuH86 T2TgtZci/FmCylD7WsNrVdXCWQ580DIRwTk7qoE0vZUnHif0qbS/f1WYyd4BFlO5 4PJ+MGhq/dZCUOndCDXUjGwl5MbalqHRFLykGlHHLg6H8sRJQZ5FyDk4S3giZYDy Z/rXzQJENn0cbnc1ViIMYBGdmHk0JRnUX7md7pYofzkKarne0O7PrNuzr6fui+fH 8+8AvSDhRe5ZDczY6jEv =bSS/ -----END PGP SIGNATURE----- --gd7gaHq0LEm9Kuik1xXGG5NPirdooAwq0-- From nobody Thu Mar 2 04:20:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34EA129977 for ; Thu, 2 Mar 2017 04:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 l9_hjsdJO_jk for ; Thu, 2 Mar 2017 04:20:29 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE70412997C for ; Thu, 2 Mar 2017 04:20:28 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A96ABA6; Thu, 2 Mar 2017 13:20:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1488457226; bh=efW296sJqVAmXCYNM8VhSSyFFdp+fA2TDaubzAxWPOA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Emapi70Z8SWFpqMJ8qRaHzqOKx3NKYfw8Agi40yvkGwq5xye0zXBFLYs96boFho7c pu+BhVFNnaz+hlIJLfyefHlxR9pzajc85H4Y8Ex2UDlAJ/WK2tkdkzLxMWEWe7i5OZ hB/OsM+Ok59qGchsXcRMwU8ZIXKutrm1EpeEQlYE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A5A04A5; Thu, 2 Mar 2017 13:20:26 +0100 (CET) Date: Thu, 2 Mar 2017 13:20:26 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux In-Reply-To: <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> Message-ID: References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.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; charset=US-ASCII; format=flowed Archived-At: Cc: Erik Kline , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:20:34 -0000 On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > How about the /63 case? Do you think it is normal that linux kernel > does not configure an IP address on Ethernet when receiving a plen==63? As far as I am aware, the only documents we have regarding autoconfigration of adresses on ethernet says to only do this on plen == 64. Thus it shouldn't be done on any other plen. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 2 04:36:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689B31294F9 for ; Thu, 2 Mar 2017 04:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 NTWynaUzBT3W for ; Thu, 2 Mar 2017 04:36:41 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B21129985 for ; Thu, 2 Mar 2017 04:36:40 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v22CadWj007799 for ; Thu, 2 Mar 2017 13:36:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F2550205268 for ; Thu, 2 Mar 2017 13:36:38 +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 E8B052022C5 for ; Thu, 2 Mar 2017 13:36:38 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22Caccc013413 for ; Thu, 2 Mar 2017 13:36:38 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: ipv6@ietf.org References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> From: Alexandre Petrescu Message-ID: <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> Date: Thu, 2 Mar 2017 13:36:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:36:42 -0000 Le 02/03/2017 à 12:37, Wilco Baan Hofman a écrit : > > > On 02/03/17 12:06, Alexandre Petrescu wrote: >> Le 02/03/2017 à 10:31, Mikael Abrahamsson a écrit : >>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: >>> >>>> perfectly fine to use that plen==65 to have an entry in the rt >>>> table, and use a manually configured address in that plen. >>> >>> Linux does the right thing in not autoconfiguring itself >>> address(es) when plen isn't 64. >> >> Whereas it is the right thing if on Ethernet (RFC2464) it is wrong >> on cellular links for which we have no RFC IPv6-over-foo. Same >> with USB and to a certain extent on WiFi. >> > It is undefined on non-IEEE802 networks and /64 is the one thing that > works for SLAAC, operationally. I agree with you. And this is a place where everything can be right or wrong: there is no consistency. Interop problems loom there. The fact that we have IPv6 running ok over 4G ptp links, and over USBnet is a very encouraging sign that makes many happy: look, IPv6 even there! But it does not mean it does not have problems. >>> However, what does it do when it receives an PIO with plen of 65 >>> and M=1 and then it gets an IA_NA and configures that on the >>> interface? >> >> I dont know. But I guess it still calls that 65 plen "illegal". > > Which would be correct in the IEEE802 case, undefined in other cases, Yes. For more precision - correct _only_ for the 802.3 case (IPv6 over Ethernet). Because we dont have an IPv6-over-WiFi either (802.11). > still not incorrect behaviour from Linux in this case. I think someone can call it correct or incorrect equally well. Because there is no consistent spec or set of specs. I call it incorrect. >>> Doesn't it install the /65 in the routing table? >> >> Dont know, but there is a need to check. >> >> How about the /63 case? Do you think it is normal that linux >> kernel does not configure an IP address on Ethernet when receiving >> a plen==63? >> > I would actually consider that normal, because the standard basically > mandates /64 and configuring on /63 is undefined at this time. I would like to doubt your saying 'basically'. Yes, the IP-over-Eth RFC2464 mandates "An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an Ethernet interface must have a length of 64 bits". It does not say which prefix of [ACONF/RFC2462] must be /64? Is it a global prefix in RA? Or is it the link-local prefix? Both these prefixes are relevant for the above phrase, both are mentioned in ACONF, yet only one is present in RA (the one linux complains about when at 65). Is the mandate cited above applying to the prefix in RA? Or to the link-local prefix? If the mandate applies to the prefix in RA then linux is right to complain, on Ethernet. If the mandate applies only to the LL prefix, then linux is wrong to complain about 65 in RA. If the mandate applies to both then RFC4291 is wrong when it says fe80::/10. RFC2464 does not say "the prefix in an RA on Ethernet MUST be 64". It does not forbid that that 64bit prefix be formed by self-appending a 0 to a /63 from the RA, or other mechanism. Besides, RFC4862 (successor to 2462) says "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored." And linux does _not_ ignore a /63 in the RA: it adds a rt entry for that /63 prefix. That's not normal either. You see what I mean? > As implementer I would also reject such prefixes, because the code > for generating the EUI-64 and the privacy extension address all > (correctly) assume 64-bits of space, not 63, not 65. Makes sense. But linux does not simply reject a /63. A linux kernel receiving a '/63' in RA will add a rt entry even though it does not configure an address. So that's not really 'rejection' of the prefix (unless of course you define 'reject' to mean 'silently add a route and then drop the packet'.) Do you agree with that? Alex [...] From nobody Thu Mar 2 04:44:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66221294CA for ; Thu, 2 Mar 2017 04:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 zSQ54sDrHmAT for ; Thu, 2 Mar 2017 04:44:16 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D65120727 for ; Thu, 2 Mar 2017 04:44:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v22CiDPn011876; Thu, 2 Mar 2017 13:44:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B0AA9204F1E; Thu, 2 Mar 2017 13:44:13 +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 A0CBC207A26; Thu, 2 Mar 2017 13:44:13 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22CiDQO019321; Thu, 2 Mar 2017 13:44:13 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: Mikael Abrahamsson References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 2 Mar 2017 13:44:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Erik Kline , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:44:17 -0000 Le 02/03/2017 à 13:20, Mikael Abrahamsson a écrit : > On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > >> How about the /63 case? Do you think it is normal that linux >> kernel does not configure an IP address on Ethernet when receiving >> a plen==63? > > As far as I am aware, the only documents we have regarding > autoconfigration of adresses on ethernet says to only do this on plen > == 64. Thus it shouldn't be done on any other plen. Mikael, I explained separately something I think makes sense, but here it is briefly anyways. IPv6-over-Ethernet RFC2464 says a certain plen must be 64, but it's not clear whether that plen is the plen of the prefix in RA, or the plen of the LL address. If the plen that RFC refers to is that of the LL address (not that of the plen of the prefix in the RA) then linux shouldnt reject prefixes in RA with plen==65. Besides, no spec stops somebody from forming a /64 out of a /63 received in RA plus a 0. Or somehow else. Anyways, you seem to be two thinking and reading specs otherwise than I do, so I may not insist... Alex > From nobody Thu Mar 2 04:46:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BF9120727 for ; Thu, 2 Mar 2017 04:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 XywZSLVpOncV for ; Thu, 2 Mar 2017 04:46:14 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737E7129989 for ; Thu, 2 Mar 2017 04:46:14 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6BCC3A6; Thu, 2 Mar 2017 13:46:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1488458772; bh=1xZ6JIjnmHKJVL09RAAmV0AbGqUUnCkN5gz3FQMO6pQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Pl4Q1APCMNShjst1F8Vze86Dojvai/Z03lsbq7EL3wt/qU4pAtm6bTvjYphPxbIC5 I7MrVM7SmV/rhpbDkHf+YaCxAtA0L4X/plyMO8SLJXHYGIW6s5oAh7rELaQgrFTmxd PxM8rSSSzu6sCwCzGjot6mekaDeMIKTSwx/b0His= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 667B5A5; Thu, 2 Mar 2017 13:46:12 +0100 (CET) Date: Thu, 2 Mar 2017 13:46:12 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux In-Reply-To: <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> Message-ID: References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.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; charset=US-ASCII; format=flowed Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:46:15 -0000 On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > Yes. For more precision - correct _only_ for the 802.3 case (IPv6 over > Ethernet). Because we dont have an IPv6-over-WiFi either (802.11). We have IPv6 for 802.1 framed networks (that was my understanding). Both 802.3 and 802.11 uses ethernet frames, so why wouldn't they be considered the same from L3 IPv6 point of view? That's the way it's been done historically anyway, as far as I can see. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 2 05:29:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEB4129534 for ; Thu, 2 Mar 2017 05:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 kEq139QU6gsn for ; Thu, 2 Mar 2017 05:29:53 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD7B129464 for ; Thu, 2 Mar 2017 05:29:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v22DTncr023248; Thu, 2 Mar 2017 14:29:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A91AC208223; Thu, 2 Mar 2017 14:29:49 +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 9B7332041FD; Thu, 2 Mar 2017 14:29:49 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22DTnCe029905; Thu, 2 Mar 2017 14:29:49 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: Mikael Abrahamsson References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> From: Alexandre Petrescu Message-ID: <8b421fd5-81e0-5d8d-1715-4d0e3ab51e52@gmail.com> Date: Thu, 2 Mar 2017 14:29:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 13:29:55 -0000 Le 02/03/2017 à 13:46, Mikael Abrahamsson a écrit : > On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > >> Yes. For more precision - correct _only_ for the 802.3 case (IPv6 >> over Ethernet). Because we dont have an IPv6-over-WiFi either >> (802.11). > > We have IPv6 for 802.1 framed networks (that was my understanding). > Both 802.3 and 802.11 uses ethernet frames, Well, yes in principle. But I would doubt your saying 'both'. Because if one looks at an IPv6 packet captured in monitor mode on WiFi one does not see any Ethernet header. Or maybe you mean something else by an Ethernet frame(?). Or maybe you meant that local processing converts between these Ethernet headers and 802.11 headers(?). On the air the IPv6 packets have 802.11 headers (not EthernetII headers) _and_ 802.11 trailers. One can see them with wireshark in monitor mode. These headers and trailers have many fields relevant for some IPv6 fields in IPv6 headers (e.g. traffic class, and others). Yet we have no spec about how would one map some these from 802.11 to IP. We do have a spec about how to map an IP mcast address to a MAC mcast address, what ethertype to use in EthernetII header (which is _not_ the 802.11 Headers), and that's about it. We also have software everywhere that converts between 802.11 headers and 802.3 EthernetII headers. That software is not documented either. > so why wouldn't they be considered the same from L3 IPv6 point of > view? Because that is the easy choice. And because if we do so, then we lose many of features these miriad of link layers have to offer. This is one reason why many IPv6-over-foo IoT-specific links get written: to take advantage of the link layer features at IP layer. I would agree that all these links _could_ be the same from the IPv6 stack standpoint, but there are many IoT adaptation layers out there which make it that the Ethernet view you mention above is not used at least in some places. > That's the way it's been done historically anyway, as far as I can > see. I agree with you. But, there are some IETF documents that consider some aspects which could be qualified as the domain of IPv6-over-802.11, and without considering a IPv6-over-Ethernet. E.g. draft-ietf-tsvwg-ieee-802-11-01 "Guidelines for DiffServ to IEEE 802.11 Mapping". _If_ we had an IPv6-over-WiFi document (not just IPv6-over-Ethernet) then we could have proposed these DiffServ mapping proposals to go along with unicast mapping, and mcast mapping proposals of the typical IPv6-over-Ethernet. Alex From nobody Thu Mar 2 06:03:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A1F1295B4 for ; Thu, 2 Mar 2017 06:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 wxo9Dvq5od2z for ; Thu, 2 Mar 2017 06:02:59 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1E512958D for ; Thu, 2 Mar 2017 06:02:58 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id c11so27917438uaa.0 for ; Thu, 02 Mar 2017 06:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UMS4YnQ+0uvs+gddXgFg9R4DkeGdcaOv5jpXm4Sp2f0=; b=ODWN6+Vk5Ktg0Sg+CCt/YBkRkV5nAiXv8V/htDH0+6aMH9dVqBJmNa2IPVPzkjxNLm tGG6DkSYJJqIgiRSwbyX7THZSmSYtHrF8xjBU3cePnQXeC1gbSIqKsWL/JgWBEVLf90t Zf43SrwDSCc6log8GKcEYXxqmJZ1dcFdjqZhsojet3upW/ixKmojp2mELaTsYF2MXNAS UKu+BpTXCQMXvkh5N3GGQyUu5yXPZtshrHrSOg33ejqacXdW7HtV3Tnezw1MRuCKcI51 leahQzZVj029U6SphiJ9aKl0uVg2ubN8QRwZTivtuPkolDoeHnHO6Y3+UaGQtlU/1uLW 0odA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UMS4YnQ+0uvs+gddXgFg9R4DkeGdcaOv5jpXm4Sp2f0=; b=PFciK9ofDMe9OrzBMcWIvKeCI8cEw+xtk37O47J80vEdgvtSb5ck0ldXsCYjSWhFiR tUkCJymDHYRrb1dYz4CPn1f4I58Q4UsirTOxjT7/X1vDqHEc8+A85fYeWDU31juSfVmE iqtrIRVzID3RM9L1AC5yEq7eiD+x8qC2lo1saWWKoszt8FiPuVv7Odn0tvWIDE8RACTH 3YfSJ6NtA6YFWL1bSoF5GFveHSEGvIDzrF6jvszj/cbWVIj/VBjcbVb3TKaKkVtLhF75 6VIJh4Rtg5+SEO8FQX8vZZFX9lmfi5JJwpIwCxtLesdK0XnI7TbWOtkpttYCCZJ4GFic oduA== X-Gm-Message-State: AMke39mrcWbftq8ezFCNTVewJQ5SbOHDaovpoltYSESSgZTPPAEjuzuvaUdGYkY7ttMVBZtCjxpprIgjESs08Ysi X-Received: by 10.176.1.5 with SMTP id 5mr5895332uak.30.1488463374858; Thu, 02 Mar 2017 06:02:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 06:02:34 -0800 (PST) In-Reply-To: <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> From: Lorenzo Colitti Date: Thu, 2 Mar 2017 23:02:34 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Tore Anderson Content-Type: multipart/alternative; boundary=001a113d058cb88a680549bfe2da Archived-At: Cc: 6man WG , james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 14:03:05 -0000 --001a113d058cb88a680549bfe2da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 2, 2017 at 8:11 PM, Tore Anderson wrote: > > So really, you can't express this type of configuration using only an > > IPv6 address and a prefix length, because they don't provide enough > > information to do that. "2001:db8:0:c0:2:100::/80" by itself is not > > enough: you need one more piece of information, which is the length > > of the NAT64 prefix. > > I'm not exactly sure what you're saying here? RFC7915 does currently > work, and hosts participating in a network using RFC7915 do not need to > know the length of the translation prefix. > Oh, I see. It works if you ensure that all the hosts and translators agree on how to calculate the suffix, and no two hosts have IPv6 addresses that differ only in the suffix. IPv6 addresses that don't have this property experience unidirectional connectivity to IPv4, and can cause packets to be sent by third parties to the host that has the correct suffix. Fair enough. > > As I said before, I think we should have an exception for IPv6 > > addresses where the only non-zero bits in the IID are an IPv4 > > address. Those aren't really IPv6 addresses anyway, they're just > > convenient representations for IPv4 addresses. > > Well, the point is that in order to ensure compatibility with SIIT such > an =C2=ABexception=C2=BB would need to _always_ apply, and then it's not = really > much of an exception anymore. > How about an exception for IPv6-translatable addresses, then? I don't think it's essential that the host know that the addresses are IPv6-translatable. --001a113d058cb88a680549bfe2da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Mar 2, 2017 at 8:11 PM, Tore Anderson <tore@fud.no> wrote:
    =
    &g= t; So really, you can't express this type of configuration using only a= n
    > IPv6 address and a prefix length, because they don't provide enoug= h
    > information to do that. "2001:db8:0:c0:2:100::/80" by itself= is not
    > enough: you need one more piece of information, which is the length > of the NAT64 prefix.

    I'm not exactly sure what you're saying here? RFC7915 does c= urrently
    work, and hosts participating in a network using RFC7915 do not need to
    know the length of the translation prefix.

    <= div>Oh, I see. It works if you ensure that all the hosts and translators ag= ree on how to calculate the suffix, and no two hosts have IPv6 addresses th= at differ only in the suffix. IPv6 addresses that don't have this prope= rty experience unidirectional connectivity to IPv4, and can cause packets t= o be sent by third parties to the host that has the correct suffix. Fair en= ough.
    =C2=A0
    > As I said before, I think we should have= an exception for IPv6
    > addresses where the only non-zero bits in the IID are an IPv4
    > address. Those aren't really IPv6 addresses anyway, they're ju= st
    > convenient representations for IPv4 addresses.

    Well, the point is that in order to ensure compatibility with SIIT s= uch
    an =C2=ABexception=C2=BB would need to _always_ apply, and then it's no= t really
    much of an exception anymore.

    How about= an exception for IPv6-translatable addresses, then? I don't think it&#= 39;s essential that the host know that the addresses are IPv6-translatable.=
    --001a113d058cb88a680549bfe2da-- From nobody Thu Mar 2 06:36:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F38C129493 for ; Thu, 2 Mar 2017 06:36:17 -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 autolearn_force=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 kUkAZytwSOPX for ; Thu, 2 Mar 2017 06:36:15 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5901294E8 for ; Thu, 2 Mar 2017 06:36:14 -0800 (PST) Received: from [2a02:fe0:c420:6ae::c68] (port=42034 helo=envy) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cjRpz-00015s-QR; Thu, 02 Mar 2017 15:36:11 +0100 Date: Thu, 2 Mar 2017 15:36:11 +0100 From: Tore Anderson To: Lorenzo Colitti Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Message-ID: <20170302153611.36506f85@envy> In-Reply-To: References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: james woodyatt , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 14:36:17 -0000 * Lorenzo Colitti > On Thu, Mar 2, 2017 at 8:11 PM, Tore Anderson wrote: >=20 > > > So really, you can't express this type of configuration using > > > only an IPv6 address and a prefix length, because they don't > > > provide enough information to do that. "2001:db8:0:c0:2:100::/80" > > > by itself is not enough: you need one more piece of information, > > > which is the length of the NAT64 prefix. > > > > I'm not exactly sure what you're saying here? RFC7915 does currently > > work, and hosts participating in a network using RFC7915 do not > > need to know the length of the translation prefix. >=20 > Oh, I see. It works if you ensure that all the hosts and translators > agree on how to calculate the suffix, Yes, apart from the fact that the hosts usually don't need to =C2=ABcalculate=C2=BB anything or even have any awareness of the translation taking place: For outbound flows from a host with an IPv4-translatable IPv6 address to the IPv4 internet, a DNS64 recursor would typically take care of that calcuation. This works exactly the same as if you're using Stateful NAT64 instead. For inbound flows to such a host it only has to respond normally to the source address in the incoming IPv6 request packet - which may or may not be an IPv4-embedded IPv6 address. Again, this works same as with Stateful NAT64 (assuming the NAT64 device allows inbound flows from the IPv4 network in the first place, e.g., using static BIB entries). > and no two hosts have IPv6 addresses that differ only in the suffix. > IPv6 addresses that don't have this property experience > unidirectional connectivity to IPv4, and can cause packets to be sent > by third parties to the host that has the correct suffix. Fair enough. Indeed, if you arbitrarily start setting the bits RFC6052 says should be all 0 you will have successfully shot yourself in the foot. (Not that I believe this is relevant to the discussion at hand.) > > Well, the point is that in order to ensure compatibility with SIIT > > such an =C2=ABexception=C2=BB would need to _always_ apply, and then it= 's not > > really much of an exception anymore. >=20 > How about an exception for IPv6-translatable addresses, then? I don't > think it's essential that the host know that the addresses are > IPv6-translatable. Exactly, you'd need an exception for IPv4-translatable IPv6 addresses. But if you're coding up an host OS IPv6 stack you can't differentiate between IPv4-translatable IPv6 addresses and =C2=ABnormal=C2=BB IPv6 addres= ses. After all there's no flag or property that tells the host stack that a given IPv6 address is IPv4-translatable or not. An OS/IPv6 stack implementer therefore has no choice but to make this =C2=ABexception=C2=BB apply to *all* IPv6 addresses, allowing addresses to = be configured with arbitrary-length IIDs, thus making the exception the rule. Tore From nobody Thu Mar 2 07:36:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F5B12999F for ; Thu, 2 Mar 2017 07:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 W0ksGDARnVIe for ; Thu, 2 Mar 2017 07:36:02 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4967C1294D6 for ; Thu, 2 Mar 2017 07:36:02 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id 72so81475178uaf.3 for ; Thu, 02 Mar 2017 07:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q+hYHEq5J5pbo2xPwUF3KPn4AtdBZqeuwaJmmMMU/uM=; b=KWizLzNWB6wrKlUECumDoIHnlVibt/o7wb/5+ySc8tsgNjynjCZhQOxipoyOzj9Kek pzVpgW7lZmhD3CoylxG61j0TIIGhNY/pnu5uwrVk+W0PBF93ffQlJ9XNn5RTdP6JnZEv 5UVYFu7JtkKpH9PRqlCdeNUqO+Q5WqfKtGZrKh+xOyqBctYIr1WSNpMyQimg6OndWb60 3pShxupe7OIjTTa8DCwiHTmL09NqgN0h7QyJKQf1bBbGohZB6Rj2pXNUujcDjPMYKGPP d3aX368OFktgWECEaJfoXZ2RZh1dznfjzCJyZuy4EoeyuOIMrPsr/e/ozXeKT3PYZXG7 o6Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q+hYHEq5J5pbo2xPwUF3KPn4AtdBZqeuwaJmmMMU/uM=; b=jgmT4czr6Day00CniKpBA0DZMpPNovZbYUFVN6VTuv7ZsGQN5lQgbcogJ5xFAZeK/b xiX6ea+W9kGLMifLzFgaGdpkE5s6t929/c14A8ZWPeELWUq+3lOhJxv/m4zRSxkcYyJW +GwhWXfyJZdrIdkhscjqiI/CNet6Lm+SDwkJ/pCHJnwtygw6xkIzEC2f32R98NBv4/Dy HfqqlaIKr4PJV39nDWtvQ3vj1VCJSqC6TBu1L8igafoexgUKVTVDTbfjQ5GVUV411SnQ fyHdTLd9F6hnhoA0Uyt7Wp8FVLcuyGoS/VlKmyHIjXZVYLUtUnAH9hHsCP2VOy/kAkEZ oE+w== X-Gm-Message-State: AMke39n9lrAIyGQugBGEEnczKssEFFSIsJuIXoGX5/Fzqr43Nws1hK/z18Xffol/hlM0vFDMn80ies90jaSavgKJ X-Received: by 10.31.142.68 with SMTP id q65mr3273975vkd.83.1488468960824; Thu, 02 Mar 2017 07:36:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 07:35:40 -0800 (PST) In-Reply-To: <20170302153611.36506f85@envy> References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> From: Lorenzo Colitti Date: Fri, 3 Mar 2017 00:35:40 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Tore Anderson Content-Type: multipart/alternative; boundary=001a1143703aabc1750549c12ff6 Archived-At: Cc: james woodyatt , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 15:36:04 -0000 --001a1143703aabc1750549c12ff6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 2, 2017 at 11:36 PM, Tore Anderson wrote: > But if you're coding up an host OS IPv6 stack you can't differentiate > between IPv4-translatable IPv6 addresses and =C2=ABnormal=C2=BB IPv6 addr= esses. > After all there's no flag or property that tells the host stack that a > given IPv6 address is IPv4-translatable or not. > Agreed. But note: I'm not suggesting that hosts should refuse to manually configure arbitrary-length prefix lengths. Hosts allow this today and I have no problem with that. What I'm saying is that the IID length for unicast addresses, with a few exceptions, should continue to be fixed at 64 bits. Those exceptions should be unicast addresses that start with binary 000 (RFC 4291) point-to-point links that use /127 (RFC 6164), IPv6-translatable addresses (RFC 6052), and probably not much else. The reason the fixed 64-bit length is important is that it ensures that subnets never run out of addresses, and that's an extremely desirable property. --001a1143703aabc1750549c12ff6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Mar 2, 2017 at 11:36 PM, Tore Anderson <tore@fud.no> wrote:
    But if you're coding= up an host OS IPv6 stack you can't differentiate
    between IPv4-translatable IPv6 addresses and =C2=ABnormal=C2=BB IPv6 addres= ses.
    After all there's no flag or property that tells the host stack that a<= br> given IPv6 address is IPv4-translatable or not.
    =C2=A0=
    Agreed. But note: I'm not suggesting that hosts should refus= e to manually configure arbitrary-length prefix lengths. Hosts allow this t= oday and I have no problem with that.

    What I'm= saying is that the IID length for unicast addresses, with a few exceptions= , should continue to be fixed at 64 bits. Those exceptions should be unicas= t addresses that start with binary 000 (RFC 4291) point-to-point links that= use /127 (RFC 6164), IPv6-translatable addresses (RFC 6052), and probably = not much else.

    The reason the fixed 64-bit length = is important is that it ensures that subnets never run out of addresses, an= d that's an extremely desirable property.
    --001a1143703aabc1750549c12ff6-- From nobody Thu Mar 2 08:23:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD88B129515 for ; Thu, 2 Mar 2017 08:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 67aYIBACw4k2 for ; Thu, 2 Mar 2017 08:23:22 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609AC12946A for ; Thu, 2 Mar 2017 08:23:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v22GNKM5007044 for ; Thu, 2 Mar 2017 17:23:20 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F269320421A for ; Thu, 2 Mar 2017 17:23:19 +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 E7A8E200DA6 for ; Thu, 2 Mar 2017 17:23:19 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22GNJin028868 for ; Thu, 2 Mar 2017 17:23:19 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: ipv6@ietf.org References: <20170223134026.GI5069@gir.theapt.org> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> From: Alexandre Petrescu Message-ID: Date: Thu, 2 Mar 2017 17:23:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BD58DA40116A8652E5BBF789" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 16:23:24 -0000 This is a multi-part message in MIME format. --------------BD58DA40116A8652E5BBF789 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 02/03/2017 à 16:35, Lorenzo Colitti a écrit : > [...] > The reason the fixed 64-bit length is important is that it ensures > that subnets never run out of addresses, and that's an extremely > desirable property. Ok, but maybe it's the operators running out of /64s, no? I speculate, but I couldn't imagine a cellular operator dedicating a /40, i.e. 2^24 /64s, i.e. the equivalent of a 10.x Class A, to cover its end users. (the cellular operator I work with dedicates a /47 to cover its end users). Alex --------------BD58DA40116A8652E5BBF789 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



    Le 02/03/2017 à 16:35, Lorenzo Colitti a écrit :
    [...]
    The reason the fixed 64-bit length is important is that it ensures that subnets never run out of addresses, and that's an extremely desirable property.

    Ok, but maybe it's the operators running out of /64s, no?

    I speculate, but I couldn't imagine a cellular operator dedicating a /40, i.e. 2^24 /64s, i.e. the equivalent of a 10.x Class A, to cover its end users.    (the cellular operator I work with dedicates a /47 to cover its end users).

    Alex

    --------------BD58DA40116A8652E5BBF789-- From nobody Thu Mar 2 09:49:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB92D129593 for ; Thu, 2 Mar 2017 09:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 gAF0dQKKxh_6 for ; Thu, 2 Mar 2017 09:49:51 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186481294C9 for ; Thu, 2 Mar 2017 09:49:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 86BE34B; Thu, 2 Mar 2017 18:49:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1488476985; bh=52ZGTs/V9eO1vmOAxcWwa6neB2BR eo2qAsYTaEKhsnc=; b=dl3f6SYOFvqWlo1hCpLaMjlleRcCe36CAs2nHhLbyahx dTwQB/II35wOBhVZqQ1jTHBTyAlfVlvRs2pYON8abc9Xzok+Cv2GuHpkTgy89WBo ivf3rnWA9Pr1vX9BFWxF9KQTEq6ps2+o+x4675HHNtlAOr0shIRlZtxsyzmQz6Y= 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 10026) with ESMTP id urkoK3vUFBtD; Thu, 2 Mar 2017 18:49:45 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:15bd:d61c:a52a:9afb] (unknown [IPv6:2a02:a213:a300:9300:15bd:d61c:a52a:9afb]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 52EE84A; Thu, 2 Mar 2017 18:49:45 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_1E648C9C-A120-4147-BD6C-7124FE377D54"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Thu, 2 Mar 2017 18:49:41 +0100 Message-Id: <2D14A5DE-E836-4C40-9B92-4A3D6BB3BC01@steffann.nl> References: <20170223134026.GI5069@gir.theapt.org> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 17:49:52 -0000 --Apple-Mail=_1E648C9C-A120-4147-BD6C-7124FE377D54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, > Ok, but maybe it's the operators running out of /64s, no? No > I speculate, but I couldn't imagine a cellular operator dedicating a = /40, i.e. 2^24 /64s, i.e. the equivalent of a 10.x Class A, to cover its = end users. (the cellular operator I work with dedicates a /47 to = cover its end users). A /40 is nothing. An operator get's a *minimum* of a /32, and in RIPE = land can get a /29 by just asking for it. A /40 is less than 1/2048th of = a small operator's address space. Cheers, Sander --Apple-Mail=_1E648C9C-A120-4147-BD6C-7124FE377D54 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----- iQEcBAEBCAAGBQJYuFs1AAoJEKAtA7D+JBO5LugIAIDUFwhM3Dor05ASUy3ACkm9 hGCmMIhl7BmSd1z2wTr9cVISaJbNOmraOgiiakNVf60pAXWbYFlfVta6TTruwJVC io/g5Hs3nPUlpyEq8xPEBGLw1Cm6QDh/JNi3IJTughyq3n/rgqM19FJ1JKWjUURO n+t4uWJQLE/oexQR6TmdAibWGAjVTZPf/UGioXp3OUEY36/rWwA6eWtAvcxnrOfz 8zqwqWbJC5c9UJDMF49uLZGLeXKVa/McTjDbfYZS3tlzXwLJVKBO6T9y2QiNhyqR cH+DH0S8oNNxw1RxLoxpGjF3orBczXKbNcEz5cMVeXv+y5RTkrvsXxK08FV1OPE= =z8EP -----END PGP SIGNATURE----- --Apple-Mail=_1E648C9C-A120-4147-BD6C-7124FE377D54-- From nobody Thu Mar 2 10:05:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C467F12959D for ; Thu, 2 Mar 2017 10:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 HIWptalXlRQ5 for ; Thu, 2 Mar 2017 10:05:28 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4BF1295A1 for ; Thu, 2 Mar 2017 10:05:27 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4132EA7; Thu, 2 Mar 2017 19:05:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1488477925; bh=8oNDNqSU8QhON2neRKGITfTe4fEazfOG1Yq4L3Fjmu0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=M7ERu5IEWdgrMxm4KEwEipnxIqeDKcicZwbGDfcNZe3klnI0LSLa/2PNsCFtoqe5C 2TwEZI0LmvVdIdbwwEArcjerbYDM4b/ekTtNKbaL7cEphzdBFT8Y84OguWY4Dt5Bfv 2vSYKDuu82/98j9bYz7D3BZB/m9XXPha3fWSwxUo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3CCF8A6; Thu, 2 Mar 2017 19:05:25 +0100 (CET) Date: Thu, 2 Mar 2017 19:05:25 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt In-Reply-To: Message-ID: References: <20170223134026.GI5069@gir.theapt.org> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 18:05:30 -0000 On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > I speculate, but I couldn't imagine a cellular operator dedicating a > /40, i.e. 2^24 /64s, i.e. the equivalent of a 10.x Class A, to cover its > end users. (the cellular operator I work with dedicates a /47 to cover > its end users). Then that cellular operator is extremely small and only has less than 128k users. 3GPP mandates /64 per PDP context. That's what mobile operators use. I know operator who allocate new pools to their GGSNs in chunks of /44s, ie covering a million users at a time. /40 is not much, is one 1/256th of the default allocation you get by just showing up and saying "hello, I am LIR and I want to use IPv6". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 2 10:24:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0511295AF for ; Thu, 2 Mar 2017 10:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 AlTTU_hjA21d for ; Thu, 2 Mar 2017 10:24:23 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138121295B8 for ; Thu, 2 Mar 2017 10:24:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v22IOKLj019157; Thu, 2 Mar 2017 19:24:20 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DC6D520D2AD; Thu, 2 Mar 2017 19:24:20 +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 CF6A320D287; Thu, 2 Mar 2017 19:24:20 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22IOKfS013754; Thu, 2 Mar 2017 19:24:20 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Sander Steffann References: <20170223134026.GI5069@gir.theapt.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <2D14A5DE-E836-4C40-9B92-4A3D6BB3BC01@steffann.nl> From: Alexandre Petrescu Message-ID: <79c5f76a-8b15-b4cf-31e2-7e25f4f98318@gmail.com> Date: Thu, 2 Mar 2017 19:24:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2D14A5DE-E836-4C40-9B92-4A3D6BB3BC01@steffann.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 18:24:25 -0000 Le 02/03/2017 à 18:49, Sander Steffann a écrit : > Hi, > >> Ok, but maybe it's the operators running out of /64s, no? > > No So why dont they give more than one such /64 to one end user? >> I speculate, but I couldn't imagine a cellular operator dedicating >> a /40, i.e. 2^24 /64s, i.e. the equivalent of a 10.x Class A, to >> cover its end users. (the cellular operator I work with >> dedicates a /47 to cover its end users). > > A /40 is nothing. ?? > An operator get's a *minimum* of a /32, I can agree to that. But I am also familiar with the common practice to use chunks of GUAs on the interconnection links (instead of LLs or ULAs). There too people say "we have enough of these IPv6 prefixes, no worry". But it's again speculation. > and in RIPE land can get a /29 by just asking for it. That looks simple. > A /40 is less than 1/2048th of a small operator's address space. Look, let us talk only about the cellular parts of a certain country of what such an operator may get. I can agree with you that an operator may get much from RIPE, but I ask how much of it will she assign to its end users on cellular links? Do you know of a cellular operator assigning a shorter-than-/47 prefix to cover its cellular end users? I am not asking to name it, but whether such thing exists is sufficient for me. Alex > > Cheers, Sander > From nobody Thu Mar 2 10:27:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB4A1295B0 for ; Thu, 2 Mar 2017 10:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 3hvzekEX2jsP for ; Thu, 2 Mar 2017 10:27:29 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD16129593 for ; Thu, 2 Mar 2017 10:27:29 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v22IRRru007618; Thu, 2 Mar 2017 19:27:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8264F202490; Thu, 2 Mar 2017 19:27: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 7575F2022F8; Thu, 2 Mar 2017 19:27:27 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22IRRnc015279; Thu, 2 Mar 2017 19:27:27 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Mikael Abrahamsson References: <20170223134026.GI5069@gir.theapt.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> From: Alexandre Petrescu Message-ID: Date: Thu, 2 Mar 2017 19:27:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 18:27:30 -0000 Le 02/03/2017 à 19:05, Mikael Abrahamsson a écrit : > On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > >> I speculate, but I couldn't imagine a cellular operator dedicating >> a /40, i.e. 2^24 /64s, i.e. the equivalent of a 10.x Class A, to >> cover its end users. (the cellular operator I work with dedicates >> a /47 to cover its end users). > > Then that cellular operator is extremely small and only has less > than 128k users. Yes, it looks so. > 3GPP mandates /64 per PDP context. That's what mobile operators use. > > I know operator who allocate new pools to their GGSNs in chunks of > /44s, ie covering a million users at a time. YEs yes, but how much of that /44 is covering the end-users and how much is reserved for interconnnections? > /40 is not much, is one 1/256th of the default allocation you get by > just showing up and saying "hello, I am LIR and I want to use IPv6". Ah great, but I guess few cellular operators (if any?) are LIRs. Or maybe that's true and I didnt know. If all this were that simple and clearcut - there are enough /64s out there - then why operators only assign one per one end user? Alex From nobody Thu Mar 2 10:33:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB8C1295BF for ; Thu, 2 Mar 2017 10:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 WxEDxbcfD6bg for ; Thu, 2 Mar 2017 10:33:05 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16267129593 for ; Thu, 2 Mar 2017 10:33:05 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 215C0A7; Thu, 2 Mar 2017 19:33:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1488479583; bh=bZf770lSo9xVf/oCJ0GbyIaIrIxe8HAt/EGvE/pZtQs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=SzaQXBP04mhi02JlP+2H7DEintdXk5h+ZihwR1qM0K+5ANoMa32Ei7PByY0wikb9Z R70LtufcugPT8Uh+zCJvqgj4djlaOAzfytRBVUZw4Wa9kPBM0xADCtQW1dNFR4oCa4 jVzapCBqpO7BwWtax8WoXRjTzmd17PYiiYWeA5GE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 09BF3A6; Thu, 2 Mar 2017 19:33:03 +0100 (CET) Date: Thu, 2 Mar 2017 19:33:03 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt In-Reply-To: Message-ID: References: <20170223134026.GI5069@gir.theapt.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 18:33:06 -0000 On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > YEs yes, but how much of that /44 is covering the end-users and how much > is reserved for interconnnections? Nothing. It's /44 to the GGSN/SPGW. > Ah great, but I guess few cellular operators (if any?) are LIRs. Or > maybe that's true and I didnt know. You don't know. > If all this were that simple and clearcut - there are enough /64s out > there - then why operators only assign one per one end user? Because DHCPv6-PD hasn't been implemented in mobile networks yet (that I know of). So that's all they can do per 3GPP standards. Residential rollouts, most use /56 per customer. >From the RIRs, you can without further justification get /48 per "site", so if you show up to RIR and you're LIR and you say "hello, I have 40 million customers and I want to give each customer a /48" then they'll give you a /22 most likely. You're perfectly within your right as an operator to deploy /48 per customer per current RIR rules that I am aware of. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 2 10:55:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F181294A9 for ; Thu, 2 Mar 2017 10:55:03 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 qBNrSQ3y8_dT for ; Thu, 2 Mar 2017 10:55:01 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD651294A8 for ; Thu, 2 Mar 2017 10:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488480897; x=1489085697; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=aROM1n4UV6Myn3OvGolatWXeh A4TVmRvN13/lftMbBY=; b=aMd3iLMy2SkUvKrTm1/+jNFGrvL10cQci+k0HhXtl Au6I+3QV3AYtAoxpHtHtms4ojEndlyVObZKa5kSJ9i+Y2CQ7u5iWFLNfnma7sqZM Z/hpyyfIybvntdtk96BwRBFUW03e2RHHv23cTrSJhVXNBg0elFI/8xrFyVUdVrQs 4k= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=oedLhTafiyK7XLxgKMz4R+XYUjPLNut2JnMakAW8Zf8ye1USqbZ+Yj/LLj/r VZSWKvCaW/uADqSgq0dEHnXkAEDo5ACsEpC0mpA4BNyfWOkwdFmeqi033 l0WwFumaX9WfbLKw1ZArheqjpT++oKcj+YoaijhXPNDckswx9WxNa8=; X-MDAV-Processed: mail.consulintel.es, Thu, 02 Mar 2017 19:54:57 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 02 Mar 2017 19:54:53 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005377500.msg for ; Thu, 02 Mar 2017 19:54:52 +0100 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170302:md50005377500::V7LR/1YEOlCPUC5/:00000/13 X-Return-Path: prvs=1234a5327c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Thu, 02 Mar 2017 19:54:49 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt From: JORDI PALET MARTINEZ To: Message-ID: <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> Thread-Topic: Objection to draft-ietf-6man-rfc4291bis-07.txt References: <20170223134026.GI5069@gir.theapt.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 18:55:03 -0000 Actually, is not correct that most use /56 for residential. >From my last review of the survey, worldwide, 22% use /48, 35% use /56, but= there is a lot of ISPs (33%) doing it wrong and using /64, which of course= , we are explaining them that is wrong. 10% use =E2=80=9Cother=E2=80=9D siz= es. Full details at: https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-su= rvey Saludos, Jordi =20 -----Mensaje original----- De: ipv6 en nombre de Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Responder a: Fecha: jueves, 2 de marzo de 2017, 19:33 Para: Alexandre Petrescu CC: Asunto: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt On Thu, 2 Mar 2017, Alexandre Petrescu wrote: =20 > YEs yes, but how much of that /44 is covering the end-users and how m= uch=20 > is reserved for interconnnections? =20 Nothing. It's /44 to the GGSN/SPGW. =20 > Ah great, but I guess few cellular operators (if any?) are LIRs. Or= =20 > maybe that's true and I didnt know. =20 You don't know. =20 > If all this were that simple and clearcut - there are enough /64s out= =20 > there - then why operators only assign one per one end user? =20 Because DHCPv6-PD hasn't been implemented in mobile networks yet (that = I=20 know of). So that's all they can do per 3GPP standards. =20 Residential rollouts, most use /56 per customer. =20 >From the RIRs, you can without further justification get /48 per "site= ",=20 so if you show up to RIR and you're LIR and you say "hello, I have 40= =20 million customers and I want to give each customer a /48" then they'll= =20 give you a /22 most likely. You're perfectly within your right as an=20 operator to deploy /48 per customer per current RIR rules that I am awa= re=20 of. =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Mar 2 11:00:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8041295D3 for ; Thu, 2 Mar 2017 11:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 aYm5oGB5-Yco for ; Thu, 2 Mar 2017 11:00:12 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D198C1295D2 for ; Thu, 2 Mar 2017 11:00:11 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v22J0AIY019408; Thu, 2 Mar 2017 20:00:10 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0739B20D286; Thu, 2 Mar 2017 20:00:10 +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 EE72F20D12D; Thu, 2 Mar 2017 20:00:09 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22J09H1030973; Thu, 2 Mar 2017 20:00:09 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Mikael Abrahamsson References: <20170223134026.GI5069@gir.theapt.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> From: Alexandre Petrescu Message-ID: Date: Thu, 2 Mar 2017 20:00:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 19:00:12 -0000 Le 02/03/2017 à 19:33, Mikael Abrahamsson a écrit : [...] >> If all this were that simple and clearcut - there are enough /64s >> out there - then why operators only assign one per one end user? > > Because DHCPv6-PD hasn't been implemented in mobile networks yet > (that I know of). This situation lasts since more than 5 years now. It is very suspicious. I wonder what is wrong and what can be done to get it fixed. Alex > So that's all they can do per 3GPP standards. > > Residential rollouts, most use /56 per customer. > >> From the RIRs, you can without further justification get /48 per >> "site", > so if you show up to RIR and you're LIR and you say "hello, I have > 40 million customers and I want to give each customer a /48" then > they'll give you a /22 most likely. You're perfectly within your > right as an operator to deploy /48 per customer per current RIR rules > that I am aware of. > From nobody Thu Mar 2 11:02:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F871295FB for ; Thu, 2 Mar 2017 11:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 QNiFIRjSfzB0 for ; Thu, 2 Mar 2017 11:02:30 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B77F1295E8 for ; Thu, 2 Mar 2017 11:02:30 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v22J2Si5026603 for ; Thu, 2 Mar 2017 20:02:28 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0FD89202490 for ; Thu, 2 Mar 2017 20:02: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 069592022F8 for ; Thu, 2 Mar 2017 20:02:28 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22J2R3b031981 for ; Thu, 2 Mar 2017 20:02:27 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: ipv6@ietf.org References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> From: Alexandre Petrescu Message-ID: <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> Date: Thu, 2 Mar 2017 20:02:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 19:02:32 -0000 Le 02/03/2017 à 19:54, JORDI PALET MARTINEZ a écrit : > Actually, is not correct that most use /56 for residential. > >> From my last review of the survey, worldwide, 22% use /48, 35% use >> /56, but there is a lot of ISPs (33%) doing it wrong and using /64, >> which of course, we are explaining them that is wrong. 10% use >> “other†sizes. So how comes that households can get /56s but smartphones no? Really there must be something there hidden. Alex > > Full details at: > > https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-survey > > Saludos, Jordi > > > -----Mensaje original----- De: ipv6 en nombre > de Mikael Abrahamsson Organización: People's Front > Against WWW Responder a: Fecha: jueves, 2 de marzo > de 2017, 19:33 Para: Alexandre Petrescu > CC: Asunto: Re: > Objection to draft-ietf-6man-rfc4291bis-07.txt > > On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > >> YEs yes, but how much of that /44 is covering the end-users and how >> much is reserved for interconnnections? > > Nothing. It's /44 to the GGSN/SPGW. > >> Ah great, but I guess few cellular operators (if any?) are LIRs. >> Or maybe that's true and I didnt know. > > You don't know. > >> If all this were that simple and clearcut - there are enough /64s >> out there - then why operators only assign one per one end user? > > Because DHCPv6-PD hasn't been implemented in mobile networks yet > (that I know of). So that's all they can do per 3GPP standards. > > Residential rollouts, most use /56 per customer. > >> From the RIRs, you can without further justification get /48 per >> "site", > so if you show up to RIR and you're LIR and you say "hello, I have 40 > million customers and I want to give each customer a /48" then > they'll give you a /22 most likely. You're perfectly within your > right as an operator to deploy /48 per customer per current RIR rules > that I am aware of. > > -- Mikael Abrahamsson email: swmike@swm.pp.se > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be > aware that any disclosure, copying, distribution or use of the > contents of this information, including attached files, is > prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Mar 2 11:06:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37CF129608 for ; Thu, 2 Mar 2017 11:06:21 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 E_CxR_Q0DhWW for ; Thu, 2 Mar 2017 11:06:20 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB491295D2 for ; Thu, 2 Mar 2017 11:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488481578; x=1489086378; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=faUe7G2IRGnyITyGNUDDTk2GM aGfAuBv775DFw5c1Ag=; b=d0vGUPOKypQlGAYuCHYYQEnVGnROapcFo8H52DeT2 nE1jtzUuIUyb8g6IiNsX9UKHqGjULMXwmJy4Te8d1YtxRsvxZtsNafaHE4dc5ehl h+4lb7Hy46qYoEGOWGFuABh2Lane2FAVWuKDwvxiuO1BWmD0rsVi6thkv5sBDUj/ xU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ZDBOFHMzwer5yPIbUoQkm0IaqHbLVMZcrZjzqb7RZwEmNvmIIvTq9bNh7y9s 53A4Q8bCsvaLS6wim9dLTVTdXBE9+hPBnI5i1+G0fpMjsL82FfkBYq2OB AeTvIKV6ukFESjYIArcF91uEv+BfxD8TfbBc88beD0YXMrgNVKd/8c=; X-MDAV-Processed: mail.consulintel.es, Thu, 02 Mar 2017 20:06:18 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 02 Mar 2017 20:06:18 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005377510.msg for ; Thu, 02 Mar 2017 20:06:16 +0100 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170302:md50005377510::/sViXCdCGLYOj+/z:00000EX0 X-Return-Path: prvs=1234a5327c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Thu, 02 Mar 2017 20:06:15 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt From: JORDI PALET MARTINEZ To: Message-ID: <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> Thread-Topic: Objection to draft-ietf-6man-rfc4291bis-07.txt References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> In-Reply-To: <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 19:06:22 -0000 I guess because the lack of DHCPv6-PD support, as you already indicated? I think majority of the households and business customers get configured th= e CPE by means for DHCPv6-PD =E2=80=A6 Saludos, Jordi =20 -----Mensaje original----- De: ipv6 en nombre de Alexandre Petrescu Responder a: Fecha: jueves, 2 de marzo de 2017, 20:02 Para: Asunto: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt =20 =20 Le 02/03/2017 =C3=A0 19:54, JORDI PALET MARTINEZ a =C3=A9crit : > Actually, is not correct that most use /56 for residential. > >> From my last review of the survey, worldwide, 22% use /48, 35% use >> /56, but there is a lot of ISPs (33%) doing it wrong and using /64, >> which of course, we are explaining them that is wrong. 10% use >> =E2=80=9Cother=E2=80=9D sizes. =20 So how comes that households can get /56s but smartphones no? =20 Really there must be something there hidden. =20 Alex =20 > > Full details at: > > https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deploym= ent-survey > > Saludos, Jordi > > > -----Mensaje original----- De: ipv6 en nombre > de Mikael Abrahamsson Organizaci=C3=B3n: People's = Front > Against WWW Responder a: Fecha: jueves, 2 de marzo > de 2017, 19:33 Para: Alexandre Petrescu > CC: Asunto: Re: > Objection to draft-ietf-6man-rfc4291bis-07.txt > > On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > >> YEs yes, but how much of that /44 is covering the end-users and how >> much is reserved for interconnnections? > > Nothing. It's /44 to the GGSN/SPGW. > >> Ah great, but I guess few cellular operators (if any?) are LIRs. >> Or maybe that's true and I didnt know. > > You don't know. > >> If all this were that simple and clearcut - there are enough /64s >> out there - then why operators only assign one per one end user? > > Because DHCPv6-PD hasn't been implemented in mobile networks yet > (that I know of). So that's all they can do per 3GPP standards. > > Residential rollouts, most use /56 per customer. > >> From the RIRs, you can without further justification get /48 per >> "site", > so if you show up to RIR and you're LIR and you say "hello, I have 40 > million customers and I want to give each customer a /48" then > they'll give you a /22 most likely. You're perfectly within your > right as an operator to deploy /48 per customer per current RIR rules > that I am aware of. > > -- Mikael Abrahamsson email: swmike@swm.pp.se > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be > aware that any disclosure, copying, distribution or use of the > contents of this information, including attached files, is > prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Mar 2 11:15:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC7D1295FF for ; Thu, 2 Mar 2017 11:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 n9ETrg9B4AgX for ; Thu, 2 Mar 2017 11:15:24 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277061293EC for ; Thu, 2 Mar 2017 11:15:23 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v22JFMhj029114 for ; Thu, 2 Mar 2017 20:15:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A10620D2D3 for ; Thu, 2 Mar 2017 20:15:22 +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 305F020D2EA for ; Thu, 2 Mar 2017 20:15:22 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22JFLO2007415 for ; Thu, 2 Mar 2017 20:15:22 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: ipv6@ietf.org References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Thu, 2 Mar 2017 20:15:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 19:15:26 -0000 Le 02/03/2017 à 20:06, JORDI PALET MARTINEZ a écrit : > I guess because the lack of DHCPv6-PD support, as you already > indicated? But for deity's sake - DHCPv6-PD is available as open source... it's common software. Just download and install. The IETF Specs suggest it, and the 3GPP specs require it too. There must be something else making these router equipment manufacturers refraining from downloading and installing DHCPv6-PD. > I think majority of the households and business customers get > configured the CPE by means for DHCPv6-PD … AFAIK my CPE at home does not use DHCPv6-PD, but something based on IPv4, like 6rd. I think it's something developped in-house at that particular operator. Alex > > Saludos, Jordi > > > -----Mensaje original----- De: ipv6 en > nombre de Alexandre Petrescu Responder > a: Fecha: jueves, 2 de marzo de 2017, > 20:02 Para: Asunto: Re: Objection to > draft-ietf-6man-rfc4291bis-07.txt > > > > Le 02/03/2017 à 19:54, JORDI PALET MARTINEZ a écrit : >> Actually, is not correct that most use /56 for residential. >> >>> From my last review of the survey, worldwide, 22% use /48, 35% >>> use /56, but there is a lot of ISPs (33%) doing it wrong and >>> using /64, which of course, we are explaining them that is >>> wrong. 10% use “other†sizes. > > So how comes that households can get /56s but smartphones no? > > Really there must be something there hidden. > > Alex > >> >> Full details at: >> >> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-survey > >> >> > >> Saludos, Jordi >> >> >> -----Mensaje original----- De: ipv6 en >> nombre de Mikael Abrahamsson Organización: >> People's Front Against WWW Responder a: Fecha: >> jueves, 2 de marzo de 2017, 19:33 Para: Alexandre Petrescu >> CC: Asunto: Re: >> Objection to draft-ietf-6man-rfc4291bis-07.txt >> >> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: >> >>> YEs yes, but how much of that /44 is covering the end-users and >>> how much is reserved for interconnnections? >> >> Nothing. It's /44 to the GGSN/SPGW. >> >>> Ah great, but I guess few cellular operators (if any?) are LIRs. >>> Or maybe that's true and I didnt know. >> >> You don't know. >> >>> If all this were that simple and clearcut - there are enough /64s >>> out there - then why operators only assign one per one end user? >> >> Because DHCPv6-PD hasn't been implemented in mobile networks yet >> (that I know of). So that's all they can do per 3GPP standards. >> >> Residential rollouts, most use /56 per customer. >> >>> From the RIRs, you can without further justification get /48 per >>> "site", >> so if you show up to RIR and you're LIR and you say "hello, I have >> 40 million customers and I want to give each customer a /48" then >> they'll give you a /22 most likely. You're perfectly within your >> right as an operator to deploy /48 per customer per current RIR >> rules that I am aware of. >> >> -- Mikael Abrahamsson email: swmike@swm.pp.se >> >> -------------------------------------------------------------------- > >> >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > >> >> >> >> >> ********************************************** IPv4 is over Are you >> ready for the new Internet ? http://www.consulintel.es The IPv6 >> Company >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the use of the individual(s) named above. If you are not the >> intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, including >> attached files, is prohibited. >> >> >> >> -------------------------------------------------------------------- > >> >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of > the individual(s) named above. If you are not the intended recipient > be aware that any disclosure, copying, distribution or use of the > contents of this information, including attached files, is > prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Mar 2 11:25:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A66D129543 for ; Thu, 2 Mar 2017 11:25: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 mWGNWmnd8P0R for ; Thu, 2 Mar 2017 11:25:40 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0022129488 for ; Thu, 2 Mar 2017 11:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488482735; x=1489087535; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=NjIqf+ljYkKBqrXNP5gqIH6xH sFKmtsgAowtKH7rVd4=; b=WGUX10HECcqOC0pGISsa5etd8YA7zCFqjWtv6hDGB xjEkskWS8QzQER78YDVgo8lE3yov0PKs6j1kCYgWwx0mLjDLUpKNurvov+n/LYOi eZlupQ+TYYw1fEnf7LHCVi2Y88t6owwaeaqg9yicrr2kb5h+FeEvhZPrljin/EOm fw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Thvd27UcYOgg+TkozK0IwGKVVhnS9okmd7z7OuiJheEMCBMFjptqV0BSXySp LoN/RTzHUdKSzAQi6ZY3GjQq61RMNNrJpE3pEt58ouuLKlZFcxVydtOum cPcCTUxDIrWUTe7Cu14bLBFBSiuPqbwJyiKq6FjeFvTwGr4tHZ6HMc=; X-MDAV-Processed: mail.consulintel.es, Thu, 02 Mar 2017 20:25:35 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 02 Mar 2017 20:25:32 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005377531.msg for ; Thu, 02 Mar 2017 20:25:32 +0100 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170302:md50005377531::cX3IzEkRGvgbxpz8:00004WZj X-Return-Path: prvs=1234a5327c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Thu, 02 Mar 2017 20:25:29 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: Objection to draft-ietf-6man-rfc4291bis-07.txt References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 19:25:42 -0000 I understood from one of your previous emails that 3GPP doesn=E2=80=99t req= uire DHCPv6-PD. RFC6653, suggest its use, so probably we got confused ourse= lves and 3GPP is actually using it. 6rd is a different thing, because is actually IPv4 link and IPv6 is a tunne= l, so you typically use DHCP (v4). In IPv6-only world (including cellular), the WAN link will be IPv6-only ins= tead of dual-stack. This is already happening. If they don=E2=80=99t use it, I guess is the same reason why big vendors di= dn=E2=80=99t implemented yet RDDNS =E2=80=A6 Cellular world is using 464XLAT, and they use DHCPv6-PD. Check RFC6877. Saludos, Jordi =20 -----Mensaje original----- De: ipv6 en nombre de Alexandre Petrescu Responder a: Fecha: jueves, 2 de marzo de 2017, 20:15 Para: Asunto: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt =20 =20 Le 02/03/2017 =C3=A0 20:06, JORDI PALET MARTINEZ a =C3=A9crit : > I guess because the lack of DHCPv6-PD support, as you already > indicated? =20 But for deity's sake - DHCPv6-PD is available as open source... it's common software. Just download and install. The IETF Specs suggest it= , and the 3GPP specs require it too. =20 There must be something else making these router equipment manufacturer= s refraining from downloading and installing DHCPv6-PD. =20 > I think majority of the households and business customers get > configured the CPE by means for DHCPv6-PD =E2=80=A6 =20 AFAIK my CPE at home does not use DHCPv6-PD, but something based on IPv4, like 6rd. I think it's something developped in-house at that particular operator. =20 Alex =20 > > Saludos, Jordi > > > -----Mensaje original----- De: ipv6 en > nombre de Alexandre Petrescu Responder > a: Fecha: jueves, 2 de marzo de 2017, > 20:02 Para: Asunto: Re: Objection to > draft-ietf-6man-rfc4291bis-07.txt > > > > Le 02/03/2017 =C3=A0 19:54, JORDI PALET MARTINEZ a =C3=A9crit : >> Actually, is not correct that most use /56 for residential. >> >>> From my last review of the survey, worldwide, 22% use /48, 35% >>> use /56, but there is a lot of ISPs (33%) doing it wrong and >>> using /64, which of course, we are explaining them that is >>> wrong. 10% use =E2=80=9Cother=E2=80=9D sizes. > > So how comes that households can get /56s but smartphones no? > > Really there must be something there hidden. > > Alex > >> >> Full details at: >> >> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deploy= ment-survey > >> >> > >> Saludos, Jordi >> >> >> -----Mensaje original----- De: ipv6 en >> nombre de Mikael Abrahamsson Organizaci=C3=B3n: >> People's Front Against WWW Responder a: Fecha: >> jueves, 2 de marzo de 2017, 19:33 Para: Alexandre Petrescu >> CC: Asunto: Re: >> Objection to draft-ietf-6man-rfc4291bis-07.txt >> >> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: >> >>> YEs yes, but how much of that /44 is covering the end-users and >>> how much is reserved for interconnnections? >> >> Nothing. It's /44 to the GGSN/SPGW. >> >>> Ah great, but I guess few cellular operators (if any?) are LIRs. >>> Or maybe that's true and I didnt know. >> >> You don't know. >> >>> If all this were that simple and clearcut - there are enough /64s >>> out there - then why operators only assign one per one end user? >> >> Because DHCPv6-PD hasn't been implemented in mobile networks yet >> (that I know of). So that's all they can do per 3GPP standards. >> >> Residential rollouts, most use /56 per customer. >> >>> From the RIRs, you can without further justification get /48 per >>> "site", >> so if you show up to RIR and you're LIR and you say "hello, I have >> 40 million customers and I want to give each customer a /48" then >> they'll give you a /22 most likely. You're perfectly within your >> right as an operator to deploy /48 per customer per current RIR >> rules that I am aware of. >> >> -- Mikael Abrahamsson email: swmike@swm.pp.se >> >> -------------------------------------------------------------------- > >> >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > >> >> >> >> >> ********************************************** IPv4 is over Are you >> ready for the new Internet ? http://www.consulintel.es The IPv6 >> Company >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the use of the individual(s) named above. If you are not the >> intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, including >> attached files, is prohibited. >> >> >> >> -------------------------------------------------------------------- > >> >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of > the individual(s) named above. If you are not the intended recipient > be aware that any disclosure, copying, distribution or use of the > contents of this information, including attached files, is > prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Mar 2 12:23:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B7912896F for ; Thu, 2 Mar 2017 12:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 EDOlXQl7lygs for ; Thu, 2 Mar 2017 12:23:53 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606BB129505 for ; Thu, 2 Mar 2017 12:23:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v22KNpq2009624 for ; Thu, 2 Mar 2017 21:23:51 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6049D20D369 for ; Thu, 2 Mar 2017 21:23:51 +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 56D8320D348 for ; Thu, 2 Mar 2017 21:23:51 +0100 (CET) Received: from [132.166.84.25] ([132.166.84.25]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v22KNo7e022019 for ; Thu, 2 Mar 2017 21:23:50 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: ipv6@ietf.org References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> From: Alexandre Petrescu Message-ID: <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> Date: Thu, 2 Mar 2017 21:23:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 20:23:56 -0000 Le 02/03/2017 à 20:25, JORDI PALET MARTINEZ a écrit : > I understood from one of your previous emails that 3GPP doesn’t > require DHCPv6-PD. Right - if I understand correctly, it does not require DHCPv6-PD on the UE. Maybe in the core, but not in the UE. > RFC6653, suggest its use, so probably we got confused ourselves and > 3GPP is actually using it. > > 6rd is a different thing, because is actually IPv4 link and IPv6 is a > tunnel, so you typically use DHCP (v4). I agree. > In IPv6-only world (including cellular), the WAN link will be > IPv6-only instead of dual-stack. This is already happening. > > If they don’t use it, I guess is the same reason why big vendors > didn’t implemented yet RDDNS … I wonder if Windows refusing RDNSS doesn't have somehting to do with its Teredo; and extending this logic to smartphones: the lack of answers to DHCPv6-PD issued from the UE may have something to do with 464xlat presence. Could it be that 464xlat presence on UE makes it that DHCPv6-PD is impossible on same UE? > Cellular world is using 464XLAT, and they use DHCPv6-PD. Check > RFC6877. I guess you mean cellular stations (like BS, not the User Equipment) uses DHCPv6-PD within the fixed network. Because cellular operator I am aware of replies to DHCPv6-PD requests issued from an User Equipment. Alex > > Saludos, Jordi > > > -----Mensaje original----- De: ipv6 en nombre > de Alexandre Petrescu Responder a: > Fecha: jueves, 2 de marzo de 2017, > 20:15 Para: Asunto: Re: Objection to > draft-ietf-6man-rfc4291bis-07.txt > > > > Le 02/03/2017 à 20:06, JORDI PALET MARTINEZ a écrit : >> I guess because the lack of DHCPv6-PD support, as you already >> indicated? > > But for deity's sake - DHCPv6-PD is available as open source... it's > common software. Just download and install. The IETF Specs suggest > it, and the 3GPP specs require it too. > > There must be something else making these router equipment > manufacturers refraining from downloading and installing DHCPv6-PD. > >> I think majority of the households and business customers get >> configured the CPE by means for DHCPv6-PD … > > AFAIK my CPE at home does not use DHCPv6-PD, but something based on > IPv4, like 6rd. I think it's something developped in-house at that > particular operator. > > Alex > >> >> Saludos, Jordi >> >> >> -----Mensaje original----- De: ipv6 en >> nombre de Alexandre Petrescu >> Responder a: Fecha: jueves, 2 de >> marzo de 2017, 20:02 Para: Asunto: Re: Objection >> to draft-ietf-6man-rfc4291bis-07.txt >> >> >> >> Le 02/03/2017 à 19:54, JORDI PALET MARTINEZ a écrit : >>> Actually, is not correct that most use /56 for residential. >>> >>>> From my last review of the survey, worldwide, 22% use /48, 35% >>>> use /56, but there is a lot of ISPs (33%) doing it wrong and >>>> using /64, which of course, we are explaining them that is >>>> wrong. 10% use “other†sizes. >> >> So how comes that households can get /56s but smartphones no? >> >> Really there must be something there hidden. >> >> Alex >> >>> >>> Full details at: >>> >>> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-survey > >>> >>> >>> >>> >>> > >>> >>> >> >>> Saludos, Jordi >>> >>> >>> -----Mensaje original----- De: ipv6 en >>> nombre de Mikael Abrahamsson Organización: >>> People's Front Against WWW Responder a: >>> Fecha: jueves, 2 de marzo de 2017, 19:33 Para: Alexandre >>> Petrescu CC: >>> Asunto: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt >>> >>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: >>> >>>> YEs yes, but how much of that /44 is covering the end-users >>>> and how much is reserved for interconnnections? >>> >>> Nothing. It's /44 to the GGSN/SPGW. >>> >>>> Ah great, but I guess few cellular operators (if any?) are >>>> LIRs. Or maybe that's true and I didnt know. >>> >>> You don't know. >>> >>>> If all this were that simple and clearcut - there are enough >>>> /64s out there - then why operators only assign one per one end >>>> user? >>> >>> Because DHCPv6-PD hasn't been implemented in mobile networks yet >>> (that I know of). So that's all they can do per 3GPP standards. >>> >>> Residential rollouts, most use /56 per customer. >>> >>>> From the RIRs, you can without further justification get /48 >>>> per "site", >>> so if you show up to RIR and you're LIR and you say "hello, I >>> have 40 million customers and I want to give each customer a /48" >>> then they'll give you a /22 most likely. You're perfectly within >>> your right as an operator to deploy /48 per customer per current >>> RIR rules that I am aware of. >>> >>> -- Mikael Abrahamsson email: swmike@swm.pp.se >>> >>> -------------------------------------------------------------------- > >>> >>> >>> >>> >>> > >>> >>> >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > >>> >>> >>> >>> >>> > >>> >>> >> >>> >>> >>> >>> >>> ********************************************** IPv4 is over Are >>> you ready for the new Internet ? http://www.consulintel.es The >>> IPv6 Company >>> >>> This electronic message contains information which may be >>> privileged or confidential. The information is intended to be >>> for the use of the individual(s) named above. If you are not the >>> intended recipient be aware that any disclosure, copying, >>> distribution or use of the contents of this information, >>> including attached files, is prohibited. >>> >>> >>> >>> -------------------------------------------------------------------- > >>> >>> >>> >>> >>> > >>> >>> >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > >>> >>> >>> >>> >>> > >>> >>> >> >> >> -------------------------------------------------------------------- > >> >> >> >> >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> >> >> >> > >> >> >> >> ********************************************** IPv4 is over Are >> you ready for the new Internet ? http://www.consulintel.es The >> IPv6 Company >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the use of the individual(s) named above. If you are not the >> intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, including >> attached files, is prohibited. >> >> >> >> -------------------------------------------------------------------- > >> >> >> >> >> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> >> >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of > the individual(s) named above. If you are not the intended recipient > be aware that any disclosure, copying, distribution or use of the > contents of this information, including attached files, is > prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Mar 2 13:02:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E3A129656; Thu, 2 Mar 2017 13:02:51 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZF4ye8aeQIz9; Thu, 2 Mar 2017 13:02:49 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449AB1294FD; Thu, 2 Mar 2017 13:02:46 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 2133E42174DB8; Thu, 2 Mar 2017 21:02:40 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v22L2hE0016648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Mar 2017 22:02:43 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v22L2em8001935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Mar 2017 21:02:41 GMT Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.153]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Thu, 2 Mar 2017 22:02:40 +0100 From: "Papadimitriou, Dimitri (Nokia - BE)" To: "rtg-ads@ietf.org" , "draft-ietf-6man-rfc2460bis.all@ietf.org" Subject: RE: Routing directorate review of draft-ietf-6man-rfc2460bis Thread-Topic: Routing directorate review of draft-ietf-6man-rfc2460bis Thread-Index: AdKFwZDg9wFxEPPGS96EtpTiRnPBlQAqvXfAAxKG9ZA= Date: Thu, 2 Mar 2017 21:02:40 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF833D36EDAA@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <9C5FD3EFA72E1740A3D41BADDE0B461FC61A4621@szxema506-mbs.china.huawei.com> <84675BAA8C49154AB81E2587BE8BDF833D3556AD@FR711WXCHMBA07.zeu.alcatel-lucent.com> In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF833D3556AD@FR711WXCHMBA07.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 21:02:51 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtNm1hbi1yZmMyNDYwYmlzLTA4LnR4dA0K UmV2aWV3ZXI6IERpbWl0cmkgUGFwYWRpbWl0cmlvdSANClJldmlldyBEYXRlOiAwMS0wMy0yMDE3 DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KDQpTdW1tYXJ5Og0KDQpJIGhhdmUg c29tZSBtaW5vciBjb21tZW50cyBhYm91dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBtaWdo dCBoYXZlIHRvIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KTWFqb3IgSXNzdWVz OiANCg0KTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KDQpNaW5vciBJc3N1ZXM6DQoNClNlY3Rpb24g NC40OiBwcm9jZXNzaW5nIG9mIHRoZSAic2VnbWVudCBsZWZ0IiBmaWVsZCBpcyBsZWZ0IHVuZG9j dW1lbnRlZCAoc2hvdWxkbid0IGl0IGJlIGRlY3JlbWVudGVkIGFmdGVyIGJlaW5nIHByb2Nlc3Nl ZCA/KQ0KDQpTZWN0aW9uIDQuNTogIklmIGluc3VmZmljaWVudCBmcmFnbWVudHMgYXJlIHJlY2Vp dmVkIHRvIGNvbXBsZXRlIHJlYXNzZW1ibHkiIGRvZXMgImluc3VmZmljaWVudCIgbWVhbnMgdGhl IGxhc3QgZnJhZ21lbnQgPw0KDQpTZWN0aW9uIDQuODogc3RhdGVzICJOZXcgaG9wLWJ5LWhvcCBv cHRpb25zIGFyZSBub3QgcmVjb21tZW5kZWQgYmVjYXVzZSBub2RlcyBtYXkgYmUgY29uZmlndXJl ZCB0byBpZ25vcmUgdGhlIEhvcC1ieS1Ib3AgT3B0aW9uIGhlYWRlciwgZHJvcCBwYWNrZXRzIGNv bnRhaW5pbmcgYSBob3AtYnktaG9wIGhlYWRlciIgZG9lcyB0aGlzIGNvbmZpZ3VyYXRpb24gY2hh bmdlIGJlY2F1c2Ugb3B0aW9ucyBhcmUgbmV3IG9yIG9sZCA/IHRoZXJlIHNlZW1zIHRvIGJlIGNv bmZ1c2lvbiBoZXJlIGJldHdlZW4gIm5ldyB2cy4gZXhpc3RpbmciIG9wdGlvbnMgYW5kICJpbnRl cm1lZGlhdGUgbm9kZXMgTUFZIGJlIGNvbmZpZ3VyZWQgdG8gaWdub3JlL2Ryb3AgcGFja2V0cyB3 aXRoIHRoZXNlIG9wdGlvbnMgaW5jbHVkZWQiLiANCg0KU2VjdGlvbiA4LjM6IG9uZSB3b3VsZCBo YXZlIGV4cGVjdGVkIGEgc2VsZi1jb25zaXN0ZW50IGZvcm11bGEgdG8gZGV0ZXJtaW5lIHRoZSBt YXgucGF5bG9hZCBzaXplIGluc3RlYWQgb2YgYSByZWxhdGl2ZSBjb21wYXJpc29uIHRvIElQdjQN Cg0KU2VjdGlvbiA4LjQ6IGF1dG9tYXRpY2FsbHkgcmV2ZXJzZWQgb3Igbm90LCB0aGlzIHNlY3Rp b24gZG9lc24ndCBzdGF0ZSBpZiB0aGUgcmVzcG9uc2UgKHVuZGVyc3Rvb2QgaGVyZSB0aGF0IHRo ZSBvcHRpb24gdHlwZSBpcyByZWNvZ25pemVkKSBpcyB0byBiZSBzZW50IHRvIHRoZSBzb3VyY2Ug YWRkcmVzcyAoZGlyZWN0bHkpIG9yIHRoZSBsYXN0IGVudHJ5IGZyb20gdGhlIHJlY29yZCByb3V0 ZSBmb3IgaW5zdGFuY2UgKGNmLiBTZWN0aW9uIDQuNCkuDQoNCkVkaXRvcmlhbHM6DQoNCnAyLiBz L0ludGVybmV0IFByb3RvY29sL0ludGVybmV0IFByb3RvY29sIChJUCkNCg0KU2VjdGlvbiAyIGRl ZmluZXMgbGluayBmb3IgbGluayBNVFUgYnV0IGRvZXNuJ3QgZGVmaW5lIHBhdGggZm9yIHBhdGgg TVRVDQoNCnAxNC4gcy9hIHNvdXJjZSBub2RlIGtub3cvYSBzb3VyY2Ugbm9kZSBrbm93cw0KDQot LS0tLQ0KDQo= From nobody Thu Mar 2 13:25:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDF0120724; Thu, 2 Mar 2017 13:25:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MzNltsrqsMIc; Thu, 2 Mar 2017 13:25:00 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891B1129653; Thu, 2 Mar 2017 13:25:00 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id 25so10471770pgy.3; Thu, 02 Mar 2017 13:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wrpkXdbuFy/lEQdmjFMnGDGMh+TCfvxXAl/M3cqevEs=; b=phjJMjjxpwzj/eBpDcNPR5SuNjM9GQLxaX8DkcxhQUnpgk4vq+2K25EYDbW4U+rWpy NyRhEpq39hJfE4zwpMs5j7eK1HEU5TSWYcNqvSDhBgVVMcNmiftfTiDKxKOOIGV0FmNA KNrFkuyT35mUMxgDm9CYeqQxFxMK6XQ1OwxCkwWmvHsIhAaq5OPRc+0tjXucghu14bmO +GQVDbDn7gNkmeAv+HnWCpoI3QbUQnjaX5lNWF23k94uIVxdLg0ndY/pd6vubifan/eX Fen+27bf0bRw9Y87Jaj/GcaVOFoA33pvzNPn3YnTPO+DCvqfRlPdM8hCSK8vh8NwzCMU KhmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=wrpkXdbuFy/lEQdmjFMnGDGMh+TCfvxXAl/M3cqevEs=; b=hHfGXPrB4wi1jgUvzRrhxED2slo/vp12+w/f2blY3tndyiuGRy1mc1qblBVxTGcu8o mHSnt60YLQwSxFEF3Wefx82IhF8lOz18mVNW9ydswT9upqzGlBt9aVNzmZ8zM20uCM50 QMGvtE4y3o8BwtS5gTV7sIMp8msyAPlUAmHmyINTOYJqCrrk3OTXTEz4Csoi/QbxLUps ypeWQPGOIuyCHp1NIBZuz5P4o32JgA453+a2IrXtbpAyyNP++puqN+C7+wZfwmBgR2Ez IFkvMVIYK67mM8IADBPOq0WtEM9EJz9AQPLhtyDiQzVTFK2mMgIZqIFqfTxDNZ06lSz6 cSkA== X-Gm-Message-State: AMke39kwN1ePMdMvwvx4xdeq1sq+Hs99/nAkSvuv3jLDy0PASa+gaZ+ugbFxBK5x67rmdQ== X-Received: by 10.84.236.9 with SMTP id q9mr21268067plk.96.1488489899989; Thu, 02 Mar 2017 13:24:59 -0800 (PST) Received: from [192.168.178.21] ([118.149.111.252]) by smtp.gmail.com with ESMTPSA id x15sm19000828pgo.56.2017.03.02.13.24.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Mar 2017 13:24:59 -0800 (PST) Subject: Hop-by-hop options [Re: Routing directorate review of draft-ietf-6man-rfc2460bis] To: "Papadimitriou, Dimitri (Nokia - BE)" , "rtg-ads@ietf.org" , "draft-ietf-6man-rfc2460bis.all@ietf.org" References: <9C5FD3EFA72E1740A3D41BADDE0B461FC61A4621@szxema506-mbs.china.huawei.com> <84675BAA8C49154AB81E2587BE8BDF833D3556AD@FR711WXCHMBA07.zeu.alcatel-lucent.com> <84675BAA8C49154AB81E2587BE8BDF833D36EDAA@FR711WXCHMBA07.zeu.alcatel-lucent.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6a33c1d3-9a9a-674b-1fc7-a1bc17aafead@gmail.com> Date: Fri, 3 Mar 2017 10:25:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <84675BAA8C49154AB81E2587BE8BDF833D36EDAA@FR711WXCHMBA07.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-dir@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 21:25:02 -0000 On 03/03/2017 10:02, Papadimitriou, Dimitri (Nokia - BE) wrote: ... > Section 4.8: states "New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header" does this configuration change because options are new or old ? there seems to be confusion here between "new vs. existing" options and "intermediate nodes MAY be configured to ignore/drop packets with these options included". Middleboxes *might* be configured to do something sensible with existing HbH options (such as ignoring them) and something annoying with unknown new ones (such as kicking them to the slow path or dropping the packet). So yes, the situation is worse for new options than for ones that have been defined years ago. But they are both risky. Brian From nobody Thu Mar 2 13:36:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB0012967B for ; Thu, 2 Mar 2017 13:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 ibjoq3DhJg1U for ; Thu, 2 Mar 2017 13:36:39 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBFC129674 for ; Thu, 2 Mar 2017 13:36:38 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id m67so31369544qkf.2 for ; Thu, 02 Mar 2017 13:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wbj4+3nQZOlUvjlj9E1rdHY/CoHAepBEQGTnaZyBhXI=; b=PFGzsTmPuDnHhCD1sYdFZpVUz8nCdJGSQIKJKKN/KTMZB9fLRIiBVlO+ytGGaByWHR D6a7dft+h4gjI4wXYLRbgQNw/3mIAz7bixfbscEsCzpDteRAJPpQmt09kDY9qFRzjBUp VpWyUTlGfAlMwPLH0D/zac2HlyWl/W/EHWbtP3YQJnOFer5eqJ01ZSR8U5S0THBEa6Xt RLPIH4wSSxZr9Imw773tkD8zlr+QhF2fKAYXXil13icq7JrpbUV4x649PmTHPyDm18Yp YvTwSPaQsp92fBVFHitobFvtR8Ajam1gZeB8ZJ0uKqfXoD/j2NZtOZF5G3L1+e2SEuuW YCsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wbj4+3nQZOlUvjlj9E1rdHY/CoHAepBEQGTnaZyBhXI=; b=m1ZCv3CHHcvGKePKlZvzJqSWlocVZmW+eUU7jAm4VB0JFQy5AOS4H9RiENuQNdks+K teqKS5mRmhFdwUFIdMxN1N6C1D5c/OXHpeaU4F8sgxvp6sUM3RfhLt2StBrm7k6P89lU DoQDmIZ71V0oX97z43Gw5hxELr106B+ThHxYxcLQR2yc+nRypk8uHNeuFe3aeJ5PVIXw N8JB5YTpbTsp0YBd8NUDcSx7jhdpsh+GVRL4F0XkiMPkChw7nJxXXwmPsT8KoJtd/SM0 OjwhxuXHjRPyOMTepoeo3wukv75QIuTqblmn3bA20+5pkLqzu+PjBS4kshouusv1ILDI FG9A== X-Gm-Message-State: AMke39nylHk0sSlKTUTuR3EBBvgA/L5q6Rdq8qwqGWlRCCT30BEPRLy7/V6LIIWnPb6Zfl+F+pt3Zf0S6MGGXQ== X-Received: by 10.55.7.7 with SMTP id 7mr17744274qkh.228.1488490597056; Thu, 02 Mar 2017 13:36:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.55.232 with HTTP; Thu, 2 Mar 2017 13:36:36 -0800 (PST) In-Reply-To: <6a33c1d3-9a9a-674b-1fc7-a1bc17aafead@gmail.com> References: <9C5FD3EFA72E1740A3D41BADDE0B461FC61A4621@szxema506-mbs.china.huawei.com> <84675BAA8C49154AB81E2587BE8BDF833D3556AD@FR711WXCHMBA07.zeu.alcatel-lucent.com> <84675BAA8C49154AB81E2587BE8BDF833D36EDAA@FR711WXCHMBA07.zeu.alcatel-lucent.com> <6a33c1d3-9a9a-674b-1fc7-a1bc17aafead@gmail.com> From: Tom Herbert Date: Thu, 2 Mar 2017 13:36:36 -0800 Message-ID: Subject: Re: Hop-by-hop options [Re: Routing directorate review of draft-ietf-6man-rfc2460bis] To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtg-ads@ietf.org" , "draft-ietf-6man-rfc2460bis.all@ietf.org" , "Papadimitriou, Dimitri \(Nokia - BE\)" , "ipv6@ietf.org" , "rtg-dir@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 21:36:40 -0000 On Thu, Mar 2, 2017 at 1:25 PM, Brian E Carpenter wrote: > On 03/03/2017 10:02, Papadimitriou, Dimitri (Nokia - BE) wrote: > ... >> Section 4.8: states "New hop-by-hop options are not recommended because = nodes may be configured to ignore the Hop-by-Hop Option header, drop packet= s containing a hop-by-hop header" does this configuration change because op= tions are new or old ? there seems to be confusion here between "new vs. ex= isting" options and "intermediate nodes MAY be configured to ignore/drop pa= ckets with these options included". > > Middleboxes *might* be configured to do something sensible with existing = HbH options (such as ignoring them) and something annoying with unknown new= ones (such as kicking them to the slow path or dropping the packet). So ye= s, the situation is worse for new options than for ones that have been defi= ned years ago. But they are both risky. > Right, but in the current state of things any EH has proven hard to successfully deploy in practice. IMO it's more of an implementation problem that needs to be addressed rather than a protocol specification problem. If the recommendation is to not create new HBH options because of this it seems like this affirms protocol ossification and maybe we've lost the battle! Tom From nobody Thu Mar 2 14:21:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3573C128B38 for ; Thu, 2 Mar 2017 14:21:19 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3aW8dkPMz122 for ; Thu, 2 Mar 2017 14:21:17 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD38126BF7 for ; Thu, 2 Mar 2017 14:21:17 -0800 (PST) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v22ML8xN044661 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Mar 2017 22:21:08 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <58B89AD3.3000806@foobar.org> Date: Thu, 02 Mar 2017 22:21:07 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.10 (Macintosh/20170123) MIME-Version: 1.0 To: Lorenzo Colitti Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> <58B74D22.5010104@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:21:19 -0000 Lorenzo Colitti wrote: > Let me rephrase the question. I asked for use cases for longer-than-/64 > prefixes and listed the ones I have seen so far: > > * "I only need 3 addresses" (but not "I only need 3 addresses and > here's why I can't accept 2^64 instead of 3") > * ND exhaustion attacks > > Do you have additional use cases? "This is the way we've done it for 20 > years" is not a use case. Thank you for rephrasing the question in a neutral way. Here is my answer: https://www.ietf.org/mail-archive/web/ietf/current/msg101724.html We will probably need to agree to disagree on it. Nick From nobody Thu Mar 2 14:43:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A986128E18 for ; Thu, 2 Mar 2017 14:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 XZ9rAnweyFek for ; Thu, 2 Mar 2017 14:43:52 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E85126BF7 for ; Thu, 2 Mar 2017 14:43:51 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 6DE7DB71 for ; Thu, 2 Mar 2017 22:43:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1WBzobzwTb4 for ; Thu, 2 Mar 2017 16:43:51 -0600 (CST) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 3AAD59F0 for ; Thu, 2 Mar 2017 16:43:51 -0600 (CST) Received: by mail-ua0-f199.google.com with SMTP id f54so58756488uaa.5 for ; Thu, 02 Mar 2017 14:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:from:date:message-id:subject:to; bh=RrD97a5bvxfS8prcZHSebPOWiKrJVqzq9M2v3iUJxwM=; b=kcxGTt+QXruZiky7JkHtaafXc2gtxTWmSAb9dGmphRA1GFbeC5tE9oL/s+Mqq59ZSB 1zAQeHqrJXUG2TLCtcY9fHYRYEk3FJ5XTx9IYbSwBl8lJv4kohTrzLRVFCWW8ZfxK73B e36I/7nQNUTJTAROqi5/XIR3cbwLBO7NyzOxje7HAqzdgh5ozyKb/qpHf3Ku1Dxc/NgA or5cGwu9FrHCaYFNsV8OVE5T556ZY13lAUrDKGFbHLh3ycWGVHcTMPvQzBhQpgaLFuT7 jWNJuPLw0luRbiM8ofKGFyOHPRtqJrLl4GKhcmRwaWY9xWgQlzsrO09KgKGFaiNSF8K+ OXhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RrD97a5bvxfS8prcZHSebPOWiKrJVqzq9M2v3iUJxwM=; b=FlG1fL8b1gdKpkJU0vSvNjOTAOSzuyK9H+LAiechyD6ciaEwfBr2FvFBUzdTZwIEIc nnZ3UGSy3KSZpKMEo1iKphvaZo+83FD8xcnIbcRZ/fBwGwOp+HVVw7hVFoeG5un5JIVi 0AywTDSnDnmgjf8zBxgYEt8rRCgIdgtMzQaSd1yHNVdHeVryaZ9LMXHiYzQMX3NjdRDu hTG3U6oYtk1vxmby6Fegf5+AhmyBipXgkPvsbdsREj7iNnxNtwrl9CSvWYhvPSr/efis ic0WF0I2xAwzZ9CnzDfPAlTLlHL/9sIVrnMOgSMnwF1H2SA+gPPq2DxlBg0lN90tVTjo GfGg== X-Gm-Message-State: AMke39lr6akqTZFBw87ueST6rlBeQE051CjhKL9VQAQu9qKkVrIs9aTjW7wmn5F/6Wsc9sCl5qL5OAK9xUnMPRTfUsvZAF4pDSjiqnAnwmrzqGYmc49ZTYQ+DA/81gCjdWqL/0O5vhgv9erhDJM= X-Received: by 10.31.204.197 with SMTP id c188mr4208973vkg.31.1488494630462; Thu, 02 Mar 2017 14:43:50 -0800 (PST) X-Received: by 10.31.204.197 with SMTP id c188mr4208967vkg.31.1488494630212; Thu, 02 Mar 2017 14:43:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.89.71 with HTTP; Thu, 2 Mar 2017 14:43:49 -0800 (PST) From: David Farmer Date: Thu, 2 Mar 2017 16:43:49 -0600 Message-ID: Subject: A proposal for draft-ietf-6man-rfc4291bis-07 To: 6man WG Content-Type: multipart/alternative; boundary=001a114dd5d0af5e4a0549c7292c Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:43:54 -0000 --001a114dd5d0af5e4a0549c7292c Content-Type: text/plain; charset=UTF-8 I've been thinking about this, really hard, and listening to what others are saying. I think we want to say the following; 1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not classful! 2. Subnet Prefixes of 64 bits are RECOMMENDED 3. IIDs are REQUIRED to be 64 bits 4. Say nothing that would imply you cannot configure a prefix length longer than 64 bits in length, at least manually. 5. Avoid all explicit exceptions, like RFC6164, etc... How about in the current draft remove the 2nd paragraph of 2.4, then add the following paragraph at the end of section 2.4 IPv6 unicast routing is based on prefixes of any length up to 128 bits [BCP198]. However, subnet prefixes of 64 bits in length are recommended in normal use. Furthermore, subnet prefixes and Interface IDs both of 64 bits in length are required when a unicast address is formed from a subnet prefix and an Interface ID. Otherwise, when a subnet prefix of another length is used then a unicast address is assumed to have no internal structure and is treated as a single 128 bit quantity. The rationale for the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. Then in the 4th paragraph of 2.4.1 As noted in Section 2.4, when a unicast address is formed from a subnet prefix and an Interface ID, both are required to be 64 bits in length. I think this accomplishes the 5 goals above and is not inconsistent with at least the intent of RFC4291. If you read section 2.5 of the RFC4291, I think my new paragraph is only more clearly restating what is said there already. Note that SLACC and other things that use IIDs have 64 bits required for the IID and subnet prefix length. But, it should also be noted that host are not required to have any knowledge of an addresses structure including its own addresses, therefore IIDs are in fact optional. Additionally, 64 bit prefix lengths are recommend for everything, including manual config and DHCP, but manual config and DHCP are allowed other prefix lengths as well. Also, the exception for unicast addresses that begin with 000 is no longer really necessary. Rotten tomatoes and eggs now please. :) Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114dd5d0af5e4a0549c7292c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I've been thinking about this, really hard, and listen= ing to what others are saying. I think we want to say the following;
    1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not classful!<= br>2. Subnet Prefixes of 64 bits are RECOMMENDED
    3. IIDs are REQUIRED=C2= =A0to be 64 bits
    4. Say nothing that would imply you cannot configure a = prefix length longer than 64 bits in length, at least manually.
    5. Avoi= d all explicit exceptions, like RFC6164, etc...

    How about in the cu= rrent draft remove the 2nd paragraph of 2.4, then add the following paragra= ph at the end of section 2.4

    =C2=A0 =C2=A0IPv6 unicast routing = is based on prefixes of any length up to 128
    =C2=A0 =C2=A0bits [BCP198].= However, subnet prefixes of 64 bits in length are
    =C2=A0 =C2=A0recommen= ded in normal use. Furthermore, subnet prefixes and
    =C2=A0 =C2=A0Interfa= ce IDs both of 64 bits in length are required when a unicast
    =C2=A0 =C2= =A0address is formed from a subnet prefix and an Interface ID. Otherwise,=C2=A0 =C2=A0when a subnet prefix of another length is used then a unicas= t address
    =C2=A0 =C2=A0is assumed to have no internal structure and is t= reated as a single
    =C2=A0 =C2=A0128 bit quantity. The rationale for the = 64 bit boundary in IPv6
    =C2=A0 =C2=A0addresses can be found in [RFC7421= ].=C2=A0

    Then in the 4th paragraph of 2.4.1
    =C2=A0 =C2=A0As noted in Section 2.4, when a unicast address is formed fro= m a
    =C2=A0 =C2=A0subnet prefix and an Interface ID, both are required t= o be 64 bits
    =C2=A0 =C2=A0in length.

    I think this accomplishes t= he 5 goals above and is not inconsistent with at least the intent of RFC429= 1. If you read section 2.5 of the RFC4291, I think my new paragraph is only= more clearly restating what is said there already.

    Note that SLACC and other things that use IIDs have 64 bits required for = the IID and subnet prefix length.=C2=A0 But, it should also be noted that h= ost are not required to have any knowledge of an addresses structure includ= ing its own addresses, therefore IIDs are in fact optional. =C2=A0 Addition= ally, 64 bit prefix lengths are recommend for everything, including manual = config and DHCP, but manual config and DHCP are allowed other prefix length= s as well.=C2=A0 =C2=A0Also, the exception for unicast addresses that begin= with 000 is no longer really necessary.

    Rotten=C2= =A0tomatoes and eggs now please. :)

    Thanks. =C2=A0=

    =C2=A0--
    =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking & Tele= communication Services
    Office of Information Technology
    University of= Minnesota=C2=A0=C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Phone: 612-626-0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612= -812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
    --001a114dd5d0af5e4a0549c7292c-- From nobody Thu Mar 2 14:49:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380C6128E18 for ; Thu, 2 Mar 2017 14:49:13 -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 autolearn_force=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 GCXo5Vse-jw8 for ; Thu, 2 Mar 2017 14:49:11 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6A7127A90 for ; Thu, 2 Mar 2017 14:49:10 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id B499224AE09; Thu, 2 Mar 2017 22:49:01 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id CC38216009F; Thu, 2 Mar 2017 22:49:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AAC2E1600A6; Thu, 2 Mar 2017 22:49:00 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZWhTLX3f3FGm; Thu, 2 Mar 2017 22:49:00 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D463016009F; Thu, 2 Mar 2017 22:48:59 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E63AB65D34EC; Fri, 3 Mar 2017 09:48:56 +1100 (EST) To: Alexandre Petrescu From: Mark Andrews References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt In-reply-to: Your message of "Thu, 02 Mar 2017 21:23:56 +0100." <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> Date: Fri, 03 Mar 2017 09:48:56 +1100 Message-Id: <20170302224856.E63AB65D34EC@rock.dv.isc.org> Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:49:13 -0000 In message <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com>, Alexandre Petrescu writes: > Le 02/03/2017 20:25, JORDI PALET MARTINEZ a crit : > > I understood from one of your previous emails that 3GPP doesnt > > require DHCPv6-PD. > > Right - if I understand correctly, it does not require DHCPv6-PD on the > UE. Maybe in the core, but not in the UE. > > > RFC6653, suggest its use, so probably we got confused ourselves and > > 3GPP is actually using it. > > > > 6rd is a different thing, because is actually IPv4 link and IPv6 is a > > tunnel, so you typically use DHCP (v4). > > I agree. > > > In IPv6-only world (including cellular), the WAN link will be > > IPv6-only instead of dual-stack. This is already happening. > > > > If they dont use it, I guess is the same reason why big vendors > > didnt implemented yet RDDNS > > I wonder if Windows refusing RDNSS doesn't have somehting to do with its > Teredo; and extending this logic to smartphones: the lack of answers to > DHCPv6-PD issued from the UE may have something to do with 464xlat > presence. > > Could it be that 464xlat presence on UE makes it that DHCPv6-PD is > impossible on same UE? No. They are or should be orthogonal. One is about providing IPv4 as as service. The other is about providing IPv6 address space. > > Cellular world is using 464XLAT, and they use DHCPv6-PD. Check > > RFC6877. > > I guess you mean cellular stations (like BS, not the User Equipment) > uses DHCPv6-PD within the fixed network. No, the UE should be using DHCPv6-PD. This is how tethered equipement should be getting IPv6 address space. > Because cellular operator I am aware of replies to DHCPv6-PD requests > issued from an User Equipment. > > Alex > > > > > Saludos, Jordi > > > > > > -----Mensaje original----- De: ipv6 en nombre > > de Alexandre Petrescu Responder a: > > Fecha: jueves, 2 de marzo de 2017, > > 20:15 Para: Asunto: Re: Objection to > > draft-ietf-6man-rfc4291bis-07.txt > > > > > > > > Le 02/03/2017 20:06, JORDI PALET MARTINEZ a crit : > >> I guess because the lack of DHCPv6-PD support, as you already > >> indicated? > > > > But for deity's sake - DHCPv6-PD is available as open source... it's > > common software. Just download and install. The IETF Specs suggest > > it, and the 3GPP specs require it too. > > > > There must be something else making these router equipment > > manufacturers refraining from downloading and installing DHCPv6-PD. > > > >> I think majority of the households and business customers get > >> configured the CPE by means for DHCPv6-PD > > > > AFAIK my CPE at home does not use DHCPv6-PD, but something based on > > IPv4, like 6rd. I think it's something developped in-house at that > > particular operator. > > > > Alex > > > >> > >> Saludos, Jordi > >> > >> > >> -----Mensaje original----- De: ipv6 en > >> nombre de Alexandre Petrescu > >> Responder a: Fecha: jueves, 2 de > >> marzo de 2017, 20:02 Para: Asunto: Re: Objection > >> to draft-ietf-6man-rfc4291bis-07.txt > >> > >> > >> > >> Le 02/03/2017 19:54, JORDI PALET MARTINEZ a crit : > >>> Actually, is not correct that most use /56 for residential. > >>> > >>>> From my last review of the survey, worldwide, 22% use /48, 35% > >>>> use /56, but there is a lot of ISPs (33%) doing it wrong and > >>>> using /64, which of course, we are explaining them that is > >>>> wrong. 10% use other sizes. > >> > >> So how comes that households can get /56s but smartphones no? > >> > >> Really there must be something there hidden. > >> > >> Alex > >> > >>> > >>> Full details at: > >>> > >>> > https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-s > urvey > > > >>> > >>> > >>> > >>> > >>> > > > >>> > >>> > >> > >>> Saludos, Jordi > >>> > >>> > >>> -----Mensaje original----- De: ipv6 en > >>> nombre de Mikael Abrahamsson Organizacin: > >>> People's Front Against WWW Responder a: > >>> Fecha: jueves, 2 de marzo de 2017, 19:33 Para: Alexandre > >>> Petrescu CC: > >>> Asunto: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt > >>> > >>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > >>> > >>>> YEs yes, but how much of that /44 is covering the end-users > >>>> and how much is reserved for interconnnections? > >>> > >>> Nothing. It's /44 to the GGSN/SPGW. > >>> > >>>> Ah great, but I guess few cellular operators (if any?) are > >>>> LIRs. Or maybe that's true and I didnt know. > >>> > >>> You don't know. > >>> > >>>> If all this were that simple and clearcut - there are enough > >>>> /64s out there - then why operators only assign one per one end > >>>> user? > >>> > >>> Because DHCPv6-PD hasn't been implemented in mobile networks yet > >>> (that I know of). So that's all they can do per 3GPP standards. > >>> > >>> Residential rollouts, most use /56 per customer. > >>> > >>>> From the RIRs, you can without further justification get /48 > >>>> per "site", > >>> so if you show up to RIR and you're LIR and you say "hello, I > >>> have 40 million customers and I want to give each customer a /48" > >>> then they'll give you a /22 most likely. You're perfectly within > >>> your right as an operator to deploy /48 per customer per current > >>> RIR rules that I am aware of. > >>> > >>> -- Mikael Abrahamsson email: swmike@swm.pp.se > >>> > >>> -------------------------------------------------------------------- > > > >>> > >>> > >>> > >>> > >>> > > > >>> > >>> > >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > > > >>> > >>> > >>> > >>> > >>> > > > >>> > >>> > >> > >>> > >>> > >>> > >>> > >>> ********************************************** IPv4 is over Are > >>> you ready for the new Internet ? http://www.consulintel.es The > >>> IPv6 Company > >>> > >>> This electronic message contains information which may be > >>> privileged or confidential. The information is intended to be > >>> for the use of the individual(s) named above. If you are not the > >>> intended recipient be aware that any disclosure, copying, > >>> distribution or use of the contents of this information, > >>> including attached files, is prohibited. > >>> > >>> > >>> > >>> -------------------------------------------------------------------- > > > >>> > >>> > >>> > >>> > >>> > > > >>> > >>> > >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > > > >>> > >>> > >>> > >>> > >>> > > > >>> > >>> > >> > >> > >> -------------------------------------------------------------------- > > > >> > >> > >> > >> > >> > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > >> > >> > >> > >> > >> > > > >> > >> > >> > >> ********************************************** IPv4 is over Are > >> you ready for the new Internet ? http://www.consulintel.es The > >> IPv6 Company > >> > >> This electronic message contains information which may be > >> privileged or confidential. The information is intended to be for > >> the use of the individual(s) named above. If you are not the > >> intended recipient be aware that any disclosure, copying, > >> distribution or use of the contents of this information, including > >> attached files, is prohibited. > >> > >> > >> > >> -------------------------------------------------------------------- > > > >> > >> > >> > >> > >> > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > >> > >> > >> > >> > >> > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > > > > > > ********************************************** IPv4 is over Are you > > ready for the new Internet ? http://www.consulintel.es The IPv6 > > Company > > > > This electronic message contains information which may be privileged > > or confidential. The information is intended to be for the use of > > the individual(s) named above. If you are not the intended recipient > > be aware that any disclosure, copying, distribution or use of the > > contents of this information, including attached files, is > > prohibited. > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Mar 2 16:18:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07776126B6D for ; Thu, 2 Mar 2017 16:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lFNJgGPNuAz0 for ; Thu, 2 Mar 2017 16:18:09 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC6F129578 for ; Thu, 2 Mar 2017 16:18:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v230I946060127; Thu, 2 Mar 2017 17:18:09 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v230I7C7060122 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 2 Mar 2017 17:18:07 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 2 Mar 2017 16:18:07 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 2 Mar 2017 16:18:07 -0800 From: "Manfredi, Albert E" To: David Farmer , 6man WG Subject: RE: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Topic: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Index: AQHSk6aBc0GC3/s6VkejKSh9uOtZ66GCOwMg Date: Fri, 3 Mar 2017 00:18:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 00:18:11 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERh dmlkIEZhcm1lcg0KDQo+IEkndmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzLCByZWFsbHkgaGFy ZCwgYW5kIGxpc3RlbmluZyB0byB3aGF0DQo+IG90aGVycyBhcmUgc2F5aW5nLiBJIHRoaW5rIHdl IHdhbnQgdG8gc2F5IHRoZSBmb2xsb3dpbmc7DQo+DQo+IDEuIElQdjYgdW5pY2FzdCByb3V0aW5n IGlzIDEyOCBiaXRzIGluIGxlbmd0aCBbQkNQMTk4XSwgQUtBIG5vdCBjbGFzc2Z1bCENCg0KT2th eS4NCg0KPiAyLiBTdWJuZXQgUHJlZml4ZXMgb2YgNjQgYml0cyBhcmUgUkVDT01NRU5ERUQNCg0K SWYgYSBob21lIG9yIG90aGVyIG5ldHdvcmsgaXMgYXNzaWduZWQgYSAvNjQsIHdoYXQgZG8gd2Ug cmVjb21tZW5kIGZvciBpbnRlcm5hbCBzdWJuZXR0aW5nLCB0aGVuPyBDYW4ndCBiZSBkb25lPyBP ciBkb2VzIHRoZSBJRVRGIGZvcmJpZCBJU1BzIGZyb20gYXNzaWduaW5nIC82NHM/DQoNCj4gMy4g SUlEcyBhcmUgUkVRVUlSRUTCoHRvIGJlIDY0IGJpdHMNCg0KSSB0aG91Z2h0IHRoaXMgaW50ZXJt aW5hYmxlIGxhc3QgY2FsbCB3YXMgc3BlY2lmaWNhbGx5IGJlY2F1c2UgbWFueSBvZiB1cyBvYmpl Y3QgdG8gdGhpcyBpZGVhLiBXaXRoIHRob3NlIGV4Y2VwdGlvbnMgc3VjaCBhcyBTTEFBQyBvbiBF dGhlcm5ldC4gT3IgbWF5YmUgSUlEcyBzaG91bGQgbm90IGJlIGxvbmdlciB0aGFuIDY0IGJpdHM/ DQoNCj4gNC4gU2F5IG5vdGhpbmcgdGhhdCB3b3VsZCBpbXBseSB5b3UgY2Fubm90IGNvbmZpZ3Vy ZSBhIHByZWZpeCBsZW5ndGggbG9uZ2VyIHRoYW4gNjQgYml0cyBpbiBsZW5ndGgsIGF0IGxlYXN0 IG1hbnVhbGx5Lg0KDQpBZ3JlZWQsIGJ1dCBkb2VzIHRoYXQgbm90IGludmFsaWRhdGUgIzM/DQoN CkJlcnQNCg0K From nobody Thu Mar 2 16:34:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECCA129667 for ; Thu, 2 Mar 2017 16:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 y1Pf_OrLj1Td for ; Thu, 2 Mar 2017 16:34:21 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B1312940D for ; Thu, 2 Mar 2017 16:34:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v230YK0d026404; Thu, 2 Mar 2017 17:34:20 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v230YGE0026396 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 2 Mar 2017 17:34:16 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 2 Mar 2017 16:34:16 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 2 Mar 2017 16:34:16 -0800 From: "Manfredi, Albert E" To: David Farmer , 6man WG Subject: RE: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Topic: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Index: AQHSk6aBc0GC3/s6VkejKSh9uOtZ66GCOwMggAAG9SA= Date: Fri, 3 Mar 2017 00:34:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 00:34:22 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERh dmlkIEZhcm1lcg0KDQo+IDMuIElJRHMgYXJlIFJFUVVJUkVEwqB0byBiZSA2NCBiaXRzDQoNCkkg dGhpbmsgdGhhdCBSRkMgNDI5MSBiaXMgc2hvdWxkIG5vdCByZXRhaW4gYSBjb25zdHJhaW50IHRo YXQgaGFzIGJlZW4gYXBwbGllZCBzbyBmYXIsIG91dCBvZiBjb252ZW5pZW5jZSwgaW4gdGhlIGVh cmxpZXN0IHN0YWdlcyBvZiBJUHY2IGRlcGxveW1lbnQuIFNvbWVob3cgdGhlIGlkZWEgb2YgZm9y Y2VkIDY0LWJpdCBJSURzIGhhcyBjcmVwdCBpbnRvIHRoZSBjdWx0dXJlLCBldmVuIHdoaWxlIGl0 IGlzIGJlaW5nIHZpb2xhdGVkIGJ5IHNvbWUgZGV2aWNlcywgcm91dGVycyBwcmltYXJpbHkuDQoN ClRvIGJlIHByYWdtYXRpYyBhYm91dCB0aGVzZSB0aGluZ3MsIGdpdmVuIHRoYXQgT1NzIHNlZW0g dG8gYnJlYWsgaWYgSUlEcyBvZiBvdGhlciBsZW5ndGhzIGFyZSBhdHRlbXB0ZWQsIG15IHN1Z2dl c3Rpb24gaXMgdG8gbGltaXQgdGhlIGRhbWFnZSB0byAqY3VycmVudCB1c2UqIG9mIHRoZSAyMDAw OjovMyB1bmljYXN0IGFkZHJlc3Mgc3BhY2UuIE5vdCB0byBleHRlbmQgaXQgdG8gYWxsIG9mIElQ djYuDQoNCkJlcnQNCg0K From nobody Thu Mar 2 17:29:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14F6129450 for ; Thu, 2 Mar 2017 17:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o8Ru-_9HT0NF for ; Thu, 2 Mar 2017 17:29:18 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34911293E8 for ; Thu, 2 Mar 2017 17:29:18 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id x66so27687684pfb.3 for ; Thu, 02 Mar 2017 17:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=NKCywcKfXMc2P8CjeR+/H5LwXf8UkLqczPgFqC2G6iU=; b=tw1melvpPLmhAfuziQUUqRbW0POFeiJXa4AeTgGxlJ6o1asTU/BLHmbW1X9W+5SdNF MMaiy1hMUeF/r5ZsjfH1z3KtfKMg2+VtU6HR49lapmu3iBZUGqnKYpuFvCfmn/boYB6o 2cXOMSi/4DuXL4gGF0vrwngZnoKpnky1ceu6m2/dcjxNS7t3qYJV9UA0OZV0yhyaA5Ww U12ybcB8T5jyUg/4dla3qptLRVgZ4pJDG8tskhQJgDLA5RFMzC24O4ZT4Uw+7/pOaZnI ZZ2pMsFGNOLjk6sUpmGsyseVjyFOzgXfVYRMiXV9j0KavCs5Bw6QfZjn9XnvU9ef4RSi 1G4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=NKCywcKfXMc2P8CjeR+/H5LwXf8UkLqczPgFqC2G6iU=; b=dvD4gLVBrgB5ODvIONJKfQHuU6gutveq9BnbJdFNoqPMLxoRTHEnhFQc/3c32Ri86T 3qwCNni5kZumLyVpmsedxI0TucMNfwgpPqZ9/fLnzSj9h5837upcF719HJRkzaIfVZ9r AbgoQ34bvORLfQMcMyE18nT3GbMetVmrfr2tijWAtdqtlopJj9gP9wZdjXbvhM9lu4wA ZcTTB0azga2uabglabgK1Gb7QAYHGiC+sLOI4x/dSWMW7mCGwFzHwhKUrB3W56EUt4mX kn7VaJVNHLtCIta2LKAxiafSsiHAKrzgyIptZz+3NcWsLOf4fdUJ913hYFQzob4Uftri CVaQ== X-Gm-Message-State: AMke39lyCxiJTlXNdth7UVq6Qj9hYo/PGUIm+idsGRNLivs544TTXynHTg5klf3Q06F/Kg== X-Received: by 10.98.24.9 with SMTP id 9mr283720pfy.11.1488504558331; Thu, 02 Mar 2017 17:29:18 -0800 (PST) Received: from [192.168.178.21] ([118.149.111.252]) by smtp.gmail.com with ESMTPSA id d1sm19349739pfk.20.2017.03.02.17.29.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Mar 2017 17:29:17 -0800 (PST) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: "Manfredi, Albert E" , David Farmer , 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> Date: Fri, 3 Mar 2017 14:29:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:29:20 -0000 On 03/03/2017 13:34, Manfredi, Albert E wrote: > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David Farmer > >> 3. IIDs are REQUIRED to be 64 bits > > I think that RFC 4291 bis should not retain a constraint that has been applied so far, out of convenience, in the earliest stages of IPv6 deployment. Agreed. And I think there are actually two things to say here: 3.1. Any IPv6-over-foo spec must specify a recommended IID length. 3.2. In the absence of such a spec, the recommended IID length is 64 bits. Again, that breaks no running code, and it respects the architectural statement that prefix_length + IID_length == 128, and the use of CIDR routing and variable-length subnet masks. Brian From nobody Thu Mar 2 17:50:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369BD129431 for ; Thu, 2 Mar 2017 17:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 Yn71jclr_3h4 for ; Thu, 2 Mar 2017 17:49:59 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D341279EB for ; Thu, 2 Mar 2017 17:49:58 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 5739DCCB for ; Fri, 3 Mar 2017 01:49:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCTHFFwvzOEP for ; Thu, 2 Mar 2017 19:49:58 -0600 (CST) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 19321B2A for ; Thu, 2 Mar 2017 19:49:57 -0600 (CST) Received: by mail-ua0-f198.google.com with SMTP id f54so60547536uaa.5 for ; Thu, 02 Mar 2017 17:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b422OQCevKr/3po9nSPHyaKmb23kTJXuBR0H/fI3504=; b=YXCmSodjXSpnuT0ulrt+DzBG8kW32cIIopQ+rv7RZ4LqX5x4dYjukFTCUeP4XbwQR3 +oTordT1hgt7/gqXqGezomx4cg91fLIqzhIRWx/S1ZOxAJ9DQ2MdEN26W0Z45HrAddwh 0RYU/7wQ1IYBoWHAK0f8Wd0I8PgbraPhVg9Xo4csfSJ7Ibz9+wTT0TCZ7ZMe1VzRQrWt Uv+2eg2qNg2POA38koaFdwZpTdYE7ZQvACUUyRJhfEVHzh+2wy47/tjfzb9xu4qvbot/ 7bzAn6hQrJYOeWYwRHGeijrszBJAjd5aYd+0bAFZEtv8owGsWJfXn7z4EbSTZCWvg9mT fJ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b422OQCevKr/3po9nSPHyaKmb23kTJXuBR0H/fI3504=; b=UIKO2uUqHOoenJU10zcVbxVt6joAS4P23NEIG6GdiPZmLH+4OiwfwvH8eP34vm5WFf o+LPiFfxTrduGQ9vqjsqUPr/i7c2gRKeKU7fMoGeG5MUHoj+DbR/NAd4XqyF0K/Us3aH IKk8T04IWEhMwwdPYkKDZdbPDxlWhtt00U6oDONHBZOFmYUmeOsXnAmXA2xdchTpakaR M3fP+rniKJFdmLPHpx1m8Cp23ofZNZuaYWKG0ooKFqrCncWdZFSK9iEuymTbV8rz7f7Y b79UvrYbAIUlMUROBpKl9hGrTl+pdHS2qb8KYr3EOaSLvyjWESpJ96XP+BW1HJWDg4Hj EuNA== X-Gm-Message-State: AMke39kDWrHn9DpevlGA8MtbzPFoKJfuBCEr2s7Vvl6SsoNhGYiUJnhnGnnYz0RBSDFrbV5Lo6LbAwRqZg3+T78Cpka+NLbyxb/lek7XSLOLOqk6uCNzqVb67wHeWzLFoCtw6CSOIOtSBuYFjFo= X-Received: by 10.176.3.81 with SMTP id 75mr75790uat.163.1488505797467; Thu, 02 Mar 2017 17:49:57 -0800 (PST) X-Received: by 10.176.3.81 with SMTP id 75mr75786uat.163.1488505797225; Thu, 02 Mar 2017 17:49:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.89.71 with HTTP; Thu, 2 Mar 2017 17:49:56 -0800 (PST) In-Reply-To: References: From: David Farmer Date: Thu, 2 Mar 2017 19:49:56 -0600 Message-ID: Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: "Manfredi, Albert E" Content-Type: multipart/alternative; boundary=001a1135208a4a4c2a0549c9c3b3 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:50:00 -0000 --001a1135208a4a4c2a0549c9c3b3 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 6:18 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David Farmer > > > I've been thinking about this, really hard, and listening to what > > others are saying. I think we want to say the following; > > > > 1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not classful! > > Okay. > > > 2. Subnet Prefixes of 64 bits are RECOMMENDED > > If a home or other network is assigned a /64, what do we recommend for > internal subnetting, then? Can't be done? Or does the IETF forbid ISPs from > assigning /64s? > First of all, a home network is essentially a site, and this is an issue discussed in section 2.4.4 which probably needs to be updated too. I think including a direct reference to RFC 6177 would be a good idea, you get there indirectly via the reference to RFC3587 and it's reference to RFC3177 which was updated by RFC6177. Furthermore, HOMENET RFC7368 says The introduction of IPv6 for home networking makes it possible for every home network to be delegated enough address space from its ISP to provision globally unique prefixes for each such subnet in the home. While the number of addresses in a standard /64 IPv6 prefix is practically unlimited, the number of prefixes available for assignment to the home network is not. As a result, the growth inhibitor for the home network shifts from the number of addresses to the number of prefixes offered by the provider; this topic is discussed in BCP 157 [RFC6177], which recommends that "end sites always be able to obtain a reasonable amount of address space for their actual and planned usage." However, if a provider only delegates a /64, this new text ensures that prefix could be further subnetted down below /64 using manual config or possibly DHCPv6. This is NOT RECOMMENDED, /64 subnets are RECOMMENDED and RFC6177 clearly RECOMMENDS sites be allow more than one /64 subnet. > > 3. IIDs are REQUIRED to be 64 bits > > I thought this interminable last call was specifically because many of us > object to this idea. With those exceptions such as SLAAC on Ethernet. Or > maybe IIDs should not be longer than 64 bits? > Variable length IIDs are a BIG CHANGE and it will break current code, I'm not sure that is a really good idea. > > 4. Say nothing that would imply you cannot configure a prefix length > longer than 64 bits in length, at least manually. > > Agreed, but does that not invalidate #3? > Nope, the new text I supplied basically says 64 bit IIDs doesn't necessarily imply every subnet on the Internet is a /64. All the way back to RFC1884 this text says "at a minimum, a node may consider that unicast addresses (including its own) have no internal structure", and an IID is just that internal structure of an address, which is OPTIONAL by that text. > Bert > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a1135208a4a4c2a0549c9c3b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Thu, Mar 2, 2017 at 6:18 PM, Manfredi, Albert E &l= t;albert.= e.manfredi@boeing.com> wrote:
    From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David Farmer

    > I've been thinking about this, really hard, and listening to what<= br> > others are saying. I think we want to say the following;
    >
    > 1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not classf= ul!

    Okay.

    > 2. Subnet Prefixes of 64 bits are RECOMMENDED

    If a home or other network is assigned a /64, what do we recommend for inte= rnal subnetting, then? Can't be done? Or does the IETF forbid ISPs from= assigning /64s?

    First of all, a home n= etwork is essentially a site, and this is an issue discussed in section 2.4= .4 which probably needs to be updated too.=C2=A0 I think including a direct= reference to RFC 6177 would be a good idea, you get there indirectly via t= he reference to RFC3587 and it's reference to RFC3177 which was updated= by RFC6177. Furthermore, HOMENET RFC7368 says

    =C2=A0 = =C2=A0The introduction of IPv6 for home networking makes it possible for=C2=A0 =C2=A0every home network to be delegated enough address space from = its ISP
    =C2=A0 =C2=A0to provision globally unique prefixes for each such= subnet in the
    =C2=A0 =C2=A0home.=C2=A0 While the number of addresses in= a standard /64 IPv6 prefix is
    =C2=A0 =C2=A0practically unlimited, the n= umber of prefixes available for
    =C2=A0 =C2=A0assignment to the home netw= ork is not.=C2=A0 As a result, the growth
    =C2=A0 =C2=A0inhibitor for the= home network shifts from the number of addresses to
    =C2=A0 =C2=A0the nu= mber of prefixes offered by the provider; this topic is
    =C2=A0 =C2=A0dis= cussed in BCP 157 [RFC6177], which recommends that "end sites
    =C2= =A0 =C2=A0always be able to obtain a reasonable amount of address space for=
    =C2=A0 =C2=A0their actual and planned usage."
    =C2=A0
    However, if a provider only delegates a /64, this new text ensures that p= refix could be further subnetted down below /64 using manual config or poss= ibly DHCPv6.=C2=A0 This is NOT RECOMMENDED, /64 subnets are RECOMMENDED and= RFC6177 clearly RECOMMENDS sites be allow more than one /64 subnet.
    <= div>=C2=A0
    > 3. IIDs are REQUIRED=C2=A0to be 64 bits

    I thought this interminable last call was specifically because many of us o= bject to this idea. With those exceptions such as SLAAC on Ethernet. Or may= be IIDs should not be longer than 64 bits?

    <= div>Variable length IIDs are a BIG CHANGE and it will break current code, I= 'm not sure that is a really good idea.
    =C2=A0
    = =C2=A0
    > 4. Say nothing that would imply you cannot configure a prefix length l= onger than 64 bits in length, at least manually.

    Agreed, but does that not invalidate #3?

    Nope, the new text I supplied basically says 64 bit IIDs doesn't nece= ssarily imply every subnet on the Internet is a /64. All the way back to RF= C1884 this text says "at a minimum, a node may=C2=A0consider that unicast addresses (= including its own) have no internal structure", and an IID is just tha= t internal structure of an address, which is OPTIONAL by that text.=C2=A0
    Bert




    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 Email= :farmer@umn.edu
    Networking & Telecommunication Services
    Offic= e of Information Technology
    University of Minnesota=C2=A0=C2=A0
    2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --001a1135208a4a4c2a0549c9c3b3-- From nobody Thu Mar 2 17:55:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF83129431 for ; Thu, 2 Mar 2017 17:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 bPdsXqdJ-wyw for ; Thu, 2 Mar 2017 17:55:44 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0C4129445 for ; Thu, 2 Mar 2017 17:55:44 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id CC5BCCC0 for ; Fri, 3 Mar 2017 01:55:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v05ABR-OGL5w for ; Thu, 2 Mar 2017 19:55:43 -0600 (CST) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 964C3CB7 for ; Thu, 2 Mar 2017 19:55:43 -0600 (CST) Received: by mail-ua0-f197.google.com with SMTP id g27so38596954uaa.1 for ; Thu, 02 Mar 2017 17:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Q34Km5a/1qz/vqmZfJlUJsHF0Y5fOMCb2J2awjvXmk=; b=R+oJTpt0T7mTH3Dm7SR3yMl8jpCeuy80kenhGZggxalOHglBht7WO51w2ArwDEwvAd gxJ9Kk1ro1/TWux2kMh5KK3n7LFjdNY+0vmSYnuGbcRCd7bVh/XeSvZx3ADw7lGo2qkH lgf9EGwt5TZkvvijR0IkquyzLsmFLiDZeYKSga00p2ANddprfDy4QX4hb5Gg98b1pBY3 nXBo0RCamt0vSZnZEXMvblQFiw7TIq0p06EAkGZL2L9Ktq+3vU0Frk10NC0fiK9B40gT Hy5xxKdXUyKMchzygP9J6A4gib1DUEcJHLC1OndZ/Kj7M5FCaovkXTJIplkp+UFiO/+o u7YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Q34Km5a/1qz/vqmZfJlUJsHF0Y5fOMCb2J2awjvXmk=; b=PRd2F5tqhv/qG3fWY0p2GUvceIaxTwjraxbsSwjUksBTuTN5dmHFAhbM6AIvks3lmS Tx+ayAyJlEBySMeHq2DYJvlA3ujo0RiiC//43dRL6bcitQ8xsEveFpBTDEaHffqcuyoP pzjLZb87yw0MX9llFbuMP9HXE+YpVDKE6KO7aFXtkeX4QCYChQG8Sp0r5ssvyHgoCn61 ctc2kgWPO1iM1jKs8nRWK1A6nq/2SFQLAihsuuspY6HeFf5wMMmCNPtJPnxmkO2M+SRp cKe+0ujE+cwcnOAWKo3wxv13+RhCuh5lIOmK8Ima2WpF++QISCEiVbhCCNX0OGL1FTyb UQFQ== X-Gm-Message-State: AMke39k+HaHFYK4bdkapKuW8Aj+5ZyuE/n3UpakXCM2Bq/6YLdbiBzA32F/UyUZYk1PCw8NbyE83kNBfgKvpuRLI7e2WfnjOdtj3Vo4TCpGp41m7WcAGKaN0bXOyPHHIdC/xnWXzXCg5Fb6sCX8= X-Received: by 10.176.5.136 with SMTP id e8mr127908uae.108.1488506142899; Thu, 02 Mar 2017 17:55:42 -0800 (PST) X-Received: by 10.176.5.136 with SMTP id e8mr127899uae.108.1488506142751; Thu, 02 Mar 2017 17:55:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.89.71 with HTTP; Thu, 2 Mar 2017 17:55:42 -0800 (PST) In-Reply-To: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> From: David Farmer Date: Thu, 2 Mar 2017 19:55:42 -0600 Message-ID: Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c124874e296560549c9d727 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:55:45 -0000 --94eb2c124874e296560549c9d727 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 7:29 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 03/03/2017 13:34, Manfredi, Albert E wrote: > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David Farmer > > > >> 3. IIDs are REQUIRED to be 64 bits > > > > I think that RFC 4291 bis should not retain a constraint that has been > applied so far, out of convenience, in the earliest stages of IPv6 > deployment. > > Agreed. And I think there are actually two things to say here: > > 3.1. Any IPv6-over-foo spec must specify a recommended IID length. > 3.2. In the absence of such a spec, the recommended IID length is 64 bits. > > Again, that breaks no running code, and it respects the architectural > statement that prefix_length + IID_length == 128, and the use of CIDR > routing and variable-length subnet masks. > > Brian > I'd be fine with that, but others seem to feel otherwise. Lorenzo and James? Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c124874e296560549c9d727 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Thu, Mar 2, 2017 at 7:29 PM, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com> wrote:
    On 03/03/2017 13:34, Manfredi, Albert E wrote:
    > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David Farmer
    >
    >> 3. IIDs are REQUIRED to be 64 bits
    >
    > I think that RFC 4291 bis should not retain a constraint that has been= applied so far, out of convenience, in the earliest stages of IPv6 deploym= ent.

    Agreed. And I think there are actually two things to say here:

    3.1. Any IPv6-over-foo spec must specify a recommended IID length.
    3.2. In the absence of such a spec, the recommended IID length is 64 bits.<= br>
    Again, that breaks no running code, and it respects the architectural
    statement that prefix_length + IID_length =3D=3D 128, and the use of CIDR routing and variable-length subnet masks.
    <= br> =C2=A0 =C2=A0 Brian

    I'= ;d be fine with that, but others seem to feel otherwise.=C2=A0Lorenzo and J= ames?

    Thanks

    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking & Tele= communication Services
    Office of Information Technology
    University of= Minnesota=C2=A0=C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Phone: 612-626-0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell= : 612-812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
    --94eb2c124874e296560549c9d727-- From nobody Thu Mar 2 18:06:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9EE129455 for ; Thu, 2 Mar 2017 18:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zJ8LLGYgrCMW for ; Thu, 2 Mar 2017 18:06:06 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7964C129431 for ; Thu, 2 Mar 2017 18:06:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v232653b064094; Thu, 2 Mar 2017 19:06:05 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v2325xs8063699 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 2 Mar 2017 19:05:59 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (137.136.239.220) by XCH15-06-10.nw.nos.boeing.com (137.136.239.219) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 2 Mar 2017 18:05:58 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 2 Mar 2017 18:05:58 -0800 From: "Manfredi, Albert E" To: David Farmer , Brian E Carpenter Subject: RE: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Topic: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Index: AQHSk6aBc0GC3/s6VkejKSh9uOtZ66GCOwMggAAG9SCAAJgEgIAAB1oA//96qjA= Date: Fri, 3 Mar 2017 02:05:58 +0000 Message-ID: <2126862bab4f49f492c40639ff1b829a@XCH15-06-11.nw.nos.boeing.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:06:07 -0000 RnJvbTogRGF2aWQgRmFybWVyIFttYWlsdG86ZmFybWVyQHVtbi5lZHVdDQoNCj4+IEJyaWFuIEUg Q2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KDQo+PiBBZ3Jl ZWQuIEFuZCBJIHRoaW5rIHRoZXJlIGFyZSBhY3R1YWxseSB0d28gdGhpbmdzIHRvIHNheSBoZXJl Og0KPj4NCj4+IDMuMS4gQW55IElQdjYtb3Zlci1mb28gc3BlYyBtdXN0IHNwZWNpZnkgYSByZWNv bW1lbmRlZCBJSUQgbGVuZ3RoLg0KPj4gMy4yLiBJbiB0aGUgYWJzZW5jZSBvZiBzdWNoIGEgc3Bl YywgdGhlIHJlY29tbWVuZGVkIElJRCBsZW5ndGggaXMNCj4+IDY0IGJpdHMuDQo+Pg0KPj4gQWdh aW4sIHRoYXQgYnJlYWtzIG5vIHJ1bm5pbmcgY29kZSwgYW5kIGl0IHJlc3BlY3RzIHRoZSBhcmNo aXRlY3R1cmFsDQo+PiBzdGF0ZW1lbnQgdGhhdCBwcmVmaXhfbGVuZ3RoICsgSUlEX2xlbmd0aCA9 PSAxMjgsIGFuZCB0aGUgdXNlIG9mIENJRFINCj4+IHJvdXRpbmcgYW5kIHZhcmlhYmxlLWxlbmd0 aCBzdWJuZXQgbWFza3MuDQo+Pg0KPj4gIMKgIEJyaWFuDQo+DQo+IEknZCBiZSBmaW5lIHdpdGgg dGhhdCwgYnV0IG90aGVycyBzZWVtIHRvIGZlZWwgb3RoZXJ3aXNlLsKgTG9yZW56bw0KPiBhbmQg SmFtZXM/DQoNClRoYXQncyB3aHkgaXQncyBjYWxsZWQgImNvbnNlbnN1cy4iIEFzIG9wcG9zZWQg dG8gdW5hbmltaXR5Lg0KDQo+IEhvd2V2ZXIsIGlmIGEgcHJvdmlkZXIgb25seSBkZWxlZ2F0ZXMg YSAvNjQsIHRoaXMgbmV3IHRleHQgZW5zdXJlcyB0aGF0DQo+IHByZWZpeCBjb3VsZCBiZSBmdXJ0 aGVyIHN1Ym5ldHRlZCBkb3duIGJlbG93IC82NCB1c2luZyBtYW51YWwgY29uZmlnIG9yDQo+IHBv c3NpYmx5IERIQ1B2Ni4NCg0KRXhhY3RseS4gU28sIGhvdyBjYW4gd2UgYWxsb3cgUkZDIDQyOTEg YmlzIHRvIHNheSB0aGF0IDY0LWJpdCBJSURzIGFyZSBSRVFVSVJFRD8gV2UgY2FuJ3QuIFRoYXQg d2FzIG15IG9yaWdpbmFsIHBvaW50Lg0KDQpCZXJ0DQoNCg== From nobody Thu Mar 2 18:24:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8E312943F for ; Thu, 2 Mar 2017 18:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0aoiRuxzIvKb for ; Thu, 2 Mar 2017 18:24:27 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E151293DA for ; Thu, 2 Mar 2017 18:24:27 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id h9so1171320qke.2 for ; Thu, 02 Mar 2017 18:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4AnJrdP59GOd4Aj8W94QENTFPMyt9okW/VluO2GHZXY=; b=bXGae9DwEFfehIi8zUtOGbXxIae+uwl2FHC81G3fmtqzfW6NfctKOvTrQooCzmdTWD tuISnni0ks4R5OKnYv80a/0BB1WHtG/2tkw9uBmpDuppexaeP5DO9a+YhvcBgRuc01BP dWWRZI60p/IBvSoFPzboqDjDsxQR4drjXVSZDvLiNVQHEX3GJf3skCLAxLZDSGlOPL+T G6E9wNfVgPwrIyF5wGochgtUeuO2P6SX02Ny6Z/tEBpN0fgtPnObbrWCU8pnmKpchQgk IRXD3u6yWHL8YoM3KZrcpo8kaT3htl43qEfOF5PmtiVxzgvKEd5fa4AYT2o2t8dwPjA+ hEwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4AnJrdP59GOd4Aj8W94QENTFPMyt9okW/VluO2GHZXY=; b=KZe6lGtijuKY3lhUAmCqecd3NxcFAZwlJFMksO02n+X0TFFDVkfb8pc/LuZbB8jZ9r oo67vedbRZKxre3aAn1Rl76AFQmrAjIrOxfvItIBXNFfgc7cUq2PELSyG0BrTPUJ1JG1 VHkNysIgCzX/7xwCI2sDzJVAb3cTKsfR+hLu67UrzOJaFymPv1H8ELVc2lDydXcQaRFv U0DZiSTOyP5rSyQhzVlSHfzrcT0BYpdLnNTi5mfG/+QrRgzMQYdoFFsnpOWgzv2M9fVG lqy+QGNTvtkq/6GWVsmTtRhoG1oj1IV2TVFtahTaav3y0UINf2qRWN/YeuLmDJm/PSuG 892g== X-Gm-Message-State: AMke39k2rGWBRf1fwYL1ahC+fgxrwrOPhJwtwEHMUkR8MsSkpyjJC0wcKbuzljSkdWi3GzRRNN3+7y34yib6IA== X-Received: by 10.55.112.66 with SMTP id l63mr355829qkc.149.1488507866244; Thu, 02 Mar 2017 18:24:26 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Thu, 2 Mar 2017 18:24:25 -0800 (PST) In-Reply-To: References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 2 Mar 2017 18:24:25 -0800 X-Google-Sender-Auth: ffztX2TMXXrcv9UMSMYJBBpT5Is Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:24:28 -0000 On Tue, Feb 28, 2017 at 4:04 AM, Alexandre Petrescu wrote: > Finally, there is no advice of what bits to put between fe80:: and a > 64bit the Interface ID - zeros or ones? linux says it's a fe80::/64 and > IIRC BSD says it's a fe80::/10. The routing entries based on that can > make for interop problems. I don't know exactly what you mean by "BSD says it's a fe80::/10", but BSD variants use a 64-bit IID to configure (e.g) an ethernet interface with a link-local address, as specified in RFC4862 and RFC2464. They also only recognize addresses that match fe80::/64 as on-link: Destination Gateway Flags Netif fe80::%em0/64 link#1 U em0 On the other hand, BSDs' implementation of the IN6_IS_ADDR_LINKLOCAL() macro only checks the first 10 bits: #define IN6_IS_ADDR_LINKLOCAL(a) \ (((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80)) If you mean this by "fe80::/10", yes, BSDs hardcorde /10 for link-local. But it has nothing to do with the length of IIDs. -- JINMEI, Tatuya From nobody Thu Mar 2 18:39:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BED129415 for ; Thu, 2 Mar 2017 18:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 mXsYq_sEDlTK for ; Thu, 2 Mar 2017 18:39:33 -0800 (PST) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD0D1293DA for ; Thu, 2 Mar 2017 18:39:33 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 99455B0B for ; Fri, 3 Mar 2017 02:39:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JN96PiJXpMU for ; Thu, 2 Mar 2017 20:39:32 -0600 (CST) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 6174175B for ; Thu, 2 Mar 2017 20:39:32 -0600 (CST) Received: by mail-ua0-f200.google.com with SMTP id f54so60955056uaa.5 for ; Thu, 02 Mar 2017 18:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H6mn3NMEuR/S0guYWElGoWnVEA1tag8KnEMlIDJPHLk=; b=b5u/6jXMA5wE/5GPYo2CUGehr82axJ/kZCcM/uaowqbHa4hSLfKiZQSDPpLK/UfMrO L/+EBydgh6ToxnIN2dTxTzcey9zHfgLc0OLzf7vC6h2cpdtrE4tmMLvpWAOi5FcBpElN OaCZ3lECShvghUZ2E7Z1ZQA69q+VWQJF1Aull2jzkQ5INs0BWO/xCYCEbXrBOC2DiQHR Ip1Yu89uoqPizQE/tA8ma1yyTuV2BbUKQCr/FF61dly51CHxCubj5jzydaV4jjc1PTBh b8+k+cZBQIZD7sEIBNvtlD3cXJ8I6A+ByXWddNl73SsgpNNTUbv7JOB11INjALriybUz nWAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H6mn3NMEuR/S0guYWElGoWnVEA1tag8KnEMlIDJPHLk=; b=a1xADbpYln2a2SQd3+SQZK3HgK6bt37a/cNJWHn14YC4Jy3zIHNce/INl5Q/MURCGj EsiCy7V24vRrNbR38qxOw9hxdHU1NPiJZfJYBdCM3VhfT0Lwzr2AIS3TdTZ4JuQwHYl1 2Iwn2tmM2QlQrXpZb+sBFz5+/LIh/ZYzI4f5cmAr7Sr7dcDzM0M3dCsHV+wLjJdGGggN x2L5kXBHJnfVQvH2+92Hqy06x+EnxKqQmR8FlTg6G0e0Rtic+VPcQWWeAspmt0j/tcpw 6oAA8zV3bdDHd2DxP4769NjGkoY5BWKFZUlXWIHryUaBWp6vVFzLYPWze2ftINoLQTGA RM0g== X-Gm-Message-State: AMke39mXOEgL4bjTo+5CM0v4tgrTxkNODcwDp9T7tF+kigC/RnG5+Mu6csMp1THqK2llOTxMKex2TEJCY4OsVr3Ppil1bEtaGdttmkQTra1Z/EwIx0+V9zOarMpEaxhI7e4iUOjA0AeXwwkjkT0= X-Received: by 10.176.76.45 with SMTP id l45mr181488uaf.151.1488508771843; Thu, 02 Mar 2017 18:39:31 -0800 (PST) X-Received: by 10.176.76.45 with SMTP id l45mr181482uaf.151.1488508771669; Thu, 02 Mar 2017 18:39:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.89.71 with HTTP; Thu, 2 Mar 2017 18:39:31 -0800 (PST) In-Reply-To: <2126862bab4f49f492c40639ff1b829a@XCH15-06-11.nw.nos.boeing.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <2126862bab4f49f492c40639ff1b829a@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Thu, 2 Mar 2017 20:39:31 -0600 Message-ID: Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: "Manfredi, Albert E" Content-Type: multipart/alternative; boundary=f4030436156094c1420549ca74cd Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:39:35 -0000 --f4030436156094c1420549ca74cd Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 8:05 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > From: David Farmer [mailto:farmer@umn.edu] > > >> Brian E Carpenter wrote: > > >> Agreed. And I think there are actually two things to say here: > >> > >> 3.1. Any IPv6-over-foo spec must specify a recommended IID length. > >> 3.2. In the absence of such a spec, the recommended IID length is > >> 64 bits. > How about, IIDs are REQUIRED to be 64 bits unless overridden by an IPv6-over-foo spec? > >> Again, that breaks no running code, and it respects the architectural > >> statement that prefix_length + IID_length == 128, and the use of CIDR > >> routing and variable-length subnet masks. > >> > >> Brian > > > > I'd be fine with that, but others seem to feel otherwise. Lorenzo > > and James? > > That's why it's called "consensus." As opposed to unanimity. > > > However, if a provider only delegates a /64, this new text ensures that > > prefix could be further subnetted down below /64 using manual config or > > possibly DHCPv6. > > Exactly. So, how can we allow RFC 4291 bis to say that 64-bit IIDs are > REQUIRED? We can't. That was my original point. > > Bert > Because, it doesn't say IIDs are themselves required. In fact it says "at a minimum, a node may consider that unicast addresses (including its own) have no internal structure". IIDs are just that internal structure of an address, which is by that text is OPTIONAL. Therefore, it is only saying if you use an IID it must be 64 bits. And I'd now suggest it should say, if you use an IID it must be 64 bits unless overridden my an IPv6-over-foo spec. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f4030436156094c1420549ca74cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Thu, Mar 2, 2017 at 8:05 PM, Manfredi, Albert E &l= t;albert.= e.manfredi@boeing.com> wrote:
    From: David Farmer [mailto:farmer@umn.edu]

    >> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

    >> Agreed. And I think there are actually two things to say here:
    >>
    >> 3.1. Any IPv6-over-foo spec must specify a recommended IID length.=
    >> 3.2. In the absence of such a spec, the recommended IID length is<= br> >> 64 bits.

    How about, IIDs are R= EQUIRED to be 64 bits unless overridden by an IPv6-over-foo spec?
    =C2=A0
    >> Again, that breaks no running code, and it respects the architectu= ral
    >> statement that prefix_length + IID_length =3D=3D 128, and the use = of CIDR
    >> routing and variable-length subnet masks.
    >>
    >>=C2=A0 =C2=A0 Brian
    >
    > I'd be fine with that, but others seem to feel otherwise.=C2=A0Lor= enzo
    > and James?

    That's why it's called "consensus." As opposed to unanimi= ty.

    > However, if a provider only delegates a /64, this new text ensures tha= t
    > prefix could be further subnetted down below /64 using manual config o= r
    > possibly DHCPv6.

    Exactly. So, how can we allow RFC 4291 bis to say that 64-bit IIDs are REQU= IRED? We can't. That was my original point.

    Bert

    Because, it doesn't say IIDs a= re themselves required.=C2=A0 In fact it says=C2=A0"at a minimum, a node may=C2=A0consi= der that unicast addresses (including its own) have no internal structure&q= uot;. IIDs are just that internal structure of an address, which is by that= text is OPTIONAL.=C2=A0 Therefore, it is only saying if you use an IID it = must be 64 bits.=C2=A0

    And I'd now suggest it should=C2=A0= say, if you use an IID it must be 64 bits unless overridden my an=C2=A0IPv6-over-foo spec.=C2=A0


    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0 Email:farme= r@umn.edu
    Networking & Telecommunication Services
    Office of I= nformation Technology
    University of Minnesota=C2=A0=C2=A0
    2218 Unive= rsity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minneapol= is, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --f4030436156094c1420549ca74cd-- From nobody Thu Mar 2 18:56:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8908612950F for ; Thu, 2 Mar 2017 18:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q7RPgNJZLIUv for ; Thu, 2 Mar 2017 18:56:02 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759F0129411 for ; Thu, 2 Mar 2017 18:56:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v232u1dI053388; Thu, 2 Mar 2017 19:56:01 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v232tsEo053249 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 2 Mar 2017 19:55:54 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 2 Mar 2017 18:55:53 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 2 Mar 2017 18:55:53 -0800 From: "Manfredi, Albert E" To: David Farmer Subject: RE: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Topic: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Index: AQHSk6aBc0GC3/s6VkejKSh9uOtZ66GCOwMggAAG9SCAAJgEgIAAB1oA//96qjCAAJGUgP//eoCA Date: Fri, 3 Mar 2017 02:55:52 +0000 Message-ID: <0128cd94732b435a9a8873501de171cf@XCH15-06-11.nw.nos.boeing.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <2126862bab4f49f492c40639ff1b829a@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:56:03 -0000 RnJvbTogRGF2aWQgRmFybWVyIFttYWlsdG86ZmFybWVyQHVtbi5lZHVdIA0KDQo+IEJlY2F1c2Us IGl0IGRvZXNuJ3Qgc2F5IElJRHMgYXJlIHRoZW1zZWx2ZXMgcmVxdWlyZWQuDQoNCkkgc2VlIHRo aXMgYXMgYmVpbmcgYSBzZW1hbnRpYyBnYW1lLiBBcyBsb25nIGFzIGFuIGFkZHJlc3MgY29uc2lz dHMgb2YgYSBwcmVmaXgsIGFuZCBpdCBoYXMgdG8gaW4gb3JkZXIgZm9yIHRoZSBwYWNrZXQgdG8g YmUgZm9yd2FyZGVkICJ0aGUgdXN1YWwgd2F5IiBhY3Jvc3Mgcm91dGVycywgdGhlIHJlbWFpbmlu ZyBiaXRzIHdpbGwgYmUgYW4gSUQgcG9pbnRpbmcgdG8gYSBzcGVjaWZpYyBpbnRlcmZhY2UuIEkg ZG9u4oCZdCB0aGluayB3ZSBhcmUgc3VnZ2VzdGluZyBoZXJlIHRoYXQgYW55IHByZWZpeCBncmVh dGVyIHRoYW4gNjQgYml0cyBNVVNUIHJlc3VsdCBpbiBhIGZsYXQgbmV0d29yay4gT3IgYXQgbGVh c3QsIEknbSBub3QuDQoNCj4gSW4gZmFjdCBpdCBzYXlzwqAiYXQgYSBtaW5pbXVtLCBhIG5vZGUg bWF5wqBjb25zaWRlciB0aGF0IHVuaWNhc3QNCj4gYWRkcmVzc2VzIChpbmNsdWRpbmcgaXRzIG93 bikgaGF2ZSBubyBpbnRlcm5hbCBzdHJ1Y3R1cmUiLg0KDQpBcyBhIG1pbmltdW0sIHN1cmUsIHRo YXQncyBhbHdheXMgdGhlIGNhc2UuIEEgbm9kZSBtaWdodCBwb3NzaWJseSBhc3N1bWUgdGhpcywg YXMgYSBtaW5pbXVtLiAiQXMgYSBtaW5pbXVtIiB0aGUgcnVsZSBjYW4gYXBwbHkgdG8gYW55IElQ djYgbm9kZSwgZXZlbiAvNjQgbm9kZXMuIEEgcm91dGVyLCBmb3IgaW5zdGFuY2UsIG1pZ2h0IGJl IGNvbmZpZ3VyZWQgdG8gb25seSByb3V0ZSB0ZW4gMTI4LWJpdCBhZGRyZXNzZXMsIGVhY2ggb25l IHRvIGEgcGFydGljdWxhciBlZ3Jlc3MgaW50ZXJmYWNlLCBhbmQgYmxpbmRseSBzZW5kIHRoZSBy ZXN0IG92ZXIgYW4gMTF0aCBlZ3Jlc3MgaW50ZXJmYWNlLCBmb3IgYWxsIG90aGVyIHRyYWZmaWMu IFRoYXQgd29ya3MgZmluZSwgYXMgbG9uZyBhcyB0aGUgbnVtYmVyIG9mIDEyOC1iaXQgYWRkcmVz c2VzIGRvZXNuJ3QgZ3JvdyB0b28gbXVjaC4NCg0KPiBBbmQgSSdkIG5vdyBzdWdnZXN0IGl0IHNo b3VsZMKgc2F5LCBpZiB5b3UgdXNlIGFuIElJRCBpdCBtdXN0IGJlDQo+IDY0IGJpdHMgdW5sZXNz IG92ZXJyaWRkZW4gbXkgYW7CoElQdjYtb3Zlci1mb28gc3BlYy4NCg0KQnV0IHRoaXMgd291bGQg bWFrZSAiYXMgYSBtaW5pbXVtIiBwaHJhc2UgbG9zZSBhbGwgaXRzIG1lYW5pbmc/IE5vdyBpdCBz YXlzIHRoYXQgdGhpcyBmbGF0IHJvdXRpbmcgc2NoZW1lIG11c3QgYmUgdGhlIG9ubHkgb25lIGFs bG93YWJsZSwgZm9yIHByZWZpeGVzID4gNjQuIFNvIEkgZG9u4oCZdCB0aGluayB0aGF0J3Mgcmln aHQuDQoNCkJlcnQNCg0K From nobody Thu Mar 2 20:31:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D231296EA for ; Thu, 2 Mar 2017 20:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 SBIv3E8FRUix for ; Thu, 2 Mar 2017 20:31:28 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1876012947F for ; Thu, 2 Mar 2017 20:31:28 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id 72so102590072uaf.3 for ; Thu, 02 Mar 2017 20:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W/GynpDdAA5bQTljTnrGDVOXYq3QRG/0L9JFN57zUL8=; b=GMMtfo+rlZHdrVYoWkLLaIsNYuXoFB0KB2rnmXiOzLyzOfhw+rd7Y6F6CkMgNJQ0s8 f/BwowaLjRDyNeVyasURWBOsx7psHyUfE6aNqhUjMKwsiSVL8uUFuK8Wm7Dz7mYRu1x+ QhTkSKy2Tt1kmIxpB0td29UKwaPIGpFnLTLLpT/bfvWKWIUVDOMbjHAo3DM66Hlggxwt SCST2YGvrgi8e8z8uN5xArv/WM046alhW0Ji00oR2IYoNBY/eSzWkzKe47fGxlMQ7u4v 6rdpPbaSx6IkKbqof0EzmpNiIfpuTgP3R8m0PcEHbnpOTU4/HTUNWjH4LPneIFfEHoiT vCmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W/GynpDdAA5bQTljTnrGDVOXYq3QRG/0L9JFN57zUL8=; b=pctMcfgL4fN8bLYD+u9GkSSgDqm4OH/if60LSS4sVEOAElzz81TwylvBch144TaSWI nSss7T/zSl3w/LC9jq+QND3mcqOz2jS9+vAoQUqaQqiq7G/IQOcmrKBWODb/LsBCAHKx R6R13LzYq6zdmbrOyZ3agbjrKovSXf1Ts/Ep8zSGUfsp+HXPTRSpMpP/aZb4E9y+J3ns 8hJslVAJk+IG55U5oHw0wpCciWU1vRg3wt5ZAZFf+edfPyi+j7TJ1MgOykPJ6ZUM9jNY bpfzsbWsAG+u/eINi5VqLD334p55bj9HQRqsvfrqdnla3+hlmRQPBx9cDL7Tgn8uWDuz b8fg== X-Gm-Message-State: AMke39nEN3eWuBNcDWpLnkeaxlOD+nwQDmaiSzjwBPV0lqctUNe0mDG5xz9c2zqonOER2S6Z9viJnk0p7sLgkus/ X-Received: by 10.176.2.71 with SMTP id 65mr239628uas.155.1488515487100; Thu, 02 Mar 2017 20:31:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 20:31:06 -0800 (PST) In-Reply-To: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> From: Lorenzo Colitti Date: Fri, 3 Mar 2017 13:31:06 +0900 Message-ID: Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11428a36da49c20549cc04ee Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 04:31:29 -0000 --001a11428a36da49c20549cc04ee Content-Type: text/plain; charset=UTF-8 On Fri, Mar 3, 2017 at 10:29 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > I think that RFC 4291 bis should not retain a constraint that has been > applied so far, out of convenience, in the earliest stages of IPv6 > deployment. > > Agreed. And I think there are actually two things to say here: > > 3.1. Any IPv6-over-foo spec must specify a recommended IID length. > 3.2. In the absence of such a spec, the recommended IID length is 64 bits. > I disagree that we should leave it up to IPv6-over-foo documents to specify an IID length. If we wanted to make a statement along these lines, the statement should be that the IID length is 64 bits unless otherwise specified in an IPv6-over-foo document. If were to end up making such a statement in this document, then this document would need to formally update RFC 7934, some of whose conclusions rest on the fact that IID lengths are currently required to be 64 bits long, to say that IID lengths of 64 are RECOMMENDED for any network that provides addresses to general-purpose hosts. We would therefore have to say, in this document, that any IPv6-over-foo document that specifies an IID shorter than 64 bits should either be specifying a technology not used by general-purpose hosts, or should bear the burden of explaining why the link layer it defines does not follow the addressing best practices in RFC 7934. --001a11428a36da49c20549cc04ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Mar 3, 2017 at 10:29 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
    > I think that RFC 4291 bis should not retain a constraint tha= t has been applied so far, out of convenience, in the earliest stages of IP= v6 deployment.

    Agreed. And I think there are actually two things to say here:

    3.1. Any IPv6-over-foo spec must specify a recommended IID length.
    3.2. In the absence of such a spec, the recommended IID length is 64 bits.<= br>

    I disagree that we should leave it up t= o IPv6-over-foo documents to specify an IID length. If we wanted to make a = statement along these lines, the statement should be that the IID length is= 64 bits unless otherwise specified in an IPv6-over-foo document.

    If were to end up making such a statement in this document,= then this document would need to formally update RFC 7934, some of whose c= onclusions rest on the fact that IID lengths are currently required to be 6= 4 bits long, to say that IID lengths of 64 are RECOMMENDED for any network = that provides addresses to general-purpose hosts.

    = We would therefore have to say, in this document, that any IPv6-over-foo do= cument that specifies an IID shorter than 64 bits should either be specifyi= ng a technology not used by general-purpose hosts, or should bear the burde= n of explaining why the link layer it defines does not follow the addressin= g best practices in RFC 7934.
    --001a11428a36da49c20549cc04ee-- From nobody Thu Mar 2 20:50:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8CC12948B for ; Thu, 2 Mar 2017 20:50: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 bvqFnsQ3efrU for ; Thu, 2 Mar 2017 20:50:10 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A21F129484 for ; Thu, 2 Mar 2017 20:50:10 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id c11so51789435uaa.0 for ; Thu, 02 Mar 2017 20:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T23ksa/5LDGbU8NLM7/nhaUQnJliki2N7eieTO8Rrlw=; b=CWXFA9ZAVG+Q7l5lO5xH6DWf4BKRiLIrjIhf7lKtzn8U2Tu5FQLZVyHc3HGp2NME6T TH38DGSc/UbfNa8AcVfoqYxiVU7IJNX2x4vMqJQkme3B3uP7bVe+DotrRQAqunkNFE3W oEx9HS8t1RdJbCPkz29Xut/OcbZzX8yCUQhm41vF9QrI+19ffUwK1ktg2N/LJmF1Xocp ebenEwEtCi+Cy54zymET8eS7WRHo/C0C3jj6so1bCBO2mUImWDTNMZrmLiXzQaTOArWr FMT110YBReovOrt/F2dwCmNbq3sDxWCnWbAkKJ56s4lrDMlFAVw6fnQnZRsIG0nA2u6Q KjlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T23ksa/5LDGbU8NLM7/nhaUQnJliki2N7eieTO8Rrlw=; b=rA3V3Dcnl2ysPYEl1c4yVF1YFfwnvrKPTiICWplNfV0vt06Jj+3PukK+jtAuWRYHwb ywQSI9r/64V5DryiZDCAT7TM2iy5C32bQRogsbLFLQC6qkDmIG1xEVqd1BFEU2r/a/OA QKZyNSv+rXnmjeC0E+gcSrY4VhGXHDOmVFLAoGWpfExQnf/FDqEXRTAKw7zQPbHheyFY 4uYLHWPrdokBMoNRXLcCPsOi9ArFlMX/LGsdyDQB1Jcy1kg+XXpHlxzoPDZb1WdDS5eD ail1s/9YakiPdlOtHsXjo0nC5AiXtIaerSGMAFHdlaI1UowzVHNjWOaEp71P7Ao2vkCa K3kA== X-Gm-Message-State: AMke39kKlEZFb4DiZVGKWTjtz79WHLfH5ORQhmjIxRjLvIn9hmP4fEzLxpzgDPz2fAoMQKzcrU4QCOwN9ACt/mmK X-Received: by 10.176.82.93 with SMTP id j29mr349480uaa.57.1488516608923; Thu, 02 Mar 2017 20:50:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 2 Mar 2017 20:49:48 -0800 (PST) In-Reply-To: <58B89AD3.3000806@foobar.org> References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> <58B74D22.5010104@foobar.org> <58B89AD3.3000806@foobar.org> From: Lorenzo Colitti Date: Fri, 3 Mar 2017 13:49:48 +0900 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Nick Hilliard Content-Type: multipart/alternative; boundary=94eb2c1916a4b7e6e40549cc4721 Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 04:50:12 -0000 --94eb2c1916a4b7e6e40549cc4721 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 3, 2017 at 7:21 AM, Nick Hilliard wrote: > > Let me rephrase the question. I asked for use cases for longer-than-/64 > > prefixes and listed the ones I have seen so far: > > > > * "I only need 3 addresses" (but not "I only need 3 addresses and > > here's why I can't accept 2^64 instead of 3") > > * ND exhaustion attacks > > > > Do you have additional use cases? "This is the way we've done it for 20 > > years" is not a use case. > > Thank you for rephrasing the question in a neutral way. Here is my answer: > > https://www.ietf.org/mail-archive/web/ietf/current/msg101724.html > > We will probably need to agree to disagree on it. > Actually, I agree with the comment itself. What I would like you to do is implement your comment. I think what I above call "use cases" is what your linked email calls "field deployment issues". If so, then my question becomes: can you provide concrete examples of said field deployment issues? What can't you do if all your subnets are fixed to /64? If we don't have concrete examples, all we have is "some operators say fixed /64 is bad". But we don't know why they say it's bad, and how bad it is, or even how many of those operators say it's bad. If nobody disagreed with the staetments being made by the operators on this thread, that would be fine. But because there *is* disagreement, then reaching consensus requires finding a balance between what those operators say is best and what others in this thread (mostly host developers) say is best. That requires concrete examples, so that we can all look at the engineering tradeoffs together. I'm going to ask again: what's the harm if all your IID lengths are /64 or /127? What can't you do? (Other than use IPv6-translatable addresses, which we should have an exception for.) You're free not to answer that question at all, or to answer it with more general statements around operator feedback being important to standards development, as you have so far, but if you don't answer it with specific examples, I don't expect that you'll be able to convince the other side of the debate any more than you have so far. --94eb2c1916a4b7e6e40549cc4721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Mar 3, 2017 at 7:21 AM, Nick Hilliard <nick@foobar.org> wr= ote:
    > Let me rephrase the quest= ion. I asked for use cases for longer-than-/64
    > prefixes and listed the ones I have seen so far:
    >
    >=C2=A0 =C2=A0* "I only need 3 addresses" (but not &quo= t;I only need 3 addresses and
    >=C2=A0 =C2=A0 =C2=A0here's why I can't accept 2^64 instea= d of 3")
    >=C2=A0 =C2=A0* ND exhaustion attacks
    >
    > Do you have additional use cases? "This is the way we've done= it for 20
    > years" is not a use case.

    Thank you for rephrasing the question in a neutral way.=C2=A0 Here i= s my answer:

    https://www.ietf.org/mail-arch= ive/web/ietf/current/msg101724.html

    We will probably need to agree to disagree on it.

    =
    Actually, I agree with the comment itself. What I would like you= to do is implement your comment. I think what I above call "use cases= " is what your linked email calls "field deployment issues".= If so, then my question becomes: can you provide concrete examples of said= field deployment issues? What can't you do if all your subnets are fix= ed to /64?

    If we don't have concrete examples,= all we have is "some operators say fixed /64 is bad". But we don= 't know why they say it's bad, and how bad it is, or even how many = of those operators say it's bad. If nobody disagreed with the staetment= s being made by the operators on this thread, that would be fine. But becau= se there *is* disagreement, then reaching consensus requires finding a bala= nce between what those operators say is best and what others in this thread= (mostly host developers) say is best. That requires concrete examples, so = that we can all look at the engineering tradeoffs together.

    <= /div>
    I'm going to ask again: what's the harm if all your IID l= engths are /64 or /127? What can't you do? (Other than use IPv6-transla= table addresses, which we should have an exception for.) You're free no= t to answer that question at all, or to answer it with more general stateme= nts around operator feedback being important to standards development, as y= ou have so far, but if you don't answer it with specific examples, I do= n't expect that you'll be able to convince the other side of the de= bate any more than you have so far.
    --94eb2c1916a4b7e6e40549cc4721-- From nobody Thu Mar 2 21:41:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860B212947C for ; Thu, 2 Mar 2017 21:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 h5GGRkfr3Qqg for ; Thu, 2 Mar 2017 21:41:44 -0800 (PST) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AF612940A for ; Thu, 2 Mar 2017 21:41:44 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 8599EC50 for ; Fri, 3 Mar 2017 05:41:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zcer4-O4ee0 for ; Thu, 2 Mar 2017 23:41:43 -0600 (CST) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 3C841C22 for ; Thu, 2 Mar 2017 23:41:43 -0600 (CST) Received: by mail-ua0-f197.google.com with SMTP id q7so33195293uaf.0 for ; Thu, 02 Mar 2017 21:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rDIeBZIWu3+PSwaV22kBhbqIpSSc4M8KhYKH8xsrz0s=; b=O2NU99I8h5bmNagipl5H+kjXdQDoi2Z5WDfFuwde8Mej9yAgtk3Mu9PcfNdsh+Eh0w I/jYYreMt85R42FeuSxI4keA0Cya4Q+DO4lmBAl6qCgU7O0Wy95rvFyICqiskVuWokoD xMcKIe187Ed9aeJZIyhCaPvjwc+DitIv48j4q4a1FJWd8THK7vso2FHGTXFAumcuDRQF rlVGqA6yAvEWRRXqlPK8V2Ez/dKM1stJEs4Nb1J8RwUujtqp2xMcfg0Pz6FSJN1Wg7ae 67d9AspfAm9/YMt3nt8WU6CN/0J/VtDmmCmN2Po34k7dpDYmtOweSt/qppc7tJWOjklx Am6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rDIeBZIWu3+PSwaV22kBhbqIpSSc4M8KhYKH8xsrz0s=; b=M+RiUYFvMetjOP7rC/PjUkd/gtbmhKJgRcyEeSel4iazsJKIT5YyZs8CMQshHJHUSe 5UpKJXqUYtYR322HerncaOO5z1zGA38gCRgux/guDAadUFT74HC8g43fkEEkw+H2uoLY ZLMc6wbc2L17ZZVtgSVNXTCy5INoogS0e7fjsiK/imBO6YZqFCkhy+WODPBXxWc/+RFU lwfPLITIcbs7o/sz3CoE2Fw9wdKJA7bsEu0ltS4mA5mhBey5d0wLpcywokWKUmvU+Hng OV/jO3k344OZ6LcWef94ElGiQqVL8xamuibtWJgiePGcSeBmt6tXKP8gWcAhSfAEn1x/ 9YDA== X-Gm-Message-State: AMke39k1aWCdzkY6qq9DFY5t7Eu9Xf5JaU8Gb16/E/D7w8aIEL3+r0ffBHlub4g/sN3pzQQ+I8nLKgoTrJivQ3kzXbD0m3EI1VHTI4l5k4i65DG4L4BNtQoid26diPs3uD/4PbaoPL37YuywBDQ= X-Received: by 10.31.49.81 with SMTP id x78mr368941vkx.82.1488519702516; Thu, 02 Mar 2017 21:41:42 -0800 (PST) X-Received: by 10.31.49.81 with SMTP id x78mr368937vkx.82.1488519702197; Thu, 02 Mar 2017 21:41:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.89.71 with HTTP; Thu, 2 Mar 2017 21:41:41 -0800 (PST) In-Reply-To: <0128cd94732b435a9a8873501de171cf@XCH15-06-11.nw.nos.boeing.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <2126862bab4f49f492c40639ff1b829a@XCH15-06-11.nw.nos.boeing.com> <0128cd94732b435a9a8873501de171cf@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Thu, 2 Mar 2017 23:41:41 -0600 Message-ID: Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: "Manfredi, Albert E" Content-Type: multipart/alternative; boundary=001a114388b01753e10549cd0030 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 05:41:45 -0000 --001a114388b01753e10549cd0030 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 2, 2017 at 8:55 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > From: David Farmer [mailto:farmer@umn.edu] > > > Because, it doesn't say IIDs are themselves required. > > I see this as being a semantic game. As long as an address consists of a > prefix, and it has to in order for the packet to be forwarded "the usual > way" across routers, the remaining bits will be an ID pointing to a > specific interface. I don=E2=80=99t think we are suggesting here that any= prefix > greater than 64 bits MUST result in a flat network. Or at least, I'm not. > > > In fact it says "at a minimum, a node may consider that unicast > > addresses (including its own) have no internal structure". > > As a minimum, sure, that's always the case. A node might possibly assume > this, as a minimum. "As a minimum" the rule can apply to any IPv6 node, > even /64 nodes. A router, for instance, might be configured to only route > ten 128-bit addresses, each one to a particular egress interface, and > blindly send the rest over an 11th egress interface, for all other traffi= c. > That works fine, as long as the number of 128-bit addresses doesn't grow > too much. > > > And I'd now suggest it should say, if you use an IID it must be > > 64 bits unless overridden my an IPv6-over-foo spec. > > But this would make "as a minimum" phrase lose all its meaning? Now it > says that this flat routing scheme must be the only one allowable, for > prefixes > 64. So I don=E2=80=99t think that's right. > > Bert > Well I'll agree it's subtle, it needs to be explained better in RFC4291bis, and I probably haven't hit the mark yet, but it's more than just semantics. If I configure an interface as 2001:DB8::1/64, that is saying that the interface has 128 bit address and a subnet length of 64 bits. It's not saying the subnet prefix is 2001:DB8::0/64 and the IID is 1 with an IID length of 64. Similarly, if I configured my interface with 2001:DB8::1/120, that is saying that the interface has 128 bit address and a subnet length of 120 bits. It's not saying the subnet prefix is 2001:DB8::0/120 and the IID is 1 with an IID length of 8. Now I could also configure the address of an interface as 2001:DB8::1 with no prefix length, it then should look for an RA for that link and if there is a PIO for prefix 2001:DB8::0, and lets say it has a prefix length of 120 and with an "L" flag and no "A" flag. In my opinion that should work and communicate with another host on the link with an interface configured similarly, with say 2001:DB8::2. Furthermore, if another host on that link had an interface configure with 2001:DB8::1001, they shouldn't communicate, as that address isn't on link by that PIO. And in all of those cases, 2001:DB8::1/64, 2001:DB8::1/120, or 2001:DB8::1, 2001:DB8::2, 2001:DB8::1001 with no prefix length, there is also a link local address with an IID of length of 64 and a prefix of FE80::0/64 and was auto generated with SLAAC. And stateful DHCPv6 doesn't provide an IID either, it provides a full 128 bit IPv6 address, but doesn't provide a prefix length or a router, that is learned from the RA and it's PIOs. I agree with Randy that's another thing to fix, but that's a fight for a different day, and completely independent of this. So saying that all IIDs are required to be 64 bits, doesn't actually imply all subnet prefixes are /64. It only says you can't generate an IPv6 address using an IID on a network with a subnet prefix other than /64, and you probably can't (or at least shouldn't) set the "A" flag on PIO for prefix other than /64. However, can manually configure or get an address via DHCPv6 for subnet prefix other than /64. This why we have to correct RFC4291bis by recommending /64 subnet prefixes, because it's ambiguous now, and would be much cleaner if it was clearly recommended. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114388b01753e10549cd0030 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= hu, Mar 2, 2017 at 8:55 PM, Manfredi, Albert E <albert.e.manfre= di@boeing.com> wrote:
    From: David Farmer [mailto:farmer@umn.edu]

    > Because, it doesn't say IIDs are themselves required.

    I see this as being a semantic game. As long as an address consists of a pr= efix, and it has to in order for the packet to be forwarded "the usual= way" across routers, the remaining bits will be an ID pointing to a s= pecific interface. I don=E2=80=99t think we are suggesting here that any pr= efix greater than 64 bits MUST result in a flat network. Or at least, I'= ;m not.

    > In fact it says=C2=A0"at a minimum, a node may=C2=A0consider that= unicast
    > addresses (including its own) have no internal structure".

    As a minimum, sure, that's always the case. A node might possibly assum= e this, as a minimum. "As a minimum" the rule can apply to any IP= v6 node, even /64 nodes. A router, for instance, might be configured to onl= y route ten 128-bit addresses, each one to a particular egress interface, a= nd blindly send the rest over an 11th egress interface, for all other traff= ic. That works fine, as long as the number of 128-bit addresses doesn't= grow too much.

    > And I'd now suggest it should=C2=A0say, if you use an IID it must = be
    > 64 bits unless overridden my an=C2=A0IPv6-over-foo spec.

    But this would make "as a minimum" phrase lose all its meaning? N= ow it says that this flat routing scheme must be the only one allowable, fo= r prefixes > 64. So I don=E2=80=99t think that's right.

    Bert

    Well I'll agree it's subtl= e, it needs to be explained better in RFC4291bis, and I probably haven'= t hit the mark yet, but it's more than just semantics.=C2=A0 If I confi= gure an interface as 2001:DB8::1/64, that is saying that the interface has = 128 bit address and a subnet length of 64 bits.=C2=A0 It's not saying t= he subnet prefix is 2001:DB8::0/64 and the IID is 1 with an IID length of 6= 4.

    Similarly, if I configured my interface with 20= 01:DB8::1/120, that is saying that the interface has 128 bit address and a = subnet length of 120 bits. It's not saying the subnet prefix is 2001:DB= 8::0/120 and the IID is 1 with an IID length of 8.

    Now I could also configure the address of an interface as 2001:DB8::1 with= no prefix length, it then should look for an RA for that link and if there= is a PIO for prefix 2001:DB8::0, and lets say it has a prefix length of 12= 0 and with an "L" flag and no "A" flag.=C2=A0 In my opi= nion that should work and communicate with another host on the link with an= interface configured similarly, with say 2001:DB8::2.=C2=A0 Furthermore, i= f another host on that link had an interface configure with 2001:DB8::1001,= they shouldn't communicate, as that address isn't on link by that = PIO.

    And in all of those cases, 2001:DB8::1/64, 20= 01:DB8::1/120, or 2001:DB8::1, 2001:DB8::2, 2001:DB8::1001 with no prefix l= ength, there is also a link local address with an IID of length of 64 and a= prefix of FE80::0/64 and was auto generated with SLAAC.

    And stateful DHCPv6 doesn't provide an IID either, it provides a= full 128 bit IPv6 address, but doesn't provide a prefix length or a ro= uter, that is learned from the RA and it's PIOs.=C2=A0 I agree with Ran= dy that's another thing to fix, but that's a fight for a different = day, and completely independent of this.=C2=A0

    So = saying that all IIDs are required to be 64 bits, doesn't actually imply= all subnet prefixes are /64.=C2=A0 It only says you can't generate an = IPv6 address using an IID on a network with a subnet prefix other than /64,= and you probably can't (or at least shouldn't) set the "A&quo= t; flag on PIO for prefix other than /64. However, can manually configure o= r get an address via DHCPv6 for subnet prefix other than /64.=C2=A0 This wh= y we have to correct RFC4291bis by recommending /64 subnet prefixes, becaus= e it's ambiguous now, and would be much cleaner if it was clearly recom= mended. =C2=A0

    Thanks.

    <= br>

    --
    =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking &am= p; Telecommunication Services
    Office of Information Technology
    Univer= sity of Minnesota=C2=A0=C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
    --001a114388b01753e10549cd0030-- From nobody Thu Mar 2 22:10:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D269C129499 for ; Thu, 2 Mar 2017 22:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 YPgvUPMZ0sCX for ; Thu, 2 Mar 2017 22:09:59 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F19E129432 for ; Thu, 2 Mar 2017 22:09:59 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 27B45A6; Fri, 3 Mar 2017 07:09:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1488521397; bh=baj1dEStni45WhZtrKTdor+kyieKC1AVavpeTvv81qM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QX3p21JcOslKm3i5ONKHyMX2fTVV/fk18rUA+1EJOyEy0sLxqYISSInxRJl6+Z31l J6JLlQ6WUfvDc9dnOtz86q/s2TmKblzrTfdmoVwVKCNsSAA9IG8K1xS/Saq0euwUOa 6XqwnkzZXvegwD5IgJipZL5/tkONyndTdKUD/dv8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 244A7A3; Fri, 3 Mar 2017 07:09:57 +0100 (CET) Date: Fri, 3 Mar 2017 07:09:57 +0100 (CET) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt In-Reply-To: Message-ID: References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1232420944-1488521397=:30226" Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 06:10:01 -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. ---137064504-1232420944-1488521397=:30226 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 2 Mar 2017, JORDI PALET MARTINEZ wrote: > I understood from one of your previous emails that 3GPP doesn’t require > DHCPv6-PD. RFC6653, suggest its use, so probably we got confused > ourselves and 3GPP is actually using it. 3GPP is like IETF, it produces documents. DHCPv6-PD has been in 3GPP documents since 2012. Market requirements then makes these documents get implemented. Sometimes almost immediately, sometimes 5 years down the line, sometimes never. DHCPv6-PD seems to be one of these functions that takes a long time. Possibly because 64SHARE is already available and solves a majority of the problem space. Current 3GPP deployments can be seen as being close to a /64 PD deployment in end-user functionality. Works for a lot of use-cases, but not what we want long term. However, very widely available in both networks and devices. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1232420944-1488521397=:30226-- From nobody Thu Mar 2 23:46:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FB51297A5 for ; Thu, 2 Mar 2017 23:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 3_mj83S_7coQ for ; Thu, 2 Mar 2017 23:46:30 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9251297A8 for ; Thu, 2 Mar 2017 23:46:30 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 03 Mar 2017 07:46:29 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B10E2D788B; Thu, 2 Mar 2017 23:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=mnteLvqmjhS+TbQLFC68hleeANg=; b= ivtScVqCPxirTC0pgR/VwO6Fu7qPPwTy3/UCOw/ZSgTwwRRdlq90qSAxX4acA94k izmIbKRYRPOQzxJVaKX4aYHpc4rfcJc7JpoUaK8iv+JBaMoIUBlaTJhokSMiD7Lx oP4XmTgbCSTU8NEyu3WuG515XAnkrOhpIqGDgAcPBMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=p0lqRcy2GhdZ+bHeX9TIzpJ SAbWZx2DyxzaboYRCsrFUkHkAgUQO26enaQIbGBl8Dd8mO4furCxdx/Sw5+l0zVP RO7fLESgyYHTMwfN6CmwUy51yzp3DAXGdng+B21ynWJo9pStrfmoHoi/Jw7qHzG9 VgEPXRBY6dejg6guE+as= Received: from h.hanazo.no (unknown [173.38.220.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 84690D788A; Thu, 2 Mar 2017 23:46:28 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 82FC293505DE; Fri, 3 Mar 2017 08:46:29 +0100 (CET) From: otroan@employees.org Message-Id: <851D594B-7E32-4C40-AA89-F95E66FBF35B@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_051E5BA8-4CE3-4747-BF83-E7E4E9ADC528"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 Date: Fri, 3 Mar 2017 08:46:28 +0100 In-Reply-To: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> To: Brian E Carpenter References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 07:46:32 -0000 --Apple-Mail=_051E5BA8-4CE3-4747-BF83-E7E4E9ADC528 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, [...] >> I think that RFC 4291 bis should not retain a constraint that has = been applied so far, out of convenience, in the earliest stages of IPv6 = deployment. >=20 > Agreed. And I think there are actually two things to say here: It is of course not done because of "convenience". > 3.1. Any IPv6-over-foo spec must specify a recommended IID length. Why? Why and how does data-link layer type influence the recommended IID = length? It made sense in the past when we created "modified EUI-64"s that were = based on the data-link layer address, but why now? > 3.2. In the absence of such a spec, the recommended IID length is 64 = bits. >=20 > Again, that breaks no running code, and it respects the architectural > statement that prefix_length + IID_length =3D=3D 128, and the use of = CIDR > routing and variable-length subnet masks. Cheers, Ole --Apple-Mail=_051E5BA8-4CE3-4747-BF83-E7E4E9ADC528 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYuR9VAAoJEL7aWKiYQt92rj8P/Arv3MJtTfzFIALamSkLtx5J xGaSb7WbDz9I1DF0d8iEwJ+mzLLTEnIuC6U7vQBHWeZCIFAT6K83qGGxmXqudZCa eUFPKeKeSFomT/GAycYPFM05TcywUAkK0PAbsTuBv07SZ8LnKOrAIS70w4MLijQN FTM2eR3AmWbjnGDd1NZdxuV03la6uU92NVlPpvKZFfnrASc+GPk7HbK7bihv7I4e htsxf0j9R3ytz2y6ORtVf4kmO0urOpYPReiJ7jSCPS3riIsDRwBiHF/fJZKmocvr EYWPHR2zrPFeucGR0aNkDS2204XuzCrSAE9nWR05ierbA3YS8CmApPG71JxbCsZS rQbJbMR9Ps+fT1v0i44/jbonCk6SF9EWR3q1k3MeJm8oqE/+9ODuSB+j3Yq9AG7v BQEZHZb46vxS5nEfSIBxWysUC5d3v3uwh4NfNAoeudndvi8lF5aNqmnZ3yP5zl97 9C1ZlGvDLrFuzAq4XA/lYPn7v/d5wMTt0NVAykRHYg52vBuNMNhBiMjaFQpkKt+M ku4BbOj7NodtBdQkExeoo37qPfD37+TTDoRjoFzzMeCitvdgDXKj//1sZ0RHwahP waRO+IoCoP8c/hzK1WKKPOaQ/D3cvrGYIe03GHgEAxMvG0L3OHqy2TVonZER9h+4 PghkL6N2cN6xJFZM62Hl =QtfX -----END PGP SIGNATURE----- --Apple-Mail=_051E5BA8-4CE3-4747-BF83-E7E4E9ADC528-- From nobody Fri Mar 3 01:17:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C75F12942F for ; Fri, 3 Mar 2017 01:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wMztUY-1Xzmj for ; Fri, 3 Mar 2017 01:17:12 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645281293F4 for ; Fri, 3 Mar 2017 01:17:12 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v239HAEC028402 for ; Fri, 3 Mar 2017 10:17:10 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 294C020122C for ; Fri, 3 Mar 2017 10:17: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 1F53E200CE6 for ; Fri, 3 Mar 2017 10:17:10 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v239H91X025294 for ; Fri, 3 Mar 2017 10:17:10 +0100 Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <96a5dfe9-0122-0f8c-5ad3-f98dc1867f25@gmail.com> Date: Fri, 3 Mar 2017 10:17:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:17:14 -0000 David, Sincerely I appreciate the effort and would like to agree to most points. But here is my answer and I wont change. Le 02/03/2017 à 23:43, David Farmer a écrit : > I've been thinking about this, really hard, and listening to what > others are saying. I think we want to say the following; > > 1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not > classful! Agreed, we want to say this. > 2. Subnet Prefixes of 64 bits are RECOMMENDED I disagree, we dont want to say this. > 3. IIDs are REQUIRED to be 64 bits I disagree. > 4. Say nothing that would imply you cannot configure a prefix length > longer than 64 bits in length, at least manually. I agree. > 5. Avoid all explicit exceptions, like RFC6164, etc... I dont know. > How about in the current draft remove the 2nd paragraph of 2.4, then > add the following paragraph at the end of section 2.4 > > IPv6 unicast routing is based on prefixes of any length up to 128 > bits [BCP198]. However, subnet prefixes of 64 bits in length are > recommended in normal use. I agree. > Furthermore, subnet prefixes and Interface IDs both of 64 bits in > length are required when a unicast address is formed from a subnet > prefix and an Interface ID. This phrase is too much. > Otherwise, when a subnet prefix of > another length is used then a unicast address is assumed to have no > internal structure and is treated as a single 128 bit quantity. The > rationale for the 64 bit boundary in IPv6 addresses can be found in > [RFC7421]. This is an explanation of the earlier phrase, and as such is too too much. > Then in the 4th paragraph of 2.4.1 > > As noted in Section 2.4, when a unicast address is formed from a > subnet prefix and an Interface ID, both are required to be 64 bits in > length. Is the 'subnet prefix' coming from an RA? From elsewhere? There are very many ways to make a subnet prefix. > I think this accomplishes the 5 goals above and is not inconsistent > with at least the intent of RFC4291. If you read section 2.5 of the > RFC4291, I think my new paragraph is only more clearly restating what > is said there already. I think your text suggestion is indeed answering the initial requirements formulated at the top. But I can not agree with it as such. Again - thank you for the effort, it is good to pursue. Alex > > Note that SLACC and other things that use IIDs have 64 bits required > for the IID and subnet prefix length. But, it should also be noted > that host are not required to have any knowledge of an addresses > structure including its own addresses, therefore IIDs are in fact > optional. Additionally, 64 bit prefix lengths are recommend for > everything, including manual config and DHCP, but manual config and > DHCP are allowed other prefix lengths as well. Also, the exception > for unicast addresses that begin with 000 is no longer really > necessary. > > Rotten tomatoes and eggs now please. :) > > Thanks. > > -- =============================================== David Farmer > Email:farmer@umn.edu Networking & > Telecommunication Services Office of Information Technology > University of Minnesota 2218 University Ave SE Phone: > 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Mar 3 01:29:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED931297CA for ; Fri, 3 Mar 2017 01:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9OLYpbA8qLgS for ; Fri, 3 Mar 2017 01:29:11 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EAE1297AA for ; Fri, 3 Mar 2017 01:29:10 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v239T8M0000845; Fri, 3 Mar 2017 10:29:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 742F5203BEF; Fri, 3 Mar 2017 10:29: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 65D7F200CE6; Fri, 3 Mar 2017 10:29:08 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v239T8rP025210; Fri, 3 Mar 2017 10:29:08 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Mark Andrews References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> <20170302224856.E63AB65D34EC@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com> Date: Fri, 3 Mar 2017 10:29:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170302224856.E63AB65D34EC@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:29:14 -0000 Le 02/03/2017 à 23:48, Mark Andrews a écrit : > > In message <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com>, > Alexandre Petrescu writes: >> Le 02/03/2017 20:25, JORDI PALET MARTINEZ a crit : >>> I understood from one of your previous emails that 3GPP doesnt >>> require DHCPv6-PD. >> >> Right - if I understand correctly, it does not require DHCPv6-PD on >> the UE. Maybe in the core, but not in the UE. >> >>> RFC6653, suggest its use, so probably we got confused ourselves >>> and 3GPP is actually using it. >>> >>> 6rd is a different thing, because is actually IPv4 link and IPv6 >>> is a tunnel, so you typically use DHCP (v4). >> >> I agree. >> >>> In IPv6-only world (including cellular), the WAN link will be >>> IPv6-only instead of dual-stack. This is already happening. >>> >>> If they dont use it, I guess is the same reason why big vendors >>> didnt implemented yet RDDNS >> >> I wonder if Windows refusing RDNSS doesn't have somehting to do >> with its Teredo; and extending this logic to smartphones: the lack >> of answers to DHCPv6-PD issued from the UE may have something to >> do with 464xlat presence. >> >> Could it be that 464xlat presence on UE makes it that DHCPv6-PD is >> impossible on same UE? > > No. They are or should be orthogonal. One is about providing IPv4 > as as service. The other is about providing IPv6 address space. I can agree. With my operator I asked her once 'why not giving DHCPc6-PD to smartphone' and she replied 'because now we do 464xlat on the smartphone, and that is sufficient'. As such it sounds illogical statement, although I guess s/he has some reasons to say so. But let me ask differently: maybe it's because 464xlat requires some kernel version that DHCPv6-PD doestn support, or vice-versa? Maybe it's because once you run 464xlat on smartphone it takes control of the unique default route and DHCPv6-PD couldnt? Some reason like that? Has one tried DHCPv6-PD software simultaneosuly with 464xlat? (even knowing the cellular operator would not reply to DHCPv6 Slicitations). >>> Cellular world is using 464XLAT, and they use DHCPv6-PD. Check >>> RFC6877. >> >> I guess you mean cellular stations (like BS, not the User >> Equipment) uses DHCPv6-PD within the fixed network. > > No, the UE should be using DHCPv6-PD. This is how tethered > equipement should be getting IPv6 address space. I agree with yuo. This is why I dont understand the cellular operators dont do DHCPv6-PD. And I guess it is so because they are told it's sufficient to run the 64share INFORMATIONAL RFC. Are the people advising 64share to tethering-willing telecom operators conscious it's non-interoperable? Is the 64share advice coming together with the claim there are enough /64s out there? Alex >> Because cellular operator I am aware of replies to DHCPv6-PD >> requests issued from an User Equipment. >> >> Alex >> >>> >>> Saludos, Jordi >>> >>> >>> -----Mensaje original----- De: ipv6 en >>> nombre de Alexandre Petrescu >>> Responder a: Fecha: jueves, 2 de >>> marzo de 2017, 20:15 Para: Asunto: Re: Objection >>> to draft-ietf-6man-rfc4291bis-07.txt >>> >>> >>> >>> Le 02/03/2017 20:06, JORDI PALET MARTINEZ a crit : >>>> I guess because the lack of DHCPv6-PD support, as you already >>>> indicated? >>> >>> But for deity's sake - DHCPv6-PD is available as open source... >>> it's common software. Just download and install. The IETF Specs >>> suggest it, and the 3GPP specs require it too. >>> >>> There must be something else making these router equipment >>> manufacturers refraining from downloading and installing >>> DHCPv6-PD. >>> >>>> I think majority of the households and business customers get >>>> configured the CPE by means for DHCPv6-PD >>> >>> AFAIK my CPE at home does not use DHCPv6-PD, but something based >>> on IPv4, like 6rd. I think it's something developped in-house >>> at that particular operator. >>> >>> Alex >>> >>>> >>>> Saludos, Jordi >>>> >>>> >>>> -----Mensaje original----- De: ipv6 en >>>> nombre de Alexandre Petrescu >>>> Responder a: Fecha: jueves, 2 >>>> de marzo de 2017, 20:02 Para: Asunto: Re: >>>> Objection to draft-ietf-6man-rfc4291bis-07.txt >>>> >>>> >>>> >>>> Le 02/03/2017 19:54, JORDI PALET MARTINEZ a crit : >>>>> Actually, is not correct that most use /56 for residential. >>>>> >>>>>> From my last review of the survey, worldwide, 22% use /48, >>>>>> 35% use /56, but there is a lot of ISPs (33%) doing it >>>>>> wrong and using /64, which of course, we are explaining >>>>>> them that is wrong. 10% use other sizes. >>>> >>>> So how comes that households can get /56s but smartphones no? >>>> >>>> Really there must be something there hidden. >>>> >>>> Alex >>>> >>>>> >>>>> Full details at: >>>>> >>>>> >> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-s >> >> >> >> urvey >>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>>>> >>>>> >>>> >>>>> Saludos, Jordi >>>>> >>>>> >>>>> -----Mensaje original----- De: ipv6 >>>>> en nombre de Mikael Abrahamsson >>>>> Organizacin: People's Front Against WWW Responder a: >>>>> Fecha: jueves, 2 de marzo de 2017, 19:33 >>>>> Para: Alexandre Petrescu CC: >>>>> Asunto: Re: Objection to >>>>> draft-ietf-6man-rfc4291bis-07.txt >>>>> >>>>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: >>>>> >>>>>> YEs yes, but how much of that /44 is covering the >>>>>> end-users and how much is reserved for interconnnections? >>>>> >>>>> Nothing. It's /44 to the GGSN/SPGW. >>>>> >>>>>> Ah great, but I guess few cellular operators (if any?) are >>>>>> LIRs. Or maybe that's true and I didnt know. >>>>> >>>>> You don't know. >>>>> >>>>>> If all this were that simple and clearcut - there are >>>>>> enough /64s out there - then why operators only assign one >>>>>> per one end user? >>>>> >>>>> Because DHCPv6-PD hasn't been implemented in mobile networks >>>>> yet (that I know of). So that's all they can do per 3GPP >>>>> standards. >>>>> >>>>> Residential rollouts, most use /56 per customer. >>>>> >>>>>> From the RIRs, you can without further justification get >>>>>> /48 per "site", >>>>> so if you show up to RIR and you're LIR and you say "hello, >>>>> I have 40 million customers and I want to give each customer >>>>> a /48" then they'll give you a /22 most likely. You're >>>>> perfectly within your right as an operator to deploy /48 per >>>>> customer per current RIR rules that I am aware of. >>>>> >>>>> -- Mikael Abrahamsson email: swmike@swm.pp.se >>>>> >>>>> -------------------------------------------------------------------- >>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>>>> >>>>> >>>> >>>>> >>>>> >>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>>>> >>>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ********************************************** IPv4 is over Are >>>>> you ready for the new Internet ? http://www.consulintel.es >>>>> The IPv6 Company >>>>> >>>>> This electronic message contains information which may be >>>>> privileged or confidential. The information is intended to >>>>> be for the use of the individual(s) named above. If you are >>>>> not the intended recipient be aware that any disclosure, >>>>> copying, distribution or use of the contents of this >>>>> information, including attached files, is prohibited. >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>>>> >>>>> >>>> >>>>> >>>>> >>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>>>> >>>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>> >>>> >>>> >>>> >>>> >>>> >>> IETF IPv6 working group mailing list ipv6@ietf.org >>> Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ********************************************** IPv4 is over Are >>>> you ready for the new Internet ? http://www.consulintel.es The >>>> IPv6 Company >>>> >>>> This electronic message contains information which may be >>>> privileged or confidential. The information is intended to be >>>> for the use of the individual(s) named above. If you are not >>>> the intended recipient be aware that any disclosure, copying, >>>> distribution or use of the contents of this information, >>>> including attached files, is prohibited. >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>>> >>>> >>>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org >>> Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> >>> >>> >>> >>> >>> >>> ********************************************** IPv4 is over Are you >>> ready for the new Internet ? http://www.consulintel.es The IPv6 >>> Company >>> >>> This electronic message contains information which may be >>> privileged or confidential. The information is intended to be for >>> the use of the individual(s) named above. If you are not the >>> intended recipient be aware that any disclosure, copying, >>> distribution or use of the contents of this information, >>> including attached files, is prohibited. >>> >>> >>> >>> -------------------------------------------------------------------- >>> >>> >>> >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> >>> >>> >>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Fri Mar 3 01:33:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BCB12941E for ; Fri, 3 Mar 2017 01:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3QTalUwrBXlS for ; Fri, 3 Mar 2017 01:33:17 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53461293F4 for ; Fri, 3 Mar 2017 01:33:16 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v239XDm1007312 for ; Fri, 3 Mar 2017 10:33:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B0C13201328 for ; Fri, 3 Mar 2017 10:33:13 +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 A6552204277 for ; Fri, 3 Mar 2017 10:33:13 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v239XDKb028445 for ; Fri, 3 Mar 2017 10:33:13 +0100 Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> From: Alexandre Petrescu Message-ID: <96ab8237-7e31-a6cf-e860-b842f975c53d@gmail.com> Date: Fri, 3 Mar 2017 10:33:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:33:18 -0000 Le 03/03/2017 à 02:29, Brian E Carpenter a écrit : > On 03/03/2017 13:34, Manfredi, Albert E wrote: >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of David >> Farmer >> >>> 3. IIDs are REQUIRED to be 64 bits >> >> I think that RFC 4291 bis should not retain a constraint that has >> been applied so far, out of convenience, in the earliest stages of >> IPv6 deployment. > > Agreed. And I think there are actually two things to say here: > > 3.1. Any IPv6-over-foo spec must specify a recommended IID length. > 3.2. In the absence of such a spec, the recommended IID length is 64 > bits. Sounds promising. But how about the links which dont specify IPv6-over-foo and simply assume IPv6-over-Ethernet (e.g.g USB, cellular)? Or should we start writing IPv6-over-foo documents? How about Ethernet links 2 hops away from the edge of the cellular network assigning only one /64. Can I write an IPv6-over-Ethernet-2hop-away-from-cellular-edge? Can I write there the IID could be 4? Alex > > Again, that breaks no running code, and it respects the > architectural statement that prefix_length + IID_length == 128, and > the use of CIDR routing and variable-length subnet masks. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Mar 3 01:36:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D371297AC for ; Fri, 3 Mar 2017 01:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 2M6VM6AnGV1o for ; Fri, 3 Mar 2017 01:36:05 -0800 (PST) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924701294BD for ; Fri, 3 Mar 2017 01:36:05 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 018C1BA7 for ; Fri, 3 Mar 2017 09:36:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYsqrjsmmcMf for ; Fri, 3 Mar 2017 03:36:04 -0600 (CST) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id C9192B96 for ; Fri, 3 Mar 2017 03:36:04 -0600 (CST) Received: by mail-ua0-f198.google.com with SMTP id f54so63866287uaa.5 for ; Fri, 03 Mar 2017 01:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t3oZcV7yKrFdFuC3xPhcmhVxAMwQiVI1zeFi6aobk0k=; b=DixV18f4SLx7/yHWlvQyXBXWCvWFL9hzm0HJQpWJFjArs+Rvqs25PiqDLfCVGKYtn6 dYSeL4HIbD5C9lgvwYUO2EVvMa7qs43vg0mdQh5HUKT/5TXJo0FbQ77w1CrtWhkmOWbh CVw5LsCF6jydmggA4ShYOAx+UOzQ2U3KXnWleYyplns4T8+T38T01GMU9MVT0W0mTGxj dZcZkgoRcTCzyTF+6kKKrS+Kedhub8TXuhWCrhyf8nnkcJJ/zS3uHsqx4nOOJGbC1rnG SyRJOGTXYQGeyxQ3wCRMvoGuKcl90/1O8u2+jEr6Y+w/sWabziyxsTnEhedPreE8MGi5 HSnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t3oZcV7yKrFdFuC3xPhcmhVxAMwQiVI1zeFi6aobk0k=; b=qnkw33nATeJfQpYv/ltKnLwGMqxnNCe+uU2jefIgVqhBI7AeLNYXwoZr3+rNh2qWV5 8Zvfg/c7ZzfR17rjt3PY1HFhIioNiJVIlc9nn/AtKzQGfKINCc2KeqxnOxtrT8X+H+YC DebJ3YccGxCRIXBhBh7OqmUzaK7xr6QSW/d/aiO1k9tbNl0t2QzEOWRgPONL4e2PnYLX /rXvnQpUQUnpoFJYSmsXTEV9JDQwIXkOMdbXzY+CZ11FH9jbdVfZFAsYxEMFgrpMIa1M u9HcZOuzphJJZ6RSH6QPba/7KeinnQLL3wJHMof8+fTzHVDRU+DSlRwvbfrnmMq6k/cH 9XyQ== X-Gm-Message-State: AMke39n6Tt6s1VucKQ4pNZcVcXIhD8G8efUs1lPoGJ9kwRvVIrSw+kNJLrQb+RinTxyn3XYnTIDo6mqT8vaob+1OhpNptAjaW+us4LvqkVZJr9hgZA8hbYUpKSkGAL7bSP3nX+uZaXuMxBwVhPM= X-Received: by 10.176.3.81 with SMTP id 75mr513627uat.163.1488533764059; Fri, 03 Mar 2017 01:36:04 -0800 (PST) X-Received: by 10.176.3.81 with SMTP id 75mr513625uat.163.1488533763885; Fri, 03 Mar 2017 01:36:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.89.71 with HTTP; Fri, 3 Mar 2017 01:36:03 -0800 (PST) In-Reply-To: <96a5dfe9-0122-0f8c-5ad3-f98dc1867f25@gmail.com> References: <96a5dfe9-0122-0f8c-5ad3-f98dc1867f25@gmail.com> From: David Farmer Date: Fri, 3 Mar 2017 03:36:03 -0600 Message-ID: Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a1135208a3ba3ce0549d04633 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:36:06 -0000 --001a1135208a3ba3ce0549d04633 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 3, 2017 at 3:17 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > Le 02/03/2017 =C3=A0 23:43, David Farmer a =C3=A9crit : > >> >> 2. Subnet Prefixes of 64 bits are RECOMMENDED >> > > I disagree, we dont want to say this. > Why, please > 3. IIDs are REQUIRED to be 64 bits >> > > I disagree. > Again why, and would be ok to RECOMMEND at least It seems wrong to completely remove any reference to 64 in the IPv6 Addressing Architecture, come on. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a1135208a3ba3ce0549d04633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Fri, Mar 3, 2017 at 3:17 AM, Alexandre Petrescu &l= t;alexand= re.petrescu@gmail.com> wrote:

    Le 02/03/2017 =C3=A0 23:43, David Farmer a =C3=A9crit :

    2. Subnet Prefixes of 64 bits are RECOMMENDED

    I disagree, we dont want to say this.

    W= hy, please=C2=A0
    =C2=A0
    3. IIDs are REQUIRED to be 64 bits

    I disagree.

    Again why, and would be ok = to RECOMMEND at least

    It seems wrong to completely= remove any reference to 64 in the IPv6 Addressing Architecture, come on.= =C2=A0

    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking & Telecommunication Service= s
    Office of Information Technology
    University of Minnesota=C2=A0=C2= =A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-08= 15
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --001a1135208a3ba3ce0549d04633-- From nobody Fri Mar 3 01:38:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8681294BD for ; Fri, 3 Mar 2017 01:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 Zs3cMjOz69FP for ; Fri, 3 Mar 2017 01:38:04 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F73A12942F for ; Fri, 3 Mar 2017 01:38:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v239c20u011166 for ; Fri, 3 Mar 2017 10:38:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B7356204270 for ; Fri, 3 Mar 2017 10:38:02 +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 AE1D8203B84 for ; Fri, 3 Mar 2017 10:38:02 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v239c2r0017503 for ; Fri, 3 Mar 2017 10:38:02 +0100 Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <2126862bab4f49f492c40639ff1b829a@XCH15-06-11.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <9cc7f281-1264-c1ee-46fa-2f591a6c2a9f@gmail.com> Date: Fri, 3 Mar 2017 10:38:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2126862bab4f49f492c40639ff1b829a@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:38:06 -0000 Le 03/03/2017 à 03:05, Manfredi, Albert E a écrit : > From: David Farmer [mailto:farmer@umn.edu] > >>> Brian E Carpenter wrote: > >>> Agreed. And I think there are actually two things to say here: >>> >>> 3.1. Any IPv6-over-foo spec must specify a recommended IID >>> length. 3.2. In the absence of such a spec, the recommended IID >>> length is 64 bits. >>> >>> Again, that breaks no running code, and it respects the >>> architectural statement that prefix_length + IID_length == 128, >>> and the use of CIDR routing and variable-length subnet masks. >>> >>> Brian >> >> I'd be fine with that, but others seem to feel otherwise. Lorenzo >> and James? > > That's why it's called "consensus." As opposed to unanimity. > >> However, if a provider only delegates a /64, this new text ensures >> that prefix could be further subnetted down below /64 using manual >> config or possibly DHCPv6. [I miss the original mail from David Farmer saying the above, in the conversation with Brian and Albert, so I reply here.] I agree, but that excludes the use of dear SLAAC/Ethernet (it requires it to be manual config or possibly DHCPv6). Or otherwise improve RFC2464 to accept other-than-64 IIDs. Do you think there could be a proposal of updating 2464 with acceptance of other-than-64 IIDs? Alex > > Exactly. So, how can we allow RFC 4291 bis to say that 64-bit IIDs > are REQUIRED? We can't. That was my original point. > > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Mar 3 01:59:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC55D12941E for ; Fri, 3 Mar 2017 01:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 40AujRdmDYEu for ; Fri, 3 Mar 2017 01:58:57 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3711297AC for ; Fri, 3 Mar 2017 01:58:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v239wruF019016; Fri, 3 Mar 2017 10:58:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3C52203FE8; Fri, 3 Mar 2017 10:58: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 D49EC20122C; Fri, 3 Mar 2017 10:58:53 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v239wrEg008129; Fri, 3 Mar 2017 10:58:53 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <20170223134026.GI5069@gir.theapt.org> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> From: Alexandre Petrescu Message-ID: <0bab257c-878e-3a29-70e5-65f3367553c7@gmail.com> Date: Fri, 3 Mar 2017 10:58:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:59:00 -0000 Le 03/03/2017 à 03:24, 神明é”哉 a écrit : > On Tue, Feb 28, 2017 at 4:04 AM, Alexandre Petrescu > wrote: > >> Finally, there is no advice of what bits to put between fe80:: and >> a 64bit the Interface ID - zeros or ones? linux says it's a >> fe80::/64 and IIRC BSD says it's a fe80::/10. The routing entries >> based on that can make for interop problems. > > I don't know exactly what you mean by "BSD says it's a fe80::/10", Tatuya, sorry, that may have been a mistake on my part. That was based on a vague recollection. > but BSD variants use a 64-bit IID to configure (e.g) an ethernet > interface with a link-local address, as specified in RFC4862 and > RFC2464. > > They also only recognize addresses that match fe80::/64 as on-link: When you say 'recognize' you mean by using the below macro? If so, it may be quite approximate and vague to recognize on 10bit something that is generated on 64bit. A precise recognition would be on 64bit. > Destination Gateway Flags Netif fe80::%em0/64 > link#1 U em0 > > On the other hand, BSDs' implementation of the > IN6_IS_ADDR_LINKLOCAL() macro only checks the first 10 bits: > > #define IN6_IS_ADDR_LINKLOCAL(a) \ (((a)->s6_addr[0] == 0xfe) > && (((a)->s6_addr[1] & 0xc0) == 0x80)) > > If you mean this by "fe80::/10", yes, BSDs hardcorde /10 for > link-local. Yes that 10 comes out of 8 plus the 2 of the 0xc0 mask. If so, it means BSD uses a 10bit mask to recognise a LL, but uses a 64bit mask to generate an LL. Maybe it is prudent enough. BUt it may not be correct. The right way would be to use precisely same generation and recognition masks. Otherwise there can be risks of incompatibility, address space waste, and probably others. I guess the programmer assumes the bits between 10 and 64 are simply 0 (others may say it's 1). But we should not say the generation is using a 10bit mask and recognition is using a 64bit mask, nor vice-versa. It reads incorrectly. > But it has nothing to do with the length of IIDs. Well, if the length of the IID is 64, and the fe80::/10 recognition is hardcoded at 10, then what does BSD put between position 10 and 64 when trying to recognise an LL address it has just generated? Alex > > -- JINMEI, Tatuya > From nobody Fri Mar 3 02:00:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70841297AC for ; Fri, 3 Mar 2017 02:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 jitRKEPXhl2I for ; Fri, 3 Mar 2017 02:00:08 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5D51293F4 for ; Fri, 3 Mar 2017 02:00:07 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v23A06vP023324 for ; Fri, 3 Mar 2017 11:00:06 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 739ED203FE8 for ; Fri, 3 Mar 2017 11:00:06 +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 6A07220122C for ; Fri, 3 Mar 2017 11:00:06 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23A06uo009723 for ; Fri, 3 Mar 2017 11:00:06 +0100 Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <2126862bab4f49f492c40639ff1b829a@XCH15-06-11.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <6ff8b5dd-f20d-ae2c-722f-21385018175a@gmail.com> Date: Fri, 3 Mar 2017 11:00:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:00:10 -0000 Le 03/03/2017 à 03:39, David Farmer a écrit : > > > On Thu, Mar 2, 2017 at 8:05 PM, Manfredi, Albert E > > wrote: > > From: David Farmer [mailto:farmer@umn.edu ] > > >> Brian E Carpenter > wrote: > > >> Agreed. And I think there are actually two things to say here: > >> > >> 3.1. Any IPv6-over-foo spec must specify a recommended IID length. > >> 3.2. In the absence of such a spec, the recommended IID length is > >> 64 bits. > > > How about, IIDs are REQUIRED to be 64 bits unless overridden by an > IPv6-over-foo spec? > > > >> Again, that breaks no running code, and it respects the architectural > >> statement that prefix_length + IID_length == 128, and the use of CIDR > >> routing and variable-length subnet masks. > >> > >> Brian > > > > I'd be fine with that, but others seem to feel otherwise. Lorenzo > > and James? > > That's why it's called "consensus." As opposed to unanimity. > > > However, if a provider only delegates a /64, this new text ensures > that > > prefix could be further subnetted down below /64 using manual > config or > > possibly DHCPv6. > > Exactly. So, how can we allow RFC 4291 bis to say that 64-bit IIDs > are REQUIRED? We can't. That was my original point. > > Bert > > > Because, it doesn't say IIDs are themselves required. In fact it > says "at a minimum, a node may consider that unicast addresses > (including its own) have no internal structure". IIDs are just that > internal structure of an address, which is by that text is OPTIONAL. > Therefore, it is only saying if you use an IID it must be 64 bits. > > And I'd now suggest it should say, if you use an IID it must be 64 bits > unless overridden my an IPv6-over-foo spec. YEs, as long as we are allowed to update RFC2464 with MAY other-than-64bit IID. Alex > > > -- > =============================================== > David Farmer Email:farmer@umn.edu > > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Mar 3 02:06:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8731296BC for ; Fri, 3 Mar 2017 02:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 oyP9lmQtMmTm for ; Fri, 3 Mar 2017 02:06:38 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B481294D0 for ; Fri, 3 Mar 2017 02:06:37 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v23A6aho027398 for ; Fri, 3 Mar 2017 11:06:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 70C98200C01 for ; Fri, 3 Mar 2017 11:06:36 +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 5ED1C200DC6 for ; Fri, 3 Mar 2017 11:06:36 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23A6a43017961 for ; Fri, 3 Mar 2017 11:06:36 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - concrete examples To: ipv6@ietf.org References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> <58B74D22.5010104@foobar.org> <58B89AD3.3000806@foobar.org> From: Alexandre Petrescu Message-ID: <527eb5a7-a167-a79a-9ca6-03df9e6967ea@gmail.com> Date: Fri, 3 Mar 2017 11:06:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:06:39 -0000 Le 03/03/2017 à 05:49, Lorenzo Colitti a écrit : [...] > If we don't have concrete examples, Lorenzo - I for myself provided such concrete examples publicly, multiple times in the past, replying specifically to your request of concrete examples. Do you remember? Alex From nobody Fri Mar 3 02:28:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB55B1294BF for ; Fri, 3 Mar 2017 02:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8Nrwuik2wFw0 for ; Fri, 3 Mar 2017 02:28:11 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860EF12943E for ; Fri, 3 Mar 2017 02:28:11 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1cjkRG-000BWP-4V (job@us.ntt.net); Fri, 03 Mar 2017 10:28:10 +0000 Date: Fri, 3 Mar 2017 17:27:34 +0700 From: Job Snijders To: Lorenzo Colitti Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Message-ID: <20170303102734.GW1024@Vurt.local> References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> <58B74D22.5010104@foobar.org> <58B89AD3.3000806@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:28:13 -0000 On Fri, Mar 03, 2017 at 01:49:48PM +0900, Lorenzo Colitti wrote: > On Fri, Mar 3, 2017 at 7:21 AM, Nick Hilliard wrote: > > > > Let me rephrase the question. I asked for use cases for longer-than-/64 > > > prefixes and listed the ones I have seen so far: > > > > > > * "I only need 3 addresses" (but not "I only need 3 addresses and > > > here's why I can't accept 2^64 instead of 3") > > > * ND exhaustion attacks > > > > > > Do you have additional use cases? "This is the way we've done it for 20 > > > years" is not a use case. > > > > Thank you for rephrasing the question in a neutral way. Here is my answer: > > > > https://www.ietf.org/mail-archive/web/ietf/current/msg101724.html > > > > We will probably need to agree to disagree on it. > > > > Actually, I agree with the comment itself. What I would like you to do is > implement your comment. I think what I above call "use cases" is what your > linked email calls "field deployment issues". If so, then my question > becomes: can you provide concrete examples of said field deployment issues? > What can't you do if all your subnets are fixed to /64? > > If we don't have concrete examples, all we have is "some operators say > fixed /64 is bad". But we don't know why they say it's bad, and how bad it > is, or even how many of those operators say it's bad. If nobody disagreed > with the staetments being made by the operators on this thread, that would > be fine. But because there *is* disagreement, then reaching consensus > requires finding a balance between what those operators say is best and > what others in this thread (mostly host developers) say is best. That > requires concrete examples, so that we can all look at the engineering > tradeoffs together. > > I'm going to ask again: what's the harm if all your IID lengths are /64 or > /127? What can't you do? (Other than use IPv6-translatable addresses, which > we should have an exception for.) You're free not to answer that question > at all, or to answer it with more general statements around operator > feedback being important to standards development, as you have so far, but > if you don't answer it with specific examples, I don't expect that you'll > be able to convince the other side of the debate any more than you have so > far. I am surprised you say stuff like "If we don't have concrete examples" - i shared actual data with the group. Is there a communication breakdown? /127 doesnt work with all equipment, /64 might leave one or both parties open to nd cache attacks, /126 works most of the time (hence 52% of NTTs interfaces are configured with /126), /124 or /120 is useful when you have more than two bgp speakers in a single layer-2 segment, etc. You've argued that you can mitigate nd cache issues, by applying non-trivial mechanisms, some of which are more theoretical then practical. Operators have chosen to entirely eliminate any risk of cache exhaustion issues by making linknets smaller. If I have a hammer, a nail, and a piece of wood; why would I use QoS or routing tricks? What I would've expected from IETF crowd is appreciation for continuing to deploy IPv6 in face of all the troubles we've seen over the years, instead we're being told "U R NUMBERING WRONG!!" and see absolute dismissal for current operational practices and recognition why the state of affairs is what it is. It is upsetting that this information needs to be repeated over and over again. Why are you not listening? The last decennia has already proven that flexibility is a necessity to operate the networks. The dogs bark, but the caravan goes on. Regards, Job From nobody Fri Mar 3 02:28:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1478712942F for ; Fri, 3 Mar 2017 02:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 NQ7e3a6xnogR for ; Fri, 3 Mar 2017 02:28:37 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4522C1294C8 for ; Fri, 3 Mar 2017 02:28:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v23ASYvJ026323; Fri, 3 Mar 2017 11:28:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2A0AE204456; Fri, 3 Mar 2017 11:28:34 +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 1C66A202781; Fri, 3 Mar 2017 11:28:34 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23ASXb0011554; Fri, 3 Mar 2017 11:28:34 +0100 Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: David Farmer References: <96a5dfe9-0122-0f8c-5ad3-f98dc1867f25@gmail.com> From: Alexandre Petrescu Message-ID: <99749605-50a7-0920-9ace-2c0278efc750@gmail.com> Date: Fri, 3 Mar 2017 11:28:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:28:39 -0000 Le 03/03/2017 à 10:36, David Farmer a écrit : > > > On Fri, Mar 3, 2017 at 3:17 AM, Alexandre Petrescu > > wrote: > > > Le 02/03/2017 à 23:43, David Farmer a écrit : > > > 2. Subnet Prefixes of 64 bits are RECOMMENDED > > > I disagree, we dont want to say this. > > > Why, please It depends in which doc to put it. It makes sense in RFC2464, or other IPv6-over-foo, but not in overall archi doc. If we are to count, we notice many deployed subnet prefixes are not 64 (i.e. they wouldnt be non-conformant to this recommendation). > > > 3. IIDs are REQUIRED to be 64 bits > > > I disagree. > > > Again why, and would be ok to RECOMMEND at least Depends where: makes sense in IP-over-foo, but not in overall archi covering in one paragraph about all foos. > It seems wrong to completely remove any reference to 64 in the IPv6 > Addressing Architecture, come on. I agree it is common to talk 64 when introducing IPv6 to someone, when looking at a screen dump of rt tables of numerous end nodes, and others. Removing 64 from Archi can look daring, ofensive, hurting, not respecting reality. So one wonders why64? One source is this EUI-64 originated at IEEE. Then 'Modified' EUI-64 at IETF. Yet EUI-64 is no longer. It was designed to replace 48bit MACs. It did not succeed: we dont see 'EUI-64' on Ethernet-based devices, we continue to see 48bit MAC addresses even on non-Ethernet devices. But we hear about EUI-128, which would obviously couldnt work with IPv6. So yes I think it makes sense to remove all 64 from IPv6 Addressing Architecture. Alex > > -- > =============================================== > David Farmer Email:farmer@umn.edu > > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== From nobody Fri Mar 3 02:30:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8309712947A for ; Fri, 3 Mar 2017 02:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 QZg3ww_30qG4 for ; Fri, 3 Mar 2017 02:30:39 -0800 (PST) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DFD12943E for ; Fri, 3 Mar 2017 02:30:39 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 94085C0263; Fri, 3 Mar 2017 11:30:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 5C7FD1A0063; Fri, 3 Mar 2017 11:30:37 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Fri, 3 Mar 2017 11:30:37 +0100 From: To: Alexandre Petrescu , Mark Andrews Subject: RE: Objection to draft-ietf-6man-rfc4291bis-07.txt Thread-Topic: Objection to draft-ietf-6man-rfc4291bis-07.txt Thread-Index: AQHSlACeVr+y/Sr+qUWS2y7pqG6meKGC6Lrw Date: Fri, 3 Mar 2017 10:30:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E1BE96@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20170223134026.GI5069@gir.theapt.org> <20170302105206.15fc3886@echo.ms.redpill-linpro.com> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> <20170302224856.E63AB65D34EC@rock.dv.isc.org> <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com> In-Reply-To: <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:30:41 -0000 Hi Alex, > This is why I dont understand the cellular operators dont do DHCPv6-PD. > And I guess it is so because they are told it's sufficient to run the > 64share INFORMATIONAL RFC. This is a chicken-and-egg problem: you need both the cellular device and th= e network side to support prefix delegation + prefix exclude option, but wh= ile waiting for that to happen /64 share is your solution. Below what you c= an read in RFC7849: =3D=3D=3D=3D=3D L_REC#1: For deployments that require that the same /64 prefix be shared, the cellular device should support [RFC7278] to enable sharing a /64 prefix between the LAN and the WAN interfaces. The WAN interface is the one towards the Gateway GPRS Support Node (GGSN) / Packet Data Network Gateway (PGW). Prefix Delegation (refer to L_REC#2) is the target solution for distributing prefixes in the LAN side but, because the device may attach to earlier 3GPP release networks, a means to share a /64 prefix is also recommended [RFC7278]. [RFC7278] must be invoked only if Prefix Delegation is not in use. L_REC#2: The cellular device must support Prefix Delegation capabilities [RFC3633] and must support the Prefix Exclude Option for DHCPv6-based Prefix Delegation as defined in [RFC6603]. Particularly, it must behave as a Requesting Router. Cellular networks are more and more perceived as an alternative to fixed broadband networks for home IP- based services delivery; especially with the advent of smartphones and 3GPP data dongles. There is a need for an efficient mechanism to assign larger prefixes (other than /64s) to cellular hosts so that each LAN segment can get its own /64 prefix and multi-link subnet issues to be avoided. In case a prefix is delegated to a cellular host using DHCPv6, the cellular device will be configured with two prefixes: (1) one for the 3GPP link allocated using the Stateless Address Autoconfiguration (SLAAC) mechanism and (2) another one delegated for LANs acquired during the Prefix Delegation operation. Note that the 3GPP network architecture requires both the WAN and the delegated prefix to be aggregatable so the subscriber can be identified using a single prefix. Without the Prefix Exclude Option, the delegating router (GGSN/PGW) will have to ensure compliance with [RFC3633] (e.g., halving the delegated prefix and assigning the WAN prefix out of the first half and the prefix to be delegated to the terminal from the second half). Because Prefix Delegation capabilities may not be available in some attached networks, L_REC#1 is strongly recommended to accommodate early deployments. =3D=3D=3D=3D=3D Cheers, Med > -----Message d'origine----- > De=A0: ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Alexandre Petres= cu > Envoy=E9=A0: vendredi 3 mars 2017 10:29 > =C0=A0: Mark Andrews > Cc=A0: ipv6@ietf.org > Objet=A0: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt >=20 >=20 >=20 > Le 02/03/2017 =E0 23:48, Mark Andrews a =E9crit : > > > > In message <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com>, > > Alexandre Petrescu writes: > >> Le 02/03/2017 20:25, JORDI PALET MARTINEZ a crit : > >>> I understood from one of your previous emails that 3GPP doesnt > >>> require DHCPv6-PD. > >> > >> Right - if I understand correctly, it does not require DHCPv6-PD on > >> the UE. Maybe in the core, but not in the UE. > >> > >>> RFC6653, suggest its use, so probably we got confused ourselves > >>> and 3GPP is actually using it. > >>> > >>> 6rd is a different thing, because is actually IPv4 link and IPv6 > >>> is a tunnel, so you typically use DHCP (v4). > >> > >> I agree. > >> > >>> In IPv6-only world (including cellular), the WAN link will be > >>> IPv6-only instead of dual-stack. This is already happening. > >>> > >>> If they dont use it, I guess is the same reason why big vendors > >>> didnt implemented yet RDDNS > >> > >> I wonder if Windows refusing RDNSS doesn't have somehting to do > >> with its Teredo; and extending this logic to smartphones: the lack > >> of answers to DHCPv6-PD issued from the UE may have something to > >> do with 464xlat presence. > >> > >> Could it be that 464xlat presence on UE makes it that DHCPv6-PD is > >> impossible on same UE? > > > > No. They are or should be orthogonal. One is about providing IPv4 > > as as service. The other is about providing IPv6 address space. >=20 > I can agree. >=20 > With my operator I asked her once 'why not giving DHCPc6-PD to > smartphone' and she replied 'because now we do 464xlat on the > smartphone, and that is sufficient'. As such it sounds illogical > statement, although I guess s/he has some reasons to say so. >=20 > But let me ask differently: maybe it's because 464xlat requires some > kernel version that DHCPv6-PD doestn support, or vice-versa? Maybe it's > because once you run 464xlat on smartphone it takes control of the > unique default route and DHCPv6-PD couldnt? Some reason like that? >=20 > Has one tried DHCPv6-PD software simultaneosuly with 464xlat? (even > knowing the cellular operator would not reply to DHCPv6 Slicitations). >=20 > >>> Cellular world is using 464XLAT, and they use DHCPv6-PD. Check > >>> RFC6877. > >> > >> I guess you mean cellular stations (like BS, not the User > >> Equipment) uses DHCPv6-PD within the fixed network. > > > > No, the UE should be using DHCPv6-PD. This is how tethered > > equipement should be getting IPv6 address space. >=20 > I agree with yuo. >=20 > This is why I dont understand the cellular operators dont do DHCPv6-PD. > And I guess it is so because they are told it's sufficient to run the > 64share INFORMATIONAL RFC. >=20 > Are the people advising 64share to tethering-willing telecom operators > conscious it's non-interoperable? >=20 > Is the 64share advice coming together with the claim there are enough > /64s out there? >=20 > Alex >=20 > >> Because cellular operator I am aware of replies to DHCPv6-PD > >> requests issued from an User Equipment. > >> > >> Alex > >> > >>> > >>> Saludos, Jordi > >>> > >>> > >>> -----Mensaje original----- De: ipv6 en > >>> nombre de Alexandre Petrescu > >>> Responder a: Fecha: jueves, 2 de > >>> marzo de 2017, 20:15 Para: Asunto: Re: Objection > >>> to draft-ietf-6man-rfc4291bis-07.txt > >>> > >>> > >>> > >>> Le 02/03/2017 20:06, JORDI PALET MARTINEZ a crit : > >>>> I guess because the lack of DHCPv6-PD support, as you already > >>>> indicated? > >>> > >>> But for deity's sake - DHCPv6-PD is available as open source... > >>> it's common software. Just download and install. The IETF Specs > >>> suggest it, and the 3GPP specs require it too. > >>> > >>> There must be something else making these router equipment > >>> manufacturers refraining from downloading and installing > >>> DHCPv6-PD. > >>> > >>>> I think majority of the households and business customers get > >>>> configured the CPE by means for DHCPv6-PD > >>> > >>> AFAIK my CPE at home does not use DHCPv6-PD, but something based > >>> on IPv4, like 6rd. I think it's something developped in-house > >>> at that particular operator. > >>> > >>> Alex > >>> > >>>> > >>>> Saludos, Jordi > >>>> > >>>> > >>>> -----Mensaje original----- De: ipv6 en > >>>> nombre de Alexandre Petrescu > >>>> Responder a: Fecha: jueves, 2 > >>>> de marzo de 2017, 20:02 Para: Asunto: Re: > >>>> Objection to draft-ietf-6man-rfc4291bis-07.txt > >>>> > >>>> > >>>> > >>>> Le 02/03/2017 19:54, JORDI PALET MARTINEZ a crit : > >>>>> Actually, is not correct that most use /56 for residential. > >>>>> > >>>>>> From my last review of the survey, worldwide, 22% use /48, > >>>>>> 35% use /56, but there is a lot of ISPs (33%) doing it > >>>>>> wrong and using /64, which of course, we are explaining > >>>>>> them that is wrong. 10% use other sizes. > >>>> > >>>> So how comes that households can get /56s but smartphones no? > >>>> > >>>> Really there must be something there hidden. > >>>> > >>>> Alex > >>>> > >>>>> > >>>>> Full details at: > >>>>> > >>>>> > >> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6- > deployment-s > >> > >> > >> > >> > urvey > >>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>>>> > >>>>> > >>>> > >>>>> Saludos, Jordi > >>>>> > >>>>> > >>>>> -----Mensaje original----- De: ipv6 > >>>>> en nombre de Mikael Abrahamsson > >>>>> Organizacin: People's Front Against WWW Responder a: > >>>>> Fecha: jueves, 2 de marzo de 2017, 19:33 > >>>>> Para: Alexandre Petrescu CC: > >>>>> Asunto: Re: Objection to > >>>>> draft-ietf-6man-rfc4291bis-07.txt > >>>>> > >>>>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > >>>>> > >>>>>> YEs yes, but how much of that /44 is covering the > >>>>>> end-users and how much is reserved for interconnnections? > >>>>> > >>>>> Nothing. It's /44 to the GGSN/SPGW. > >>>>> > >>>>>> Ah great, but I guess few cellular operators (if any?) are > >>>>>> LIRs. Or maybe that's true and I didnt know. > >>>>> > >>>>> You don't know. > >>>>> > >>>>>> If all this were that simple and clearcut - there are > >>>>>> enough /64s out there - then why operators only assign one > >>>>>> per one end user? > >>>>> > >>>>> Because DHCPv6-PD hasn't been implemented in mobile networks > >>>>> yet (that I know of). So that's all they can do per 3GPP > >>>>> standards. > >>>>> > >>>>> Residential rollouts, most use /56 per customer. > >>>>> > >>>>>> From the RIRs, you can without further justification get > >>>>>> /48 per "site", > >>>>> so if you show up to RIR and you're LIR and you say "hello, > >>>>> I have 40 million customers and I want to give each customer > >>>>> a /48" then they'll give you a /22 most likely. You're > >>>>> perfectly within your right as an operator to deploy /48 per > >>>>> customer per current RIR rules that I am aware of. > >>>>> > >>>>> -- Mikael Abrahamsson email: swmike@swm.pp.se > >>>>> > >>>>> -------------------------------------------------------------------= - > >>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>>>> > >>>>> > >>>> > >>>>> > >>>>> > >>>>> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>>> -------------------------------------------------------------------= - > >>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>>>> > >>>>> > >>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > ********************************************** IPv4 is over Are > >>>>> you ready for the new Internet ? http://www.consulintel.es > >>>>> The IPv6 Company > >>>>> > >>>>> This electronic message contains information which may be > >>>>> privileged or confidential. The information is intended to > >>>>> be for the use of the individual(s) named above. If you are > >>>>> not the intended recipient be aware that any disclosure, > >>>>> copying, distribution or use of the contents of this > >>>>> information, including attached files, is prohibited. > >>>>> > >>>>> > >>>>> > >>>>> -------------------------------------------------------------------= - > >>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>>>> > >>>>> > >>>> > >>>>> > >>>>> > >>>>> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>>> -------------------------------------------------------------------= - > >>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------- > >>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> IETF IPv6 working group mailing list ipv6@ietf.org > >>> Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > >>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > ********************************************** IPv4 is over Are > >>>> you ready for the new Internet ? http://www.consulintel.es The > >>>> IPv6 Company > >>>> > >>>> This electronic message contains information which may be > >>>> privileged or confidential. The information is intended to be > >>>> for the use of the individual(s) named above. If you are not > >>>> the intended recipient be aware that any disclosure, copying, > >>>> distribution or use of the contents of this information, > >>>> including attached files, is prohibited. > >>>> > >>>> > >>>> > >>>> -------------------------------------------------------------------- > >>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>>> > >>>> > >>>> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > >>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>>> > >>>> > >>>> > -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list ipv6@ietf.org > >>> Administrative Requests: > >>> https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > ********************************************** IPv4 is over Are you > >>> ready for the new Internet ? http://www.consulintel.es The IPv6 > >>> Company > >>> > >>> This electronic message contains information which may be > >>> privileged or confidential. The information is intended to be for > >>> the use of the individual(s) named above. If you are not the > >>> intended recipient be aware that any disclosure, copying, > >>> distribution or use of the contents of this information, > >>> including attached files, is prohibited. > >>> > >>> > >>> > >>> -------------------------------------------------------------------- > >>> > >>> > >>> > >>> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> > >> > >> > >>> > >>> > >>> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Mar 3 02:52:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691391296C5 for ; Fri, 3 Mar 2017 02:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.332 X-Spam-Level: X-Spam-Status: No, score=-4.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6V5HJrtudgjo for ; Fri, 3 Mar 2017 02:52:01 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624E5126CD8 for ; Fri, 3 Mar 2017 02:52:00 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v23ApwYs013130; Fri, 3 Mar 2017 11:51:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 52B8F204456; Fri, 3 Mar 2017 11:51:58 +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 4235F204388; Fri, 3 Mar 2017 11:51:58 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23ApvX8031206; Fri, 3 Mar 2017 11:51:58 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: mohamed.boucadair@orange.com, Mark Andrews References: <20170223134026.GI5069@gir.theapt.org> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> <20170302224856.E63AB65D34EC@rock.dv.isc.org> <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com> <787AE7BB302AE849A7480A190F8B933009E1BE96@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Alexandre Petrescu Message-ID: <31396f41-0f08-3677-8012-4fd54247aa76@gmail.com> Date: Fri, 3 Mar 2017 11:52:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E1BE96@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:52:03 -0000 Le 03/03/2017 à 11:30, mohamed.boucadair@orange.com a écrit : > Hi Alex, > > >> This is why I dont understand the cellular operators dont do >> DHCPv6-PD. And I guess it is so because they are told it's >> sufficient to run the 64share INFORMATIONAL RFC. > > This is a chicken-and-egg problem: you need both the cellular device > and the network side to support prefix delegation + prefix exclude > option, How can that vicious circle be broken? I have some smartphone and other M2M modules here on which we could try a few things. What would operator expect to hear from this smartphone? Is the ISC DHCPv6-PD Client messages enough? Does operator also need 'prefix exclude'? Mandatory? Is the ISC DHCPv6-PD implementing 'prefix exclude'? > but while waiting for that to happen /64 share is your solution. Operator should understand that /64 share is impossible to use in concrete settings like vehicular networks, road-side units, and similar. > Below what you can read in RFC7849: If I read it I will certainly suggest improvements to it. It should reflect reality. > ===== L_REC#1: For deployments that require that the same /64 prefix > be shared, the cellular device should support [RFC7278] to enable > sharing a /64 prefix between the LAN and the WAN interfaces. The WAN > interface is the one towards the Gateway GPRS Support Node (GGSN) / > Packet Data Network Gateway (PGW). > > Prefix Delegation (refer to L_REC#2) is the target solution for It's not a 'target', it is a 'now'. > distributing prefixes in the LAN side but, because the device may > attach to earlier 3GPP release networks, a means to share a /64 > prefix is also recommended [RFC7278]. No! That recommendation is wrong. That RFC is INFORMATIONAL and we should stop recommending it. I has huge problems, at least with respect to scalability. > [RFC7278] must be invoked only if Prefix Delegation is not in use. ... _and_ if it works for the network being deployed. If it does not work, it MUST NOT be invoked. > L_REC#2: The cellular device must support Prefix Delegation > capabilities [RFC3633] and must support the Prefix Exclude Option for > DHCPv6-based Prefix Delegation as defined in [RFC6603]. Why is the 'prefix exclude' option a MUST? I may need to understand that, by further reading... > Particularly, it must behave as a Requesting Router. Yes, and it is a MUST not a must. > > Cellular networks are more and more perceived as an alternative to > fixed broadband networks for home IP- based services delivery; I agree. > especially with the advent of smartphones and 3GPP data dongles. _and_ M2M and IoT devices which are not 'dongles' (btw, 'dongles' are only the USB dongles, there are no other kinds of dongles). > There is a need for an efficient mechanism to assign larger prefixes > (other than /64s) to cellular hosts I fully agree. > so that each LAN segment can get its own /64 prefix _if_ that LAN is an Ethernet, yes it needs a /64. Often it is the case. > and multi-link subnet issues to be avoided. I agree, RFC must be cited. > In case a prefix is delegated to a cellular host using DHCPv6, the > cellular device will be configured with two prefixes: > > (1) one for the 3GPP link allocated using the Stateless Address > Autoconfiguration (SLAAC) mechanism and > > (2) another one delegated for LANs acquired during the Prefix > Delegation operation. I dont know what you mean by 'configured', but this second prefix may just be in the rt table of the device (not necessarily on its interfaces). How about the default route? > Note that the 3GPP network architecture requires both the WAN and the > delegated prefix to be aggregatable so the subscriber can be > identified using a single prefix. IT's good to avoid waste. > Without the Prefix Exclude Option, the delegating router (GGSN/PGW) > will have to ensure compliance with [RFC3633] (e.g., halving the > delegated prefix and assigning the WAN prefix out of the first half > and the prefix to be delegated to the terminal from the second > half). So 'prefix exclude' is not mandatory in order to have DHCPv6-PD working. > > Because Prefix Delegation capabilities may not be available in some > attached networks, L_REC#1 is strongly recommended to accommodate > early deployments. ===== It's wrong. We should _never_ recommend somehting we know it does not scale. Because if we do it may get in widespread use and later we'll have a hard time getting rid of. Alex > > Cheers, Med > > >> -----Message d'origine----- De : ipv6 >> [mailto:ipv6-bounces@ietf.org] De la part de Alexandre Petrescu >> Envoyé : vendredi 3 mars 2017 10:29 À : Mark Andrews Cc : >> ipv6@ietf.org Objet : Re: Objection to >> draft-ietf-6man-rfc4291bis-07.txt >> >> >> >> Le 02/03/2017 à 23:48, Mark Andrews a écrit : >>> >>> In message <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com>, >>> Alexandre Petrescu writes: >>>> Le 02/03/2017 20:25, JORDI PALET MARTINEZ a crit : >>>>> I understood from one of your previous emails that 3GPP >>>>> doesnt require DHCPv6-PD. >>>> >>>> Right - if I understand correctly, it does not require >>>> DHCPv6-PD on the UE. Maybe in the core, but not in the UE. >>>> >>>>> RFC6653, suggest its use, so probably we got confused >>>>> ourselves and 3GPP is actually using it. >>>>> >>>>> 6rd is a different thing, because is actually IPv4 link and >>>>> IPv6 is a tunnel, so you typically use DHCP (v4). >>>> >>>> I agree. >>>> >>>>> In IPv6-only world (including cellular), the WAN link will >>>>> be IPv6-only instead of dual-stack. This is already >>>>> happening. >>>>> >>>>> If they dont use it, I guess is the same reason why big >>>>> vendors didnt implemented yet RDDNS >>>> >>>> I wonder if Windows refusing RDNSS doesn't have somehting to >>>> do with its Teredo; and extending this logic to smartphones: >>>> the lack of answers to DHCPv6-PD issued from the UE may have >>>> something to do with 464xlat presence. >>>> >>>> Could it be that 464xlat presence on UE makes it that DHCPv6-PD >>>> is impossible on same UE? >>> >>> No. They are or should be orthogonal. One is about providing >>> IPv4 as as service. The other is about providing IPv6 address >>> space. >> >> I can agree. >> >> With my operator I asked her once 'why not giving DHCPc6-PD to >> smartphone' and she replied 'because now we do 464xlat on the >> smartphone, and that is sufficient'. As such it sounds illogical >> statement, although I guess s/he has some reasons to say so. >> >> But let me ask differently: maybe it's because 464xlat requires >> some kernel version that DHCPv6-PD doestn support, or vice-versa? >> Maybe it's because once you run 464xlat on smartphone it takes >> control of the unique default route and DHCPv6-PD couldnt? Some >> reason like that? >> >> Has one tried DHCPv6-PD software simultaneosuly with 464xlat? >> (even knowing the cellular operator would not reply to DHCPv6 >> Slicitations). >> >>>>> Cellular world is using 464XLAT, and they use DHCPv6-PD. >>>>> Check RFC6877. >>>> >>>> I guess you mean cellular stations (like BS, not the User >>>> Equipment) uses DHCPv6-PD within the fixed network. >>> >>> No, the UE should be using DHCPv6-PD. This is how tethered >>> equipement should be getting IPv6 address space. >> >> I agree with yuo. >> >> This is why I dont understand the cellular operators dont do >> DHCPv6-PD. And I guess it is so because they are told it's >> sufficient to run the 64share INFORMATIONAL RFC. >> >> Are the people advising 64share to tethering-willing telecom >> operators conscious it's non-interoperable? >> >> Is the 64share advice coming together with the claim there are >> enough /64s out there? >> >> Alex >> >>>> Because cellular operator I am aware of replies to DHCPv6-PD >>>> requests issued from an User Equipment. >>>> >>>> Alex >>>> >>>>> >>>>> Saludos, Jordi >>>>> >>>>> >>>>> -----Mensaje original----- De: ipv6 >>>>> en nombre de Alexandre Petrescu >>>>> Responder a: >>>>> Fecha: jueves, 2 de marzo de >>>>> 2017, 20:15 Para: Asunto: Re: Objection to >>>>> draft-ietf-6man-rfc4291bis-07.txt >>>>> >>>>> >>>>> >>>>> Le 02/03/2017 20:06, JORDI PALET MARTINEZ a crit : >>>>>> I guess because the lack of DHCPv6-PD support, as you >>>>>> already indicated? >>>>> >>>>> But for deity's sake - DHCPv6-PD is available as open >>>>> source... it's common software. Just download and install. >>>>> The IETF Specs suggest it, and the 3GPP specs require it >>>>> too. >>>>> >>>>> There must be something else making these router equipment >>>>> manufacturers refraining from downloading and installing >>>>> DHCPv6-PD. >>>>> >>>>>> I think majority of the households and business customers >>>>>> get configured the CPE by means for DHCPv6-PD >>>>> >>>>> AFAIK my CPE at home does not use DHCPv6-PD, but something >>>>> based on IPv4, like 6rd. I think it's something developped >>>>> in-house at that particular operator. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Saludos, Jordi >>>>>> >>>>>> >>>>>> -----Mensaje original----- De: ipv6 >>>>>> en nombre de Alexandre Petrescu >>>>>> Responder a: >>>>>> Fecha: jueves, 2 de marzo de >>>>>> 2017, 20:02 Para: Asunto: Re: Objection to >>>>>> draft-ietf-6man-rfc4291bis-07.txt >>>>>> >>>>>> >>>>>> >>>>>> Le 02/03/2017 19:54, JORDI PALET MARTINEZ a crit : >>>>>>> Actually, is not correct that most use /56 for >>>>>>> residential. >>>>>>> >>>>>>>> From my last review of the survey, worldwide, 22% use >>>>>>>> /48, 35% use /56, but there is a lot of ISPs (33%) >>>>>>>> doing it wrong and using /64, which of course, we are >>>>>>>> explaining them that is wrong. 10% use other sizes. >>>>>> >>>>>> So how comes that households can get /56s but smartphones >>>>>> no? >>>>>> >>>>>> Really there must be something there hidden. >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Full details at: >>>>>>> >>>>>>> >>>> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6- >> deployment-s >>>> >>>> >>>> >>>> >> urvey >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> Saludos, Jordi >>>>>>> >>>>>>> >>>>>>> -----Mensaje original----- De: ipv6 >>>>>>> en nombre de Mikael Abrahamsson >>>>>>> Organizacin: People's Front Against >>>>>>> WWW Responder a: Fecha: jueves, 2 de >>>>>>> marzo de 2017, 19:33 Para: Alexandre Petrescu >>>>>>> CC: >>>>>>> Asunto: Re: Objection to >>>>>>> draft-ietf-6man-rfc4291bis-07.txt >>>>>>> >>>>>>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: >>>>>>> >>>>>>>> YEs yes, but how much of that /44 is covering the >>>>>>>> end-users and how much is reserved for >>>>>>>> interconnnections? >>>>>>> >>>>>>> Nothing. It's /44 to the GGSN/SPGW. >>>>>>> >>>>>>>> Ah great, but I guess few cellular operators (if any?) >>>>>>>> are LIRs. Or maybe that's true and I didnt know. >>>>>>> >>>>>>> You don't know. >>>>>>> >>>>>>>> If all this were that simple and clearcut - there are >>>>>>>> enough /64s out there - then why operators only assign >>>>>>>> one per one end user? >>>>>>> >>>>>>> Because DHCPv6-PD hasn't been implemented in mobile >>>>>>> networks yet (that I know of). So that's all they can do >>>>>>> per 3GPP standards. >>>>>>> >>>>>>> Residential rollouts, most use /56 per customer. >>>>>>> >>>>>>>> From the RIRs, you can without further justification >>>>>>>> get /48 per "site", >>>>>>> so if you show up to RIR and you're LIR and you say >>>>>>> "hello, I have 40 million customers and I want to give >>>>>>> each customer a /48" then they'll give you a /22 most >>>>>>> likely. You're perfectly within your right as an operator >>>>>>> to deploy /48 per customer per current RIR rules that I >>>>>>> am aware of. >>>>>>> >>>>>>> -- Mikael Abrahamsson email: swmike@swm.pp.se >>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >>>>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -------------------------------------------------------------------- >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >>>>>>> ********************************************** IPv4 is over Are >>>>>>> you ready for the new Internet ? >>>>>>> http://www.consulintel.es The IPv6 Company >>>>>>> >>>>>>> This electronic message contains information which may >>>>>>> be privileged or confidential. The information is >>>>>>> intended to be for the use of the individual(s) named >>>>>>> above. If you are not the intended recipient be aware >>>>>>> that any disclosure, copying, distribution or use of the >>>>>>> contents of this information, including attached files, >>>>>>> is prohibited. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >>>>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -------------------------------------------------------------------- >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >> >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> IETF IPv6 working group mailing list ipv6@ietf.org >>>>> Administrative >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> >>>>>> >>>>>> >>>>>> ********************************************** IPv4 is over Are >>>>>> you ready for the new Internet ? http://www.consulintel.es >>>>>> The IPv6 Company >>>>>> >>>>>> This electronic message contains information which may be >>>>>> privileged or confidential. The information is intended to >>>>>> be for the use of the individual(s) named above. If you >>>>>> are not the intended recipient be aware that any >>>>>> disclosure, copying, distribution or use of the contents >>>>>> of this information, including attached files, is >>>>>> prohibited. >>>>>> >>>>>> >>>>>> >>>>>> -------------------------------------------------------------------- >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >> >>>>>> >>>>>> >>>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >> >>>>>> >>>>>> >>>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list ipv6@ietf.org >>>>> Administrative Requests: >>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> ********************************************** IPv4 is over Are you >>>>> ready for the new Internet ? http://www.consulintel.es The >>>>> IPv6 Company >>>>> >>>>> This electronic message contains information which may be >>>>> privileged or confidential. The information is intended to be >>>>> for the use of the individual(s) named above. If you are not >>>>> the intended recipient be aware that any disclosure, copying, >>>>> distribution or use of the contents of this information, >>>>> including attached files, is prohibited. >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>> >>>> >>>> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org >>>> Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >> >> >>>> >>>> >>>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Fri Mar 3 03:18:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAEF1294B0 for ; Fri, 3 Mar 2017 03:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 GuVo0AUZQFyI for ; Fri, 3 Mar 2017 03:18:51 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 725C21294AD for ; Fri, 3 Mar 2017 03:18:51 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 03 Mar 2017 11:18:51 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id E3372D788D; Fri, 3 Mar 2017 03:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=hLWUKFijLzGvStlwrLOs7fFZgKM=; b= FSGao3NRgX3M2J34o3m77mn3L2YUZZNI8LcQaatoRevnlMUq9069uM76FtTwm1tg GCksDnckA/4MxdflW+kGE9JbWsjW61hbziRR0uSLVYoGiiF/ZbfTbrnYrBISJtWT ETfkTELv1mNfFkEdhjaDIFtQqllxHMfKFRZbPn8SIw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=FPSUNjnXudue7a0aJBYmVyJ FPqmRqpG0T45Ayn6ReOYs5fD5i5xEMT8L6lY0F1ZcFWR3V+cDl0jhyxUUZ0jEdAL seJXmdWTZj5iAdUyClPYEPgmYN5K4eAybMEdCWUC7+HgJdNRcfiM8l49mvDcxVK4 evCE2doetMNSrNwu6dkE= Received: from h.hanazo.no (unknown [173.38.220.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id AEA61D788A; Fri, 3 Mar 2017 03:18:50 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BD2AD9380A51; Fri, 3 Mar 2017 12:18:48 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B838B612-6ED6-427D-B15D-E8E7FA67A711"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Date: Fri, 3 Mar 2017 12:18:47 +0100 In-Reply-To: <20170303102734.GW1024@Vurt.local> To: Job Snijders References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> <58B74D22.5010104@foobar.org> <58B89AD3.3000806@foobar.org> <20170303102734.GW1024@Vurt.local> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 11:18:53 -0000 --Apple-Mail=_B838B612-6ED6-427D-B15D-E8E7FA67A711 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Job, [...] > It is upsetting that this information needs to be repeated over and = over > again. Why are you not listening? The last decennia has already proven > that flexibility is a necessity to operate the networks. of course. at the same time please remember that there is significant = distrust towards the operators. if we as the users gave in now, will you turn around and charge me by = the address tomorrow? as have been mentioned before the hard part is to find text that is = clear on the policy, allows for new innovations and use of ILNP, /64 to = the host, NPT66, but also recognises that I can configure /128s, or that = I on my laptop split a /64 into /80s for each of my VMs... Cheers, Ole --Apple-Mail=_B838B612-6ED6-427D-B15D-E8E7FA67A711 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYuVEYAAoJEL7aWKiYQt92XO4P/0O6fgzdymjDZS47dmCHUwhQ yeHCCpdhr9+HS2hYmu6vgg2xOgC/9lB/R0hBSLxzsf/RTz1rJFydozzFWxCBTe3h eYi6suZt+LYQyU7CF2dcJN/dcPTVD9XAWTzJ1jVMh6+xIOryJUt6bPTTFi5hBD16 r/7IRbaCO64uMHrniF1BGTnYddK4QOt++Bznq5xXfMJ/nZRb7jNc+zDG316qK7jr ypYWmzKJLhotpkfU5iHC1FcFdI58S4kNWeQ03Kbs0EeVzk3F2Be+RcXoKv+kO3FQ 5X/E8nG3iPKe8ersoHxsE8B04+iVMKsuTjWXhnSWYlwRzd3EnMSI4IID/qmlG+Uk SsRvUdbUlrJ5F/nd8YkEtON3RAMzVo+kpMZlmdQOn5EwpuSvP3sBacaQB9+tgZE4 LBGbGJQi7JYsZTV08GN9cCP2fVEg26LOaBCZLAv0thGiw5rW4ZUYyZ880bhC7BL+ oHql0yrmYASK23F6OiZqOqBo61eZNTwE6GSAUmacQeg9t8vmeI1Jm6QHCQm/nsNB eTOxincmwQS0Gojxl+MTttAng1wNGxBmmZeU3gDWRTHqcSIQ8lJhG8RydMpXe37z 5BUzIj1km1eUpOgPcpsCDsRV5IawOu+Q8gvRSDpFMBSJ/ER7pi3ZzeK1lv4wELQ6 k1T3FyZHNBEuE4TaMlkK =eW+T -----END PGP SIGNATURE----- --Apple-Mail=_B838B612-6ED6-427D-B15D-E8E7FA67A711-- From nobody Fri Mar 3 05:14:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB75129518 for ; Fri, 3 Mar 2017 05:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hqO_0dToLF8Z for ; Fri, 3 Mar 2017 05:14:37 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D57129513 for ; Fri, 3 Mar 2017 05:14:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v23DEYKc005591 for ; Fri, 3 Mar 2017 14:14:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7978B209C31 for ; Fri, 3 Mar 2017 14:14:34 +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 6FC27209C1E for ; Fri, 3 Mar 2017 14:14:34 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23DEYIT016350 for ; Fri, 3 Mar 2017 14:14:34 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: ipv6@ietf.org References: <3fba77e0-d7ff-802e-019b-6fe152eaee67@gmail.com> <20170301.110443.71171106.sthaug@nethelp.no> <58B6A02E.50501@foobar.org> <58B74D22.5010104@foobar.org> <58B89AD3.3000806@foobar.org> <20170303102734.GW1024@Vurt.local> From: Alexandre Petrescu Message-ID: Date: Fri, 3 Mar 2017 14:14:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 13:14:38 -0000 Le 03/03/2017 à 12:18, otroan@employees.org a écrit : > Job, > > [...] > >> It is upsetting that this information needs to be repeated over and >> over again. Why are you not listening? The last decennia has >> already proven that flexibility is a necessity to operate the >> networks. > > of course. at the same time please remember that there is significant > distrust towards the operators. I agree. One view at a certain operator is that the deployed 3GPP Release number does not support DHCPv6-PD for end users. As such that view can only be interpreted as an invitation to wait for the next release of 3GPP Release before hoping to see DHCPv6-PD on the smartphone. With no guarantee whatsoever. Until then what can one do to support multiple scalable IPv6 subnets at the edges of 3GPP networks? Use NAT66? Make a 65 SLAAC? Mandate /65 DHCPv6 addresses on end devices tainted by fe80::/64? None sounds RECOMMENDED. Alex > if we as the users gave in now, will you turn around and charge me by > the address tomorrow? > > as have been mentioned before the hard part is to find text that is > clear on the policy, allows for new innovations and use of ILNP, /64 > to the host, NPT66, but also recognises that I can configure /128s, > or that I on my laptop split a /64 into /80s for each of my VMs... > > Cheers, Ole > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Mar 3 05:54:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1896012945A for ; Fri, 3 Mar 2017 05:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 DWrgUXSILxQN for ; Fri, 3 Mar 2017 05:54:47 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120D712943A for ; Fri, 3 Mar 2017 05:54:47 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 943C6CBF for ; Fri, 3 Mar 2017 13:54:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oZIDW6GIrEu for ; Fri, 3 Mar 2017 07:54:46 -0600 (CST) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 563CCCC5 for ; Fri, 3 Mar 2017 07:54:46 -0600 (CST) Received: by mail-ua0-f200.google.com with SMTP id v33so66734002uaf.2 for ; Fri, 03 Mar 2017 05:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:from:date:message-id:subject:to; bh=n+FUPCFNemFxPC5V6Nzct7nJUUykcQhRaqxXoth+yEw=; b=gDlkO3pmDenn04TmZ5jPD7V+G5hjvttArb+sr7/Qbf1I0BurYZL6LcGIRNhY93hXyd eQMj5FziXLWaE+K205JIlStaZh/CLMCtZPz0G7TdC2s1jzHJsu05yClIvzpAawXDqV/G FWYY0/7tumWzjfKrFTn8OU7nKD8cOxIfio+nsIZgfcZ0Mp/pNcM3TkbScq39FvrVv5eO FDKMB6rWElpHdr4zOLoiY8uaf3LXcInTocAaDUHrbhNVvDDBfdYnxuTMmy85Yuz7cnQ4 tARr3KtW6wOs38LQemxbK70/XiyVPVlcKU4+0ZObGhS4lTnIwVhLJMmNYIg9Eq8zd1p9 YMHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n+FUPCFNemFxPC5V6Nzct7nJUUykcQhRaqxXoth+yEw=; b=Cjwkvp+T9S4o2oQ/EBzwsKOnMev3HSoG3SIFUCOwddTvmCjYV1tSWyTKttVcDQJJJo CRCVEZysh4mvixZNdGG8o84u/qiLaLDp6dZgDxGNnr1yMJAtIfpLiiegqG7CvH0Xm1Vh tT2kkk1w6Ht9i2IMZArqX6G/Nkgto275/2YJY7FTTa9O+06TuY5o1xZRJRnHdxX0rKi7 dY5FoU1Cw+aTUZtoFftPnBbD4lnsy43D1PK9gQJirdyw6wHveJdm/aRJb8vBhbGW5+ah BY+KTph58nYPeGW6G1YeW0MihNXP9g8tKdW4/05aG/dhqUJIZN8RgIu4OCtb/bXusCDe oQLg== X-Gm-Message-State: AMke39kOLW6SvfvfBsZait+DVMPzeSTRnrUkWBGvRiwYm2DideIaFDnINtZ1thW1TrZEMM5++Q6fZchOPz2gqMGdZMbYqlQG3mSCDrDbyJlkTXbXnFIim5e04/qDvF28vPmaZHC7/8Oah2Yua5M= X-Received: by 10.31.49.81 with SMTP id x78mr1054696vkx.82.1488549285516; Fri, 03 Mar 2017 05:54:45 -0800 (PST) X-Received: by 10.31.49.81 with SMTP id x78mr1054689vkx.82.1488549285239; Fri, 03 Mar 2017 05:54:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.134.129 with HTTP; Fri, 3 Mar 2017 05:54:44 -0800 (PST) From: David Farmer Date: Fri, 3 Mar 2017 07:54:44 -0600 Message-ID: Subject: Another try at a proposal for draft-ietf-6man-rfc4291bis-07 To: 6man WG Content-Type: multipart/alternative; boundary=001a114388b060b4050549d3e317 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 13:54:49 -0000 --001a114388b060b4050549d3e317 Content-Type: text/plain; charset=UTF-8 Modified the goals a bit based on feedback; 1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not classful! 2. Subnet Prefixes and IIDs are usually 64 bits 3. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by an IPv6-over-foo doc, and we can't change 64 bit IIDs for SLAAC, at least not now, it would break running code 4. Sites should get more than a /64 [BCP157] 5. Explicitly allow prefix lengths other than 64 bits for manually config and DHCPv6, most code does this now and has since the beginning 6. Avoid other explicit exceptions or recommendations for longer prefixes, like RFC6164 7. include references to [BCP204]/[RFC7934] and [RFC6052] in the right places In the current draft remove the 2nd paragraph of 2.4, then add the following two paragraphs at the end of section 2.4 IPv6 unicast routing is based on prefixes of any length up to 128 bits [BCP198]. However, unicast addresses usually have a subnet prefix and interface ID of 64 bits in length. The rationale for the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. Nevertheless, a unicast address may also be provided from a node's internal configuration or via DHCPv6[RFC3515], such addresses are assumed to have no internal structure, are treated as a single 128 bit quantity, and may be associated with a subnet prefix of any length. Then replace the 4th paragraph of 2.4.1 with; When a unicast address is formed from a subnet prefix and an automatically generated interface ID (e.g. Stateless Address Autoconfiguration(SLAAC)[RFC4862]), the interface ID is required to be 64 bits in length unless overridden in an "IPv6 over " specifications. The rationale for the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. And replace the second and third paragraphs of 2.4.5 with; As noted in Section 2.4, Global Unicast addresses usually have a 64-bit interface ID length (i.e., n + m = 64), and are formatted as described in Section 2.4.1. As discussed in [BCP 157], "it should be easy for an end site to obtain address space to number multiple subnets (i.e., a block larger than a single /64)" or in other words the subnet ID length should be great than or equal to 1 (i.e., m >= 1), with typical subnet ID lengths of 4, 8, 12, and 16 bits and therefore typical global routing prefix lengths of 60, 56, 52, and 48 bits respectively. A couple other quickies; Insert new paragraph at the end of 2.1 [BCP 204] recommends that networks provide general-purpose nodes with multiple global IPv6 addresses per interface when they attach to a link, describes the benefits of and the options for doing so. Insert new sentence at the end of 2.4.5 Additional IPv6 address that carry an IPv4 address are defined in IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114388b060b4050549d3e317 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Modified the goals a bit based on feedback;

    1. IPv6= unicast routing is 128 bits in length [BCP198], AKA not classful!
    2. Su= bnet Prefixes and IIDs are usually 64 bits
    3. IIDs of 64 bit are REQUIR= ED for SLAAC, except when overridden by an IPv6-over-foo doc, and we can= 9;t change 64 bit IIDs for SLAAC, at least not now, it would break running = code
    4. Sites should get more than a /64 [BCP157]
    5. Explicitly all= ow prefix lengths other than 64 bits for manually config and DHCPv6, most c= ode does this now and has since the beginning
    6. Avoid other explicit ex= ceptions or recommendations for longer prefixes, like RFC6164=C2=A0
    7. = include references to [BCP204]/[RFC7934] and [RFC6052] in the right places<= br>

    In the current draft remove the 2nd paragraph of 2.4, then add = the following two paragraphs at the end of section 2.4

    =C2=A0 =C2=A0= IPv6 unicast routing is based on prefixes of any length up to 128
    =C2=A0= =C2=A0bits [BCP198]. However, unicast addresses usually have a subnet
    = =C2=A0 =C2=A0prefix and interface ID of 64 bits in length. The rationale fo= r the
    =C2=A0 =C2=A064 bit boundary in IPv6 addresses can be found in [RF= C7421].

    =C2=A0 =C2=A0Nevertheless, a unicast address may also be pro= vided from a node's
    =C2=A0 =C2=A0internal configuration or via DHCP= v6[RFC3515], such addresses are
    =C2=A0 =C2=A0assumed to have no internal= structure, are treated as a single
    =C2=A0 =C2=A0128 bit quantity, and = may be associated with a subnet prefix of any
    =C2=A0 =C2=A0length.
    <= br>Then replace the 4th paragraph of 2.4.1 with;

    =C2=A0 =C2=A0When a= unicast address is formed from a subnet prefix and an
    =C2=A0 =C2=A0aut= omatically generated interface ID (e.g. Stateless Address
    =C2=A0 =C2=A0= Autoconfiguration(SLAAC)[RFC4862]), the interface ID is required
    =C2=A0= =C2=A0to be 64 bits in length unless overridden in an "IPv6 over
    = =C2=A0 =C2=A0<link>" specifications. The rationale for the 64 bi= t boundary in
    =C2=A0 =C2=A0IPv6 addresses can be found in [RFC7421].
    And replace the second and third paragraphs of 2.4.5 with;

    =C2= =A0 =C2=A0As noted in Section 2.4, Global Unicast addresses usually have =C2=A0 =C2=A0a 64-bit interface ID length (i.e., n + m =3D 64), and are <= br>=C2=A0 =C2=A0formatted as described in Section 2.4.1.

    =C2=A0 =C2= =A0As discussed in [BCP 157], "it should be easy for an end site to =C2=A0 =C2=A0obtain address space to number multiple subnets (i.e., a blo= ck
    =C2=A0 =C2=A0larger than a single /64)" or in other words the s= ubnet ID length
    =C2=A0 =C2=A0should be great than or equal to 1 (i.e., = m >=3D 1), with typical
    =C2=A0 =C2=A0subnet ID lengths of 4, 8, 12, = and 16 bits and therefore typical
    =C2=A0 =C2=A0global routing prefix le= ngths of 60, 56, 52, and 48 bits
    =C2=A0 =C2=A0respectively.

    A co= uple other quickies;

    Insert new paragraph at the end of 2.1

    =C2=A0 =C2=A0[BCP 204] recommends that networks p= rovide general-purpose
    =C2=A0 =C2=A0nodes with multiple global IPv6 add= resses per interface when
    =C2=A0 =C2=A0they attach to a link, describes= the benefits of and the options
    =C2=A0 =C2=A0for doing so.

    Insert new sentence at the end of 2.4.5

    =C2=A0 =C2=A0Additi= onal IPv6 address that carry an IPv4 address are defined in
    =C2=A0 =C2= =A0IPv6 Addressing of IPv4/IPv6 Translators [RFC6052].

    T= hanks

    --
    =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Network= ing & Telecommunication Services
    Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
    2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minneapolis, MN 55414-3029=C2=A0= =C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D


    --001a114388b060b4050549d3e317-- From nobody Fri Mar 3 06:21:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3975F12956E for ; Fri, 3 Mar 2017 06:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xqLRDgIYP97j for ; Fri, 3 Mar 2017 06:21:21 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6355C129547 for ; Fri, 3 Mar 2017 06:21:21 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v23ELJH0000588 for ; Fri, 3 Mar 2017 15:21:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4C799209C10 for ; Fri, 3 Mar 2017 15:21:19 +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 43108207E05 for ; Fri, 3 Mar 2017 15:21:19 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23ELJVe019410 for ; Fri, 3 Mar 2017 15:21:19 +0100 Subject: Re: Another try at a proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <36f25df7-7e8c-a203-9be9-884fde318f38@gmail.com> Date: Fri, 3 Mar 2017 15:21:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 14:21:23 -0000 Le 03/03/2017 à 14:54, David Farmer a écrit : > Modified the goals a bit based on feedback; > > 1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not classful! Ok for me. > 2. Subnet Prefixes and IIDs are usually 64 bits s/usually/in some places > 3. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by an > IPv6-over-foo doc, and we can't change 64 bit IIDs for SLAAC, at least > not now, it would break running code We cant change but we MAY > 4. Sites should get more than a /64 [BCP157] Sites _and_ smaller devices like when they are mobile > 5. Explicitly allow prefix lengths other than 64 bits for manually > config and DHCPv6, most code does this now and has since the beginning With bugs. > 6. Avoid other explicit exceptions or recommendations for longer > prefixes, like RFC6164 > 7. include references to [BCP204]/[RFC7934] and [RFC6052] in the right > places > > In the current draft remove the 2nd paragraph of 2.4, then add the > following two paragraphs at the end of section 2.4 > > IPv6 unicast routing is based on prefixes of any length up to 128 > bits [BCP198]. However, unicast addresses usually have a subnet ^ in some places > prefix and interface ID of 64 bits in length. The rationale for the > 64 bit boundary in IPv6 addresses can be found in [RFC7421]. I disagree with some parts of that RFC. Why citing it in its entirety? The text reads as if we use that RFC to motivate cotninuing with the 64bit split. Why not citing just its par 3 of section 1: "The notion of a /64 boundary in the address was introduced after the initial design of IPv6, following a period when it was expected to be at /80. There were two motivations for setting it at /64. One was the original "8+8" proposal [ODELL] that eventually led to the Identifier-Locator Network Protocol (ILNP) [RFC6741], which required a fixed point for the split between local and wide-area parts of the address. The other was the expectation that 64-bit Extended Unique Identifier (EUI-64) Media Access Control (MAC) addresses would become widespread in place of 48-bit addresses, coupled with the plan at that time that auto-configured addresses would normally be based on interface identifiers derived from MAC addresses." And add: since then we did this (quoting a poster to this list) > RFC 3513 "only /64 is valid" > RFC 3627 "don't use /127, use /126 if you must" > RFC 4291 "reaffirming: only /64 is valid" > RFC 6164 "a /127 is OK to use too" > RFC 6583 "there are problems with /64" > RFC 7421 "/64 is the best!" > RFC 7608 "every prefix length must be forward-able" > RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!" > Nevertheless, a unicast address may also be provided from a node's > internal configuration or via DHCPv6[RFC3515], such addresses are > assumed to have no internal structure, are treated as a single ^^^^^^^^^^^^^^^^^^^^^ That is 'opaque'. I would like that to be stressed, especially in this context of this document where we set many bits and limits at many places. > 128 bit quantity, and may be associated with a subnet prefix of any > length. I agree. > Then replace the 4th paragraph of 2.4.1 with; > > When a unicast address is formed from a subnet prefix and an > automatically generated interface ID (e.g. Stateless Address > Autoconfiguration(SLAAC)[RFC4862]), the interface ID is required > to be 64 bits in length unless overridden in an "IPv6 over 'overriden' there sounds like somebody comes after. How about saying 'MAY'? > " specifications. The rationale for the 64 bit boundary in > IPv6 addresses can be found in [RFC7421]. Again citing that RFC, again as a 'rationale'. Again how about citing just its par 3 of its section 1. > And replace the second and third paragraphs of 2.4.5 with; > > As noted in Section 2.4, Global Unicast addresses usually have > a 64-bit interface ID length (i.e., n + m = 64), and are > formatted as described in Section 2.4.1. > > As discussed in [BCP 157], "it should be easy for an end site to for an end site and for an end-user on computer that could route IP packets. > obtain address space to number multiple subnets (i.e., a block > larger than a single /64)" or in other words the subnet ID length This use of word 'larger' when talking /plens is always ambiguous. Because larger value of plen means smaller number of IP addresses, and to others no. It's clearer if we said: 'a unique block defined by a prefix length of value smaller than 64'. And instead of i.e., we could say 'e.g.', because one is as happy if she gets two /64s as if she gets one /63. And that is impossible if the text says 'id est a block'. > should be great than or equal to 1 (i.e., m >= 1), with typical ^er > subnet ID lengths of 4, 8, 12, and 16 bits and therefore typical > global routing prefix lengths of 60, 56, 52, and 48 bits > respectively. Typical... when talking prefix lenghts I really wouldnt call one typical. Not even 64. > A couple other quickies; > > Insert new paragraph at the end of 2.1 > > [BCP 204] recommends that networks provide general-purpose > nodes with multiple global IPv6 addresses per interface when > they attach to a link, describes the benefits of and the options > for doing so. I agree. Further: in addition to BCP204 recommendation, the networks MUST provide multiple /64s, or other-than-64-prefixed subnets to nodes, if so requested by the nodes. Alex > Insert new sentence at the end of 2.4.5 > > Additional IPv6 address that carry an IPv4 address are defined in > IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]. > > Thanks > > -- > =============================================== > David Farmer Email:farmer@umn.edu > > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Mar 3 08:37:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F701298CE for ; Fri, 3 Mar 2017 08:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pI3-6mkfdn9V for ; Fri, 3 Mar 2017 08:37:28 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C537A1298D0 for ; Fri, 3 Mar 2017 08:37:27 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id g10so77273352wrg.2 for ; Fri, 03 Mar 2017 08:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qACONTNZ/ycRpKntenDDRp7PAfy07b4lW8JIeQjT2js=; b=b6umh+5dnmYJhnbzyFx0PD6l0NhuCUyvWgib80hfB5usmzzbsW/goruZVRBm6BWAHC M60BLa4fEniJupH4Rl0e7P5lX0OdzEeC9iXDmr4wZXfFZeBUsncTen+Ltst6AW/8TUJR QFu8vv5MGKh5r4YGjhWw7U7J1uE7iZOGk8OCOabd3exTB7nDTE3uL849CCiVRa4NKljc NR8ffxGIjEljYl6aTVc/R+UTSzbd6Cp8nbwHlvelXlV5HvpEpanHh4e/jjJELgp7/PjJ 3Tuv0q59g7BogBi69Iynj2thEZayFwxBpWQLYsPXW3zelqCFl5pe/e9Mx0LcG1EVqrXZ 1v5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qACONTNZ/ycRpKntenDDRp7PAfy07b4lW8JIeQjT2js=; b=GsHDrKqd9QTSxxMTtSFxJXU32GDupbKCNUQsxdGQEp/Xy5J8JjSFdYGzDp3Lwyp+6T tYxs8DNPW5rkJiyAGu7nDfGpYUzWRtms2lk5lXWCkBMoW7CUZotG3HwKCJJQZo8pzgNf /fqXd1x7EXBnD9r9uazGxDodGWqrm4+jGjg+xOXzthCv+YKcOuuIIcrkxEzBoAVztLSi 3Ci1vzsIiUyK4v26XEC0gBK2BHIxxLfciURgT4jqtG3vNeBKM7eNC0x1OeK+EnPNS6XX UysY89chesmg9LB7VYxSq0X1WghTH2Ak/di+EqVEUE5B0lNtoW6kinwff9xMzhQfwjVN amXA== X-Gm-Message-State: AMke39nsV5u8Yd4HyiGv5JY/7Vbb0Nl/IgOBYPSm8AY9R6VL8O71AvNR+UIykcr04FTFrroyDph5C9ZdXAiUOg== X-Received: by 10.223.163.206 with SMTP id m14mr3855936wrb.34.1488559046062; Fri, 03 Mar 2017 08:37:26 -0800 (PST) MIME-Version: 1.0 References: <20170223134026.GI5069@gir.theapt.org> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> <20170302224856.E63AB65D34EC@rock.dv.isc.org> <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com> <787AE7BB302AE849A7480A190F8B933009E1BE96@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <31396f41-0f08-3677-8012-4fd54247aa76@gmail.com> In-Reply-To: <31396f41-0f08-3677-8012-4fd54247aa76@gmail.com> From: Ca By Date: Fri, 03 Mar 2017 16:37:14 +0000 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Alexandre Petrescu , Mark Andrews , mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=f403045f22042af9f80549d6292d Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:37:31 -0000 --f403045f22042af9f80549d6292d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 3, 2017 at 2:52 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 03/03/2017 =C3=A0 11:30, mohamed.boucadair@orange.com a =C3=A9crit : > > Hi Alex, > > > > > >> This is why I dont understand the cellular operators dont do > >> DHCPv6-PD. And I guess it is so because they are told it's > >> sufficient to run the 64share INFORMATIONAL RFC. > > > > This is a chicken-and-egg problem: you need both the cellular device > > and the network side to support prefix delegation + prefix exclude > > option, > > How can that vicious circle be broken? Money. This is not a 3GPP release issue, this is a money backing the deployment cost. And, despite the cost of free software being $0, my ipv6 project was charged nearly a million dollars in QA cost from adjacent business units... just as an example that nothing is free. That said, if the v2v customer requiring PD put in an order for 10,000+ (guessing) lines , they would likely get dhcpv6-pd. Asking for it at ietf, not likely helpful. The standards and guidance all say do PD, now you just need $ > > I have some smartphone and other M2M modules here on which we could try > a few things. What would operator expect to hear from this smartphone? > > Is the ISC DHCPv6-PD Client messages enough? > > Does operator also need 'prefix exclude'? Mandatory? > > Is the ISC DHCPv6-PD implementing 'prefix exclude'? > > > but while waiting for that to happen /64 share is your solution. > > Operator should understand that /64 share is impossible to use in > concrete settings like vehicular networks, road-side units, and similar. > > > Below what you can read in RFC7849: > > If I read it I will certainly suggest improvements to it. It should > reflect reality. > > > =3D=3D=3D=3D=3D L_REC#1: For deployments that require that the same /6= 4 prefix > > be shared, the cellular device should support [RFC7278] to enable > > sharing a /64 prefix between the LAN and the WAN interfaces. The WAN > > interface is the one towards the Gateway GPRS Support Node (GGSN) / > > Packet Data Network Gateway (PGW). > > > > Prefix Delegation (refer to L_REC#2) is the target solution for > > It's not a 'target', it is a 'now'. > > > distributing prefixes in the LAN side but, because the device may > > attach to earlier 3GPP release networks, a means to share a /64 > > prefix is also recommended [RFC7278]. > > No! That recommendation is wrong. That RFC is INFORMATIONAL and we > should stop recommending it. I has huge problems, at least with respect > to scalability. > > > [RFC7278] must be invoked only if Prefix Delegation is not in use. > > ... _and_ if it works for the network being deployed. If it does not > work, it MUST NOT be invoked. > > > L_REC#2: The cellular device must support Prefix Delegation > > capabilities [RFC3633] and must support the Prefix Exclude Option for > > DHCPv6-based Prefix Delegation as defined in [RFC6603]. > > Why is the 'prefix exclude' option a MUST? I may need to understand > that, by further reading... > > > Particularly, it must behave as a Requesting Router. > > Yes, and it is a MUST not a must. > > > > Cellular networks are more and more perceived as an alternative to > > fixed broadband networks for home IP- based services delivery; > > I agree. > > > especially with the advent of smartphones and 3GPP data dongles. > > _and_ M2M and IoT devices which are not 'dongles' (btw, 'dongles' are > only the USB dongles, there are no other kinds of dongles). > > > There is a need for an efficient mechanism to assign larger prefixes > > (other than /64s) to cellular hosts > > I fully agree. > > > so that each LAN segment can get its own /64 prefix > > _if_ that LAN is an Ethernet, yes it needs a /64. Often it is the case. > > > and multi-link subnet issues to be avoided. > > I agree, RFC must be cited. > > > In case a prefix is delegated to a cellular host using DHCPv6, the > > cellular device will be configured with two prefixes: > > > > (1) one for the 3GPP link allocated using the Stateless Address > > Autoconfiguration (SLAAC) mechanism and > > > > (2) another one delegated for LANs acquired during the Prefix > > Delegation operation. > > I dont know what you mean by 'configured', but this second prefix may > just be in the rt table of the device (not necessarily on its interfaces)= . > > How about the default route? > > > Note that the 3GPP network architecture requires both the WAN and the > > delegated prefix to be aggregatable so the subscriber can be > > identified using a single prefix. > > IT's good to avoid waste. > > > Without the Prefix Exclude Option, the delegating router (GGSN/PGW) > > will have to ensure compliance with [RFC3633] (e.g., halving the > > delegated prefix and assigning the WAN prefix out of the first half > > and the prefix to be delegated to the terminal from the second > > half). > > So 'prefix exclude' is not mandatory in order to have DHCPv6-PD working. > > > > > Because Prefix Delegation capabilities may not be available in some > > attached networks, L_REC#1 is strongly recommended to accommodate > > early deployments. =3D=3D=3D=3D=3D > > It's wrong. We should _never_ recommend somehting we know it does not > scale. Because if we do it may get in widespread use and later we'll > have a hard time getting rid of. > > Alex > > > > > Cheers, Med > > > > > >> -----Message d'origine----- De : ipv6 > >> [mailto:ipv6-bounces@ietf.org] De la part de Alexandre Petrescu > >> Envoy=C3=A9 : vendredi 3 mars 2017 10:29 =C3=80 : Mark Andrews Cc : > >> ipv6@ietf.org Objet : Re: Objection to > >> draft-ietf-6man-rfc4291bis-07.txt > >> > >> > >> > >> Le 02/03/2017 =C3=A0 23:48, Mark Andrews a =C3=A9crit : > >>> > >>> In message <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com>, > >>> Alexandre Petrescu writes: > >>>> Le 02/03/2017 20:25, JORDI PALET MARTINEZ a crit : > >>>>> I understood from one of your previous emails that 3GPP > >>>>> doesnt require DHCPv6-PD. > >>>> > >>>> Right - if I understand correctly, it does not require > >>>> DHCPv6-PD on the UE. Maybe in the core, but not in the UE. > >>>> > >>>>> RFC6653, suggest its use, so probably we got confused > >>>>> ourselves and 3GPP is actually using it. > >>>>> > >>>>> 6rd is a different thing, because is actually IPv4 link and > >>>>> IPv6 is a tunnel, so you typically use DHCP (v4). > >>>> > >>>> I agree. > >>>> > >>>>> In IPv6-only world (including cellular), the WAN link will > >>>>> be IPv6-only instead of dual-stack. This is already > >>>>> happening. > >>>>> > >>>>> If they dont use it, I guess is the same reason why big > >>>>> vendors didnt implemented yet RDDNS > >>>> > >>>> I wonder if Windows refusing RDNSS doesn't have somehting to > >>>> do with its Teredo; and extending this logic to smartphones: > >>>> the lack of answers to DHCPv6-PD issued from the UE may have > >>>> something to do with 464xlat presence. > >>>> > >>>> Could it be that 464xlat presence on UE makes it that DHCPv6-PD > >>>> is impossible on same UE? > >>> > >>> No. They are or should be orthogonal. One is about providing > >>> IPv4 as as service. The other is about providing IPv6 address > >>> space. > >> > >> I can agree. > >> > >> With my operator I asked her once 'why not giving DHCPc6-PD to > >> smartphone' and she replied 'because now we do 464xlat on the > >> smartphone, and that is sufficient'. As such it sounds illogical > >> statement, although I guess s/he has some reasons to say so. > >> > >> But let me ask differently: maybe it's because 464xlat requires > >> some kernel version that DHCPv6-PD doestn support, or vice-versa? > >> Maybe it's because once you run 464xlat on smartphone it takes > >> control of the unique default route and DHCPv6-PD couldnt? Some > >> reason like that? > >> > >> Has one tried DHCPv6-PD software simultaneosuly with 464xlat? > >> (even knowing the cellular operator would not reply to DHCPv6 > >> Slicitations). > >> > >>>>> Cellular world is using 464XLAT, and they use DHCPv6-PD. > >>>>> Check RFC6877. > >>>> > >>>> I guess you mean cellular stations (like BS, not the User > >>>> Equipment) uses DHCPv6-PD within the fixed network. > >>> > >>> No, the UE should be using DHCPv6-PD. This is how tethered > >>> equipement should be getting IPv6 address space. > >> > >> I agree with yuo. > >> > >> This is why I dont understand the cellular operators dont do > >> DHCPv6-PD. And I guess it is so because they are told it's > >> sufficient to run the 64share INFORMATIONAL RFC. > >> > >> Are the people advising 64share to tethering-willing telecom > >> operators conscious it's non-interoperable? > >> > >> Is the 64share advice coming together with the claim there are > >> enough /64s out there? > >> > >> Alex > >> > >>>> Because cellular operator I am aware of replies to DHCPv6-PD > >>>> requests issued from an User Equipment. > >>>> > >>>> Alex > >>>> > >>>>> > >>>>> Saludos, Jordi > >>>>> > >>>>> > >>>>> -----Mensaje original----- De: ipv6 > >>>>> en nombre de Alexandre Petrescu > >>>>> Responder a: > >>>>> Fecha: jueves, 2 de marzo de > >>>>> 2017, 20:15 Para: Asunto: Re: Objection to > >>>>> draft-ietf-6man-rfc4291bis-07.txt > >>>>> > >>>>> > >>>>> > >>>>> Le 02/03/2017 20:06, JORDI PALET MARTINEZ a crit : > >>>>>> I guess because the lack of DHCPv6-PD support, as you > >>>>>> already indicated? > >>>>> > >>>>> But for deity's sake - DHCPv6-PD is available as open > >>>>> source... it's common software. Just download and install. > >>>>> The IETF Specs suggest it, and the 3GPP specs require it > >>>>> too. > >>>>> > >>>>> There must be something else making these router equipment > >>>>> manufacturers refraining from downloading and installing > >>>>> DHCPv6-PD. > >>>>> > >>>>>> I think majority of the households and business customers > >>>>>> get configured the CPE by means for DHCPv6-PD > >>>>> > >>>>> AFAIK my CPE at home does not use DHCPv6-PD, but something > >>>>> based on IPv4, like 6rd. I think it's something developped > >>>>> in-house at that particular operator. > >>>>> > >>>>> Alex > >>>>> > >>>>>> > >>>>>> Saludos, Jordi > >>>>>> > >>>>>> > >>>>>> -----Mensaje original----- De: ipv6 > >>>>>> en nombre de Alexandre Petrescu > >>>>>> Responder a: > >>>>>> Fecha: jueves, 2 de marzo de > >>>>>> 2017, 20:02 Para: Asunto: Re: Objection to > >>>>>> draft-ietf-6man-rfc4291bis-07.txt > >>>>>> > >>>>>> > >>>>>> > >>>>>> Le 02/03/2017 19:54, JORDI PALET MARTINEZ a crit : > >>>>>>> Actually, is not correct that most use /56 for > >>>>>>> residential. > >>>>>>> > >>>>>>>> From my last review of the survey, worldwide, 22% use > >>>>>>>> /48, 35% use /56, but there is a lot of ISPs (33%) > >>>>>>>> doing it wrong and using /64, which of course, we are > >>>>>>>> explaining them that is wrong. 10% use other sizes. > >>>>>> > >>>>>> So how comes that households can get /56s but smartphones > >>>>>> no? > >>>>>> > >>>>>> Really there must be something there hidden. > >>>>>> > >>>>>> Alex > >>>>>> > >>>>>>> > >>>>>>> Full details at: > >>>>>>> > >>>>>>> > >>>> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6- > >> deployment-s > >>>> > >>>> > >>>> > >>>> > >> urvey > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>>> Saludos, Jordi > >>>>>>> > >>>>>>> > >>>>>>> -----Mensaje original----- De: ipv6 > >>>>>>> en nombre de Mikael Abrahamsson > >>>>>>> Organizacin: People's Front Against > >>>>>>> WWW Responder a: Fecha: jueves, 2 de > >>>>>>> marzo de 2017, 19:33 Para: Alexandre Petrescu > >>>>>>> CC: > >>>>>>> Asunto: Re: Objection to > >>>>>>> draft-ietf-6man-rfc4291bis-07.txt > >>>>>>> > >>>>>>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: > >>>>>>> > >>>>>>>> YEs yes, but how much of that /44 is covering the > >>>>>>>> end-users and how much is reserved for > >>>>>>>> interconnnections? > >>>>>>> > >>>>>>> Nothing. It's /44 to the GGSN/SPGW. > >>>>>>> > >>>>>>>> Ah great, but I guess few cellular operators (if any?) > >>>>>>>> are LIRs. Or maybe that's true and I didnt know. > >>>>>>> > >>>>>>> You don't know. > >>>>>>> > >>>>>>>> If all this were that simple and clearcut - there are > >>>>>>>> enough /64s out there - then why operators only assign > >>>>>>>> one per one end user? > >>>>>>> > >>>>>>> Because DHCPv6-PD hasn't been implemented in mobile > >>>>>>> networks yet (that I know of). So that's all they can do > >>>>>>> per 3GPP standards. > >>>>>>> > >>>>>>> Residential rollouts, most use /56 per customer. > >>>>>>> > >>>>>>>> From the RIRs, you can without further justification > >>>>>>>> get /48 per "site", > >>>>>>> so if you show up to RIR and you're LIR and you say > >>>>>>> "hello, I have 40 million customers and I want to give > >>>>>>> each customer a /48" then they'll give you a /22 most > >>>>>>> likely. You're perfectly within your right as an operator > >>>>>>> to deploy /48 per customer per current RIR rules that I > >>>>>>> am aware of. > >>>>>>> > >>>>>>> -- Mikael Abrahamsson email: swmike@swm.pp.se > >>>>>>> > >>>>>>> > -------------------------------------------------------------------- > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >> > >>>>>>> > >>>>>>> > >>>>>>> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>>>>> > -------------------------------------------------------------------- > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >> > >>>>>>> > >>>>>>> > >>>>>>> > ********************************************** IPv4 is over Are > >>>>>>> you ready for the new Internet ? > >>>>>>> http://www.consulintel.es The IPv6 Company > >>>>>>> > >>>>>>> This electronic message contains information which may > >>>>>>> be privileged or confidential. The information is > >>>>>>> intended to be for the use of the individual(s) named > >>>>>>> above. If you are not the intended recipient be aware > >>>>>>> that any disclosure, copying, distribution or use of the > >>>>>>> contents of this information, including attached files, > >>>>>>> is prohibited. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -------------------------------------------------------------------- > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >> > >>>>>>> > >>>>>>> > >>>>>>> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>>>>> > -------------------------------------------------------------------- > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >> > >>>>>>> > >>>>>>> > >>>>>>> > -------------------------------------------------------------------- > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> IETF IPv6 working group mailing list ipv6@ietf.org > >>>>> Administrative > >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>>>> ------------------------------------------------------------------= -- > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >> > >>>>>> > >>>>>> > >>>>>> > ********************************************** IPv4 is over Are > >>>>>> you ready for the new Internet ? http://www.consulintel.es > >>>>>> The IPv6 Company > >>>>>> > >>>>>> This electronic message contains information which may be > >>>>>> privileged or confidential. The information is intended to > >>>>>> be for the use of the individual(s) named above. If you > >>>>>> are not the intended recipient be aware that any > >>>>>> disclosure, copying, distribution or use of the contents > >>>>>> of this information, including attached files, is > >>>>>> prohibited. > >>>>>> > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------------= -- > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> > >> > >>>>>> > >>>>>> > >>>>>> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>>>> ------------------------------------------------------------------= -- > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> > >> > >>>>>> > >>>>>> > >>>>>> > -------------------------------------------------------------------- > >>>>> IETF IPv6 working group mailing list ipv6@ietf.org > >>>>> Administrative Requests: > >>>>> https://www.ietf.org/mailman/listinfo/ipv6 > >>>>> -------------------------------------------------------------------= - > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >> > >>>>> > >>>>> > >>>>> > ********************************************** IPv4 is over Are you > >>>>> ready for the new Internet ? http://www.consulintel.es The > >>>>> IPv6 Company > >>>>> > >>>>> This electronic message contains information which may be > >>>>> privileged or confidential. The information is intended to be > >>>>> for the use of the individual(s) named above. If you are not > >>>>> the intended recipient be aware that any disclosure, copying, > >>>>> distribution or use of the contents of this information, > >>>>> including attached files, is prohibited. > >>>>> > >>>>> > >>>>> > >>>>> -------------------------------------------------------------------= - > >>>>> > >>>>> > >>>>> > >>>>> > >> > >>>>> > >>>>> > >>>>> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>>> -------------------------------------------------------------------= - > >>>>> > >>>> > >>>> > >>>>> > >>>>> > >>>>> > >> > >>>>> > >>>>> > >>>>> > -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list ipv6@ietf.org > >>>> Administrative Requests: > >>>> https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > >>> > >> > >> > >>>> > >>>> > >>>> > -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --f403045f22042af9f80549d6292d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    On Fri, Mar 3, 2017 at 2:52 AM Ale= xandre Petrescu <alexand= re.petrescu@gmail.com> wrote:

    Le 03/03/2017 =C3=A0 11:30, mohamed.boucadair@orange.com a = =C3=A9crit :
    > Hi Alex,
    >
    >
    >> This is why I dont understand the cellular operators dont do
    >> DHCPv6-PD. And I guess it is so because they are told it's
    >> sufficient to run the 64share INFORMATIONAL RFC.
    >
    > This is a chicken-and-egg problem: you need both the cellular device >=C2=A0 and the network side to support prefix delegation + prefix exclu= de
    > option,

    How can that vicious circle be broken?

    Mone= y.=C2=A0 This is not a 3GPP release issue, this is a money backing the depl= oyment cost.=C2=A0 And, despite the cost of free software being $0, my ipv6= project was charged nearly a million dollars in QA cost from adjacent busi= ness units... just as an example that nothing is free.=C2=A0

    =
    That said, if the v2v customer requiring PD put in an order for = 10,000+ (guessing) lines , they would likely get dhcpv6-pd.=C2=A0

    Asking for it at ietf, not likely helpful. The standards an= d guidance all say do PD, now you just need $=C2=A0




    I have some smartphone and other M2M modules here on which we could try
    a few things.=C2=A0 What would operator expect to hear from this smartphone= ?

    Is the ISC DHCPv6-PD Client messages enough?

    Does operator also need 'prefix exclude'?=C2=A0 Mandatory?

    Is the ISC DHCPv6-PD implementing 'prefix exclude'?

    > but while waiting for that to happen /64 share is your solution.

    Operator should understand that /64 share is impossible to use in
    concrete settings like vehicular networks, road-side units, and similar.
    > Below what you can read in RFC7849:

    If I read it I will certainly suggest improvements to it.=C2=A0 It should reflect reality.

    > =3D=3D=3D=3D=3D L_REC#1:=C2=A0 For deployments that require that the s= ame /64 prefix
    > be shared, the cellular device should support [RFC7278] to enable
    > sharing a /64 prefix between the LAN and the WAN interfaces. The WAN > interface is the one towards the Gateway GPRS Support Node (GGSN) / > Packet Data Network Gateway (PGW).
    >
    > Prefix Delegation (refer to L_REC#2) is the target solution for

    It's not a 'target', it is a 'now'.

    > distributing prefixes in the LAN side but, because the device may
    > attach to earlier 3GPP release networks, a means to share a /64
    > prefix is also recommended [RFC7278].

    No!=C2=A0 That recommendation is wrong.=C2=A0 That RFC is INFORMATIONAL and= we
    should stop recommending it.=C2=A0 I has huge problems, at least with respe= ct
    to scalability.

    > [RFC7278] must be invoked only if Prefix Delegation is not in use.

    ... _and_ if it works for the network being deployed.=C2=A0 If it does not<= br class=3D"gmail_msg"> work, it MUST NOT be invoked.

    > L_REC#2:=C2=A0 The cellular device must support Prefix Delegation
    > capabilities [RFC3633] and must support the Prefix Exclude Option for<= br class=3D"gmail_msg"> > DHCPv6-based Prefix Delegation as defined in [RFC6603].

    Why is the 'prefix exclude' option a MUST?=C2=A0 I may need to unde= rstand
    that, by further reading...

    > Particularly, it must behave as a Requesting Router.

    Yes, and it is a MUST not a must.
    >
    > Cellular networks are more and more perceived as an alternative to
    > fixed broadband networks for home IP- based services delivery;

    I agree.

    > especially with the advent of smartphones and 3GPP data dongles.

    _and_ M2M and IoT devices which are not 'dongles' (btw, 'dongle= s' are
    only the USB dongles, there are no other kinds of dongles).

    > There is a need for an efficient mechanism to assign larger prefixes >=C2=A0 (other than /64s) to cellular hosts

    I fully agree.

    > so that each LAN segment can get its own /64 prefix

    _if_ that LAN is an Ethernet, yes it needs a /64.=C2=A0 Often it is the cas= e.

    > and multi-link subnet issues to be avoided.

    I agree, RFC must be cited.

    > In case a prefix is delegated to a cellular host using DHCPv6, the
    > cellular device will be configured with two prefixes:
    >
    > (1)=C2=A0 one for the 3GPP link allocated using the Stateless Address<= br class=3D"gmail_msg"> > Autoconfiguration (SLAAC) mechanism and
    >
    > (2)=C2=A0 another one delegated for LANs acquired during the Prefix > Delegation operation.

    I dont know what you mean by 'configured', but this second prefix m= ay
    just be in the rt table of the device (not necessarily on its interfaces).<= br class=3D"gmail_msg">
    How about the default route?

    > Note that the 3GPP network architecture requires both the WAN and the<= br class=3D"gmail_msg"> > delegated prefix to be aggregatable so the subscriber can be
    > identified using a single prefix.

    IT's good to avoid waste.

    > Without the Prefix Exclude Option, the delegating router (GGSN/PGW) > will have to ensure compliance with [RFC3633] (e.g., halving the
    > delegated prefix and assigning the WAN prefix out of the first half > and the prefix to be delegated to the terminal from the second
    > half).

    So 'prefix exclude' is not mandatory in order to have DHCPv6-PD wor= king.

    >
    > Because Prefix Delegation capabilities may not be available in some > attached networks, L_REC#1 is strongly recommended to accommodate
    > early deployments. =3D=3D=3D=3D=3D

    It's wrong.=C2=A0 We should _never_ recommend somehting we know it does= not
    scale.=C2=A0 Because if we do it may get in widespread use and later we'= ;ll
    have a hard time getting rid of.

    Alex

    >
    > Cheers, Med
    >
    >
    >> -----Message d'origine----- De : ipv6
    >> [mailto:ipv6-bounces@ietf.org] De la part de Alexandre Pet= rescu
    >> Envoy=C3=A9 : vendredi 3 mars 2017 10:29 =C3=80 : Mark Andrews Cc = :
    >> ipv6@ietf.org Objet : Re: Objection to
    >> draft-ietf-6man-rfc4291bis-07.txt
    >>
    >>
    >>
    >> Le 02/03/2017 =C3=A0 23:48, Mark Andrews a =C3=A9crit :
    >>>
    >>> In message <6b89579e-62e8-dfb5= -070e-b08989b9492a@gmail.com>,
    >>> Alexandre Petrescu writes:
    >>>> Le 02/03/2017=C2=A0 20:25, JORDI PALET MARTINEZ a crit : >>>>> I understood from one of your previous emails that 3GP= P
    >>>>> doesnt require DHCPv6-PD.
    >>>>
    >>>> Right - if I understand correctly, it does not require
    >>>> DHCPv6-PD on the UE.=C2=A0 Maybe in the core, but not in t= he UE.
    >>>>
    >>>>> RFC6653, suggest its use, so probably we got confused<= br class=3D"gmail_msg"> >>>>> ourselves and 3GPP is actually using it.
    >>>>>
    >>>>> 6rd is a different thing, because is actually IPv4 lin= k and
    >>>>> IPv6 is a tunnel, so you typically use DHCP (v4).
    >>>>
    >>>> I agree.
    >>>>
    >>>>> In IPv6-only world (including cellular), the WAN link = will
    >>>>> be IPv6-only instead of dual-stack. This is already >>>>> happening.
    >>>>>
    >>>>> If they dont use it, I guess is the same reason why bi= g
    >>>>> vendors didnt implemented yet RDDNS
    >>>>
    >>>> I wonder if Windows refusing RDNSS doesn't have someht= ing to
    >>>> do with its Teredo; and extending this logic to smartphone= s:
    >>>> the lack of answers to DHCPv6-PD issued from the UE may ha= ve
    >>>> something to do with 464xlat presence.
    >>>>
    >>>> Could it be that 464xlat presence on UE makes it that DHCP= v6-PD
    >>>> is impossible on same UE?
    >>>
    >>> No.=C2=A0 They are or should be orthogonal.=C2=A0 One is about= providing
    >>> IPv4 as as service.=C2=A0 The other is about providing IPv6 ad= dress
    >>> space.
    >>
    >> I can agree.
    >>
    >> With my operator I asked her once 'why not giving DHCPc6-PD to=
    >> smartphone' and she replied 'because now we do 464xlat on = the
    >> smartphone, and that is sufficient'.=C2=A0 As such it sounds i= llogical
    >> statement, although I guess s/he has some reasons to say so.
    >>
    >> But let me ask differently: maybe it's because 464xlat require= s
    >> some kernel version that DHCPv6-PD doestn support, or vice-versa?<= br class=3D"gmail_msg"> >> Maybe it's because once you run 464xlat on smartphone it takes=
    >> control of the unique default route and DHCPv6-PD couldnt?=C2=A0 S= ome
    >> reason like that?
    >>
    >> Has one tried DHCPv6-PD software simultaneosuly with 464xlat?
    >> (even knowing the cellular operator would not reply to DHCPv6
    >> Slicitations).
    >>
    >>>>> Cellular world is using 464XLAT, and they use DHCPv6-P= D.
    >>>>> Check RFC6877.
    >>>>
    >>>> I guess you mean cellular stations (like BS, not the User<= br class=3D"gmail_msg"> >>>> Equipment) uses DHCPv6-PD within the fixed network.
    >>>
    >>> No, the UE should be using DHCPv6-PD.=C2=A0 This is how tether= ed
    >>> equipement should be getting IPv6 address space.
    >>
    >> I agree with yuo.
    >>
    >> This is why I dont understand the cellular operators dont do
    >> DHCPv6-PD. And I guess it is so because they are told it's
    >> sufficient to run the 64share INFORMATIONAL RFC.
    >>
    >> Are the people advising 64share to tethering-willing telecom
    >> operators conscious it's non-interoperable?
    >>
    >> Is the 64share advice coming together with the claim there are
    >> enough /64s out there?
    >>
    >> Alex
    >>
    >>>> Because cellular operator I am aware of replies to DHCPv6-= PD
    >>>> requests issued from an User Equipment.
    >>>>
    >>>> Alex
    >>>>
    >>>>>
    >>>>> Saludos, Jordi
    >>>>>
    >>>>>
    >>>>> -----Mensaje original----- De: ipv6 <ipv6-bounc= es@ietf.org>
    >>>>> en nombre de Alexandre Petrescu
    >>>>> <alexandre.petrescu@gmail.com> Re= sponder a:
    >>>>> <alexandre.petrescu@gmail.com> Fe= cha: jueves, 2 de marzo de
    >>>>> 2017, 20:15 Para: <ipv6@ietf.org> Asunto: Re: Ob= jection to
    >>>>> draft-ietf-6man-rfc4291bis-07.txt
    >>>>>
    >>>>>
    >>>>>
    >>>>> Le 02/03/2017=C2=A0 20:06, JORDI PALET MARTINEZ a crit= :
    >>>>>> I guess because the lack of DHCPv6-PD support, as = you
    >>>>>> already indicated?
    >>>>>
    >>>>> But for deity's sake - DHCPv6-PD is available as o= pen
    >>>>> source... it's common software.=C2=A0 Just downloa= d and install.
    >>>>> The IETF Specs suggest it, and the 3GPP specs require = it
    >>>>> too.
    >>>>>
    >>>>> There must be something else making these router equip= ment
    >>>>> manufacturers refraining from downloading and installi= ng
    >>>>> DHCPv6-PD.
    >>>>>
    >>>>>> I think majority of the households and business cu= stomers
    >>>>>> get configured the CPE by means for DHCPv6-PD
    >>>>>
    >>>>> AFAIK my CPE at home does not use DHCPv6-PD, but somet= hing
    >>>>> based on IPv4, like 6rd.=C2=A0 I think it's someth= ing developped
    >>>>> in-house at that particular operator.
    >>>>>
    >>>>> Alex
    >>>>>
    >>>>>>
    >>>>>> Saludos, Jordi
    >>>>>>
    >>>>>>
    >>>>>> -----Mensaje original----- De: ipv6 <ipv6-b= ounces@ietf.org>
    >>>>>> en nombre de Alexandre Petrescu
    >>>>>> <alexandre.petrescu@gmail.com>= ; Responder a:
    >>>>>> <alexandre.petrescu@gmail.com>= ; Fecha: jueves, 2 de marzo de
    >>>>>> 2017, 20:02 Para: <ipv6@ietf.org> Asunto: Re= : Objection to
    >>>>>> draft-ietf-6man-rfc4291bis-07.txt
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>> Le 02/03/2017=C2=A0 19:54, JORDI PALET MARTINEZ a = crit :
    >>>>>>> Actually, is not correct that most use /56 for=
    >>>>>>> residential.
    >>>>>>>
    >>>>>>>> From my last review of the survey, worldwi= de, 22% use
    >>>>>>>> /48, 35% use /56, but there is a lot of IS= Ps (33%)
    >>>>>>>> doing it wrong and using /64, which of cou= rse, we are
    >>>>>>>> explaining them that is wrong. 10% use oth= er sizes.
    >>>>>>
    >>>>>> So how comes that households can get /56s but smar= tphones
    >>>>>> no?
    >>>>>>
    >>>>>> Really there must be something there hidden.
    >>>>>>
    >>>>>> Alex
    >>>>>>
    >>>>>>>
    >>>>>>> Full details at:
    >>>>>>>
    >>>>>>>
    >>>> h= ttps://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-
    >> deployment-s
    >>>>
    >>>>
    >>>>
    >>>>
    >> urvey
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>
    >>>>>>> Saludos, Jordi
    >>>>>>>
    >>>>>>>
    >>>>>>> -----Mensaje original----- De: ipv6
    >>>>>>> <ipv6-bounces@ietf.org> en nombr= e de Mikael Abrahamsson
    >>>>>>> <swmike@swm.pp.se> Organizacin: Peop= le's Front Against
    >>>>>>> WWW Responder a: <swmike@swm.pp.se> F= echa: jueves, 2 de
    >>>>>>> marzo de 2017, 19:33 Para: Alexandre Petrescu<= br class=3D"gmail_msg"> >>>>>>> <alexandre.petrescu@gmail.com> CC: <ipv6@ietf.org>
    >>>>>>> Asunto: Re: Objection to
    >>>>>>> draft-ietf-6man-rfc4291bis-07.txt
    >>>>>>>
    >>>>>>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote:<= br class=3D"gmail_msg"> >>>>>>>
    >>>>>>>> YEs yes, but how much of that /44 is cover= ing the
    >>>>>>>> end-users and how much is reserved for
    >>>>>>>> interconnnections?
    >>>>>>>
    >>>>>>> Nothing. It's /44 to the GGSN/SPGW.
    >>>>>>>
    >>>>>>>> Ah great, but I guess few cellular operato= rs (if any?)
    >>>>>>>>=C2=A0 are LIRs. Or maybe that's true a= nd I didnt know.
    >>>>>>>
    >>>>>>> You don't know.
    >>>>>>>
    >>>>>>>> If all this were that simple and clearcut = - there are
    >>>>>>>> enough /64s out there - then why operators= only assign
    >>>>>>>>=C2=A0 one per one end user?
    >>>>>>>
    >>>>>>> Because DHCPv6-PD hasn't been implemented = in mobile
    >>>>>>> networks yet (that I know of). So that's a= ll they can do
    >>>>>>>=C2=A0 per 3GPP standards.
    >>>>>>>
    >>>>>>> Residential rollouts, most use /56 per custome= r.
    >>>>>>>
    >>>>>>>> From the RIRs, you can without further jus= tification
    >>>>>>>> get /48 per "site",
    >>>>>>> so if you show up to RIR and you're LIR an= d you say
    >>>>>>> "hello, I have 40 million customers and I= want to give
    >>>>>>> each customer a /48" then they'll giv= e you a /22 most
    >>>>>>> likely. You're perfectly within your right= as an operator
    >>>>>>> to deploy /48 per customer per current RIR rul= es that I
    >>>>>>> am aware of.
    >>>>>>>
    >>>>>>> -- Mikael Abrahamsson=C2=A0 =C2=A0 email: swmik= e@swm.pp.se
    >>>>>>>
    >>>>>>> ----------------------------------------------= ----------------------
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    IETF IPv6 working group mailing list ipv6@ietf.org Administrative
    >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
    >>>>>>> ----------------------------------------------= ----------------------
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    ********************************************** IPv4 is over Are
    >>>>>>> you ready for the new Internet ?
    >>>>>>> http://www.consulintel.es<= /a> The IPv6 Company
    >>>>>>>
    >>>>>>> This electronic message contains information w= hich may
    >>>>>>> be privileged or confidential. The information= is
    >>>>>>> intended to be for the use of the individual(s= ) named
    >>>>>>> above. If you are not the intended recipient b= e aware
    >>>>>>> that any disclosure, copying, distribution or = use of the
    >>>>>>> contents of this information, including attach= ed files,
    >>>>>>> is prohibited.
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>> ----------------------------------------------= ----------------------
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    IETF IPv6 working group mailing list     ipv6@ietf.org Administrative
    >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
    >>>>>>> ----------------------------------------------= ----------------------
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    --------------------------------------------------------------------
    >>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>> IETF IPv6 working group mailing list ipv6@ietf.org
    >>>>> Administrative
    >>>>>> Requests: htt= ps://www.ietf.org/mailman/listinfo/ipv6
    >>>>>> --------------------------------------------------= ------------------
    >>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>
    >>>>>>
    >>>>>>
    >>>>>>
    ********************************************** IPv4 is over Are
    >>>>>> you ready for the new Internet ? http://www.consulintel.es
    >>>>>>=C2=A0 The IPv6 Company
    >>>>>>
    >>>>>> This electronic message contains information which= may be
    >>>>>> privileged or confidential. The information is int= ended to
    >>>>>>=C2=A0 be for the use of the individual(s) named ab= ove. If you
    >>>>>> are not the intended recipient be aware that any >>>>>> disclosure, copying, distribution or use of the co= ntents
    >>>>>> of this information, including attached files, is<= br class=3D"gmail_msg"> >>>>>> prohibited.
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>> --------------------------------------------------= ------------------
    >>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>
    >>>>>>
    >>>>>>
    >>>>>>
    IETF IPv6 working group mailing list ipv6@ietf.org Administrative
    >>>>>> Requests: htt= ps://www.ietf.org/mailman/listinfo/ipv6
    >>>>>> --------------------------------------------------= ------------------
    >>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>
    >>>>>>
    >>>>>>
    >>>>>>
    --------------------------------------------------------------------
    >>>>> IETF IPv6 working group mailing list ipv6@ietf.org
    >>>>> Administrative Requests:
    >>>>> https://www.ietf.= org/mailman/listinfo/ipv6
    >>>>> ------------------------------------------------------= --------------
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>
    >>>>>
    >>>>>
    >>>>>
    ********************************************** IPv4 is over Are you
    >>>>> ready for the new Internet ? http:= //www.consulintel.es The
    >>>>> IPv6 Company
    >>>>>
    >>>>> This electronic message contains information which may= be
    >>>>> privileged or confidential. The information is intende= d to be
    >>>>> for the use of the individual(s) named above. If you a= re not
    >>>>> the intended recipient be aware that any disclosure, c= opying,
    >>>>> distribution or use of the contents of this informatio= n,
    >>>>> including attached files, is prohibited.
    >>>>>
    >>>>>
    >>>>>
    >>>>> ------------------------------------------------------= --------------
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>
    >>>>>
    >>>>>
    >>>>>
    IETF IPv6 working group mailing list ipv6@ietf.org Administrative
    >>>>> Requests: https:/= /www.ietf.org/mailman/listinfo/ipv6
    >>>>> ------------------------------------------------------= --------------
    >>>>>
    >>>>
    >>>>
    >>>>>
    >>>>>
    >>>>>
    >>
    >>>>>
    >>>>>
    >>>>>
    --------------------------------------------------------------------
    >>>> IETF IPv6 working group mailing list ipv6@ietf.org
    >>>> Administrative Requests:
    >>>> https://www.ietf.org/= mailman/listinfo/ipv6
    >>>> ----------------------------------------------------------= ----------
    >>>
    >>
    >>
    >>>>
    >>>>
    >>>>
    --------------------------------------------------------------------
    >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative<= br class=3D"gmail_msg"> >> Requests: https://www.ietf.or= g/mailman/listinfo/ipv6
    >> ------------------------------------------------------------------= --
    >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6= @ietf.org
    Administrative Requests: https://www.i= etf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --f403045f22042af9f80549d6292d-- From nobody Fri Mar 3 09:43:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61D6129507 for ; Fri, 3 Mar 2017 09:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.351 X-Spam-Level: X-Spam-Status: No, score=-5.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 32pQlDK9kj1M for ; Fri, 3 Mar 2017 09:43:32 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5535D129435 for ; Fri, 3 Mar 2017 09:43:31 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v23HhSUu027608; Fri, 3 Mar 2017 18:43:28 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 80D3020D712; Fri, 3 Mar 2017 18:43:28 +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 70F9F20D711; Fri, 3 Mar 2017 18:43:28 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23HhSuH021093; Fri, 3 Mar 2017 18:43:28 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Ca By , Mark Andrews , mohamed.boucadair@orange.com References: <20170223134026.GI5069@gir.theapt.org> <20170302153611.36506f85@envy> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> <20170302224856.E63AB65D34EC@rock.dv.isc.org> <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com> <787AE7BB302AE849A7480A190F8B933009E1BE96@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <31396f41-0f08-3677-8012-4fd54247aa76@gmail.com> From: Alexandre Petrescu Message-ID: <3f39bb3b-a401-1a1c-d610-b52a7948a98b@gmail.com> Date: Fri, 3 Mar 2017 18:43:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:43:35 -0000 Le 03/03/2017 à 17:37, Ca By a écrit : > > On Fri, Mar 3, 2017 at 2:52 AM Alexandre Petrescu > > > wrote: > > > > Le 03/03/2017 à 11:30, mohamed.boucadair@orange.com > a écrit : >> Hi Alex, >> >> >>> This is why I dont understand the cellular operators dont do >>> DHCPv6-PD. And I guess it is so because they are told it's >>> sufficient to run the 64share INFORMATIONAL RFC. >> >> This is a chicken-and-egg problem: you need both the cellular >> device and the network side to support prefix delegation + prefix >> exclude option, > > How can that vicious circle be broken? > > > Money. Prior to giving money, investors want to see a proof-of-concept. We cant make a proof-of-concept with a real cellular operator because no-one delivers PD. > This is not a 3GPP release issue, this is a money backing the > deployment cost. And, despite the cost of free software being $0, my > ipv6 project was charged nearly a million dollars in QA cost from > adjacent business units... just as an example that nothing is free. If cellular operators are going to ask 10.000EUR each time a protocol needs deployment then we wont go far. I think they should plan differently. I think DHCPv6-PD deployment is a too key issue to just put a price tag on it. Just pouring money on something can also worsen the problem worse: you just say a figure and then everybody calls you with offers, some with less technical merit than others. > That said, if the v2v customer requiring PD put in an order for > 10,000+ (guessing) lines , they would likely get dhcpv6-pd. What is '10.000+' lines? Do you mean one may need 10.000EUR in order to get DHCPv6-PD deployed on a cellular operator network? > Asking for it at ietf, not likely helpful. I am talking about this at IETF because it is at IETF that many operators are present and make decisions. I saw it already. Obviously I am not asking the IETF to deploy some protocol. What I am asking at IETF is that people retire 64share from the recommendation to 3GPP. That is just a small step. > The standards and guidance all say do PD, Well no. The guidance reads 'until PD arrives do 64share'. They say 'PD is the target', they dont say 'PD is a MUST'. A 'target' is something that may take some time to reach... how long time? It's now several years... Now I want them to say 'dont do 64share'. > now you just need $ But the community of deployers of vehicular network devices _already_ pays money under the form of subscriptions. And that's huge money during years, strongly backed alliances, much more than just 10.000EUR. Isn't it that these cellular operators may be greedy when asking for more and more money in order to deploy a particular protocol? I would rather ask these operators: What's the technical difficulty of deploying DHCPv6-PD? Is it difficulty to re-visit IPv6 addressing plans? (presumably planned for one /64 per Host would now have to do more). Is it billing issue? Is it fear of too much traffic? Security? Is it the 3GPP recommendation of using 64share instead of DHCPv6-PD? Alex > I have some smartphone and other M2M modules here on which we could > try a few things. What would operator expect to hear from this > smartphone? > > Is the ISC DHCPv6-PD Client messages enough? > > Does operator also need 'prefix exclude'? Mandatory? > > Is the ISC DHCPv6-PD implementing 'prefix exclude'? > >> but while waiting for that to happen /64 share is your solution. > > Operator should understand that /64 share is impossible to use in > concrete settings like vehicular networks, road-side units, and > similar. > >> Below what you can read in RFC7849: > > If I read it I will certainly suggest improvements to it. It should > reflect reality. > >> ===== L_REC#1: For deployments that require that the same /64 >> prefix be shared, the cellular device should support [RFC7278] to >> enable sharing a /64 prefix between the LAN and the WAN >> interfaces. The WAN interface is the one towards the Gateway GPRS >> Support Node (GGSN) / Packet Data Network Gateway (PGW). >> >> Prefix Delegation (refer to L_REC#2) is the target solution for > > It's not a 'target', it is a 'now'. > >> distributing prefixes in the LAN side but, because the device may >> attach to earlier 3GPP release networks, a means to share a /64 >> prefix is also recommended [RFC7278]. > > No! That recommendation is wrong. That RFC is INFORMATIONAL and we > should stop recommending it. I has huge problems, at least with > respect to scalability. > >> [RFC7278] must be invoked only if Prefix Delegation is not in use. > > ... _and_ if it works for the network being deployed. If it does not > work, it MUST NOT be invoked. > >> L_REC#2: The cellular device must support Prefix Delegation >> capabilities [RFC3633] and must support the Prefix Exclude Option >> for DHCPv6-based Prefix Delegation as defined in [RFC6603]. > > Why is the 'prefix exclude' option a MUST? I may need to understand > that, by further reading... > >> Particularly, it must behave as a Requesting Router. > > Yes, and it is a MUST not a must. >> >> Cellular networks are more and more perceived as an alternative to >> fixed broadband networks for home IP- based services delivery; > > I agree. > >> especially with the advent of smartphones and 3GPP data dongles. > > _and_ M2M and IoT devices which are not 'dongles' (btw, 'dongles' are > only the USB dongles, there are no other kinds of dongles). > >> There is a need for an efficient mechanism to assign larger >> prefixes (other than /64s) to cellular hosts > > I fully agree. > >> so that each LAN segment can get its own /64 prefix > > _if_ that LAN is an Ethernet, yes it needs a /64. Often it is the > case. > >> and multi-link subnet issues to be avoided. > > I agree, RFC must be cited. > >> In case a prefix is delegated to a cellular host using DHCPv6, the >> cellular device will be configured with two prefixes: >> >> (1) one for the 3GPP link allocated using the Stateless Address >> Autoconfiguration (SLAAC) mechanism and >> >> (2) another one delegated for LANs acquired during the Prefix >> Delegation operation. > > I dont know what you mean by 'configured', but this second prefix may > just be in the rt table of the device (not necessarily on its > interfaces). > > How about the default route? > >> Note that the 3GPP network architecture requires both the WAN and >> the delegated prefix to be aggregatable so the subscriber can be >> identified using a single prefix. > > IT's good to avoid waste. > >> Without the Prefix Exclude Option, the delegating router (GGSN/PGW) >> will have to ensure compliance with [RFC3633] (e.g., halving the >> delegated prefix and assigning the WAN prefix out of the first half >> and the prefix to be delegated to the terminal from the second >> half). > > So 'prefix exclude' is not mandatory in order to have DHCPv6-PD > working. > >> >> Because Prefix Delegation capabilities may not be available in some >> attached networks, L_REC#1 is strongly recommended to accommodate >> early deployments. ===== > > It's wrong. We should _never_ recommend somehting we know it does > not scale. Because if we do it may get in widespread use and later > we'll have a hard time getting rid of. > > Alex > >> >> Cheers, Med >> >> >>> -----Message d'origine----- De : ipv6 >>> [mailto:ipv6-bounces@ietf.org ] De > la part de Alexandre Petrescu >>> Envoyé : vendredi 3 mars 2017 10:29 À : Mark Andrews Cc : >>> ipv6@ietf.org Objet : Re: Objection to >>> draft-ietf-6man-rfc4291bis-07.txt >>> >>> >>> >>> Le 02/03/2017 à 23:48, Mark Andrews a écrit : >>>> >>>> In message <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com > >, >>>> Alexandre Petrescu writes: >>>>> Le 02/03/2017 20:25, JORDI PALET MARTINEZ a crit : >>>>>> I understood from one of your previous emails that 3GPP >>>>>> doesnt require DHCPv6-PD. >>>>> >>>>> Right - if I understand correctly, it does not require >>>>> DHCPv6-PD on the UE. Maybe in the core, but not in the UE. >>>>> >>>>>> RFC6653, suggest its use, so probably we got confused >>>>>> ourselves and 3GPP is actually using it. >>>>>> >>>>>> 6rd is a different thing, because is actually IPv4 link and >>>>>> IPv6 is a tunnel, so you typically use DHCP (v4). >>>>> >>>>> I agree. >>>>> >>>>>> In IPv6-only world (including cellular), the WAN link will >>>>>> be IPv6-only instead of dual-stack. This is already >>>>>> happening. >>>>>> >>>>>> If they dont use it, I guess is the same reason why big >>>>>> vendors didnt implemented yet RDDNS >>>>> >>>>> I wonder if Windows refusing RDNSS doesn't have somehting to >>>>> do with its Teredo; and extending this logic to smartphones: >>>>> the lack of answers to DHCPv6-PD issued from the UE may have >>>>> something to do with 464xlat presence. >>>>> >>>>> Could it be that 464xlat presence on UE makes it that >>>>> DHCPv6-PD is impossible on same UE? >>>> >>>> No. They are or should be orthogonal. One is about providing >>>> IPv4 as as service. The other is about providing IPv6 address >>>> space. >>> >>> I can agree. >>> >>> With my operator I asked her once 'why not giving DHCPc6-PD to >>> smartphone' and she replied 'because now we do 464xlat on the >>> smartphone, and that is sufficient'. As such it sounds illogical >>> statement, although I guess s/he has some reasons to say so. >>> >>> But let me ask differently: maybe it's because 464xlat requires >>> some kernel version that DHCPv6-PD doestn support, or vice-versa? >>> Maybe it's because once you run 464xlat on smartphone it takes >>> control of the unique default route and DHCPv6-PD couldnt? Some >>> reason like that? >>> >>> Has one tried DHCPv6-PD software simultaneosuly with 464xlat? >>> (even knowing the cellular operator would not reply to DHCPv6 >>> Slicitations). >>> >>>>>> Cellular world is using 464XLAT, and they use DHCPv6-PD. >>>>>> Check RFC6877. >>>>> >>>>> I guess you mean cellular stations (like BS, not the User >>>>> Equipment) uses DHCPv6-PD within the fixed network. >>>> >>>> No, the UE should be using DHCPv6-PD. This is how tethered >>>> equipement should be getting IPv6 address space. >>> >>> I agree with yuo. >>> >>> This is why I dont understand the cellular operators dont do >>> DHCPv6-PD. And I guess it is so because they are told it's >>> sufficient to run the 64share INFORMATIONAL RFC. >>> >>> Are the people advising 64share to tethering-willing telecom >>> operators conscious it's non-interoperable? >>> >>> Is the 64share advice coming together with the claim there are >>> enough /64s out there? >>> >>> Alex >>> >>>>> Because cellular operator I am aware of replies to DHCPv6-PD >>>>> requests issued from an User Equipment. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Saludos, Jordi >>>>>> >>>>>> >>>>>> -----Mensaje original----- De: ipv6 > >>>>>> en nombre de Alexandre Petrescu >>>>>> > Responder a: >>>>>> > Fecha: jueves, 2 de marzo de >>>>>> 2017, 20:15 Para: > > Asunto: Re: Objection to >>>>>> draft-ietf-6man-rfc4291bis-07.txt >>>>>> >>>>>> >>>>>> >>>>>> Le 02/03/2017 20:06, JORDI PALET MARTINEZ a crit : >>>>>>> I guess because the lack of DHCPv6-PD support, as you >>>>>>> already indicated? >>>>>> >>>>>> But for deity's sake - DHCPv6-PD is available as open >>>>>> source... it's common software. Just download and install. >>>>>> The IETF Specs suggest it, and the 3GPP specs require it >>>>>> too. >>>>>> >>>>>> There must be something else making these router equipment >>>>>> manufacturers refraining from downloading and installing >>>>>> DHCPv6-PD. >>>>>> >>>>>>> I think majority of the households and business customers >>>>>>> get configured the CPE by means for DHCPv6-PD >>>>>> >>>>>> AFAIK my CPE at home does not use DHCPv6-PD, but something >>>>>> based on IPv4, like 6rd. I think it's something >>>>>> developped in-house at that particular operator. >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Saludos, Jordi >>>>>>> >>>>>>> >>>>>>> -----Mensaje original----- De: ipv6 >>>>>>> > >>>>>>> en nombre de Alexandre Petrescu >>>>>>> > Responder a: >>>>>>> > Fecha: jueves, 2 de marzo de >>>>>>> 2017, 20:02 Para: > > Asunto: Re: Objection to >>>>>>> draft-ietf-6man-rfc4291bis-07.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le 02/03/2017 19:54, JORDI PALET MARTINEZ a crit : >>>>>>>> Actually, is not correct that most use /56 for >>>>>>>> residential. >>>>>>>> >>>>>>>>> From my last review of the survey, worldwide, 22% use >>>>>>>>> /48, 35% use /56, but there is a lot of ISPs (33%) >>>>>>>>> doing it wrong and using /64, which of course, we are >>>>>>>>> explaining them that is wrong. 10% use other sizes. >>>>>>> >>>>>>> So how comes that households can get /56s but smartphones >>>>>>> no? >>>>>>> >>>>>>> Really there must be something there hidden. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> >>>>>>>> Full details at: >>>>>>>> >>>>>>>> >>>>> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6- > >>>>> >>>>> >>>>> >>>>> >> deployment-s >>>>> >>>>> >>>>> >>>>> >>> urvey >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Saludos, Jordi >>>>>>>> >>>>>>>> >>>>>>>> -----Mensaje original----- De: ipv6 >>>>>>>> > >>>>>>>> en > nombre de Mikael Abrahamsson >>>>>>>> > >>>>>>>> Organizacin: > People's Front Against >>>>>>>> WWW Responder a: > Fecha: jueves, 2 de >>>>>>>> marzo de 2017, 19:33 Para: Alexandre Petrescu >>>>>>>> > CC: > >>>>>>>> Asunto: Re: Objection to >>>>>>>> draft-ietf-6man-rfc4291bis-07.txt >>>>>>>> >>>>>>>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote: >>>>>>>> >>>>>>>>> YEs yes, but how much of that /44 is covering the >>>>>>>>> end-users and how much is reserved for >>>>>>>>> interconnnections? >>>>>>>> >>>>>>>> Nothing. It's /44 to the GGSN/SPGW. >>>>>>>> >>>>>>>>> Ah great, but I guess few cellular operators (if >>>>>>>>> any?) are LIRs. Or maybe that's true and I didnt >>>>>>>>> know. >>>>>>>> >>>>>>>> You don't know. >>>>>>>> >>>>>>>>> If all this were that simple and clearcut - there are >>>>>>>>> enough /64s out there - then why operators only >>>>>>>>> assign one per one end user? >>>>>>>> >>>>>>>> Because DHCPv6-PD hasn't been implemented in mobile >>>>>>>> networks yet (that I know of). So that's all they can >>>>>>>> do per 3GPP standards. >>>>>>>> >>>>>>>> Residential rollouts, most use /56 per customer. >>>>>>>> >>>>>>>>> From the RIRs, you can without further justification >>>>>>>>> get /48 per "site", >>>>>>>> so if you show up to RIR and you're LIR and you say >>>>>>>> "hello, I have 40 million customers and I want to give >>>>>>>> each customer a /48" then they'll give you a /22 most >>>>>>>> likely. You're perfectly within your right as an >>>>>>>> operator to deploy /48 per customer per current RIR >>>>>>>> rules that I am aware of. >>>>>>>> >>>>>>>> -- Mikael Abrahamsson email: swmike@swm.pp.se > >>>>>>>> >>>>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>>>>>>> > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative >>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>>>>>>> > ********************************************** IPv4 is over Are >>>>>>>> you ready for the new Internet ? >>>>>>>> http://www.consulintel.es The IPv6 Company >>>>>>>> >>>>>>>> This electronic message contains information which may >>>>>>>> be privileged or confidential. The information is >>>>>>>> intended to be for the use of the individual(s) named >>>>>>>> above. If you are not the intended recipient be aware >>>>>>>> that any disclosure, copying, distribution or use of >>>>>>>> the contents of this information, including attached >>>>>>>> files, is prohibited. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>>>>>>> > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative >>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>> >>>>>>>> >>>>>>>> >>>>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> IETF IPv6 working group mailing list ipv6@ietf.org > >>>>>> Administrative >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>>>>>> > ********************************************** IPv4 is over Are >>>>>>> you ready for the new Internet ? >>>>>>> http://www.consulintel.es The IPv6 Company >>>>>>> >>>>>>> This electronic message contains information which may be >>>>>>> privileged or confidential. The information is intended >>>>>>> to be for the use of the individual(s) named above. If >>>>>>> you are not the intended recipient be aware that any >>>>>>> disclosure, copying, distribution or use of the contents >>>>>>> of this information, including attached files, is >>>>>>> prohibited. >>>>>>> >>>>>>> >>>>>>> >>>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>>>>>> > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>>>>>> > -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list ipv6@ietf.org > >>>>>> Administrative Requests: >>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> >>>>>> >>>>>> >>>>>> > ********************************************** IPv4 is over Are you >>>>>> ready for the new Internet ? http://www.consulintel.es The >>>>>> IPv6 Company >>>>>> >>>>>> This electronic message contains information which may be >>>>>> privileged or confidential. The information is intended to >>>>>> be for the use of the individual(s) named above. If you are >>>>>> not the intended recipient be aware that any disclosure, >>>>>> copying, distribution or use of the contents of this >>>>>> information, including attached files, is prohibited. >>>>>> >>>>>> >>>>>> >>>>>> > -------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>> >>>>>> >>>>>> >>>>>> > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> > -------------------------------------------------------------------- >>>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>> >>>>>> >>>>>> >>>>>> > -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list ipv6@ietf.org > >>>>> Administrative Requests: >>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>> > -------------------------------------------------------------------- >>>> >>> >>> >>>>> >>>>> >>>>> > -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org > Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- > >>> >>> >>> >>> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Mar 3 10:12:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213FF129969 for ; Fri, 3 Mar 2017 10:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 3YaDrPr_c_B5 for ; Fri, 3 Mar 2017 10:12:23 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2959612959C for ; Fri, 3 Mar 2017 10:12:23 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id s67so46363500pgb.3 for ; Fri, 03 Mar 2017 10:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=1FeWc72M3XxalunOkKPp7qicO2Zc7JgWuUHpUkVziRw=; b=AcOXMAHCsdkkqpNgasXISEr+t/wx4pJZu4Tb2UtdwCPBba/WXSDVw0qD9+d8Ht8n7s KSwCcB4QZusnnqM0lZ7zPXJ7iBIjylWyZ5XvnaDnQh5FdHlTgqPEmF7rRpdxuOy6lam7 kzQDvR8Fmmk7bWScwc0JZdz8b268czvJA6PZ/g0IZktCCUNvnUFhP39i6JP1gScMvteJ M0+m2KoQytexxK//0/PYOTao2zQWC8euJVZUn5iEg3jG3WNGuLO7wPuNjrj8w4Ids2Sm D1SBiLABd/moVgbwgZrcuJ11DFvNHEfF80z7SWj2qUkIe0y08qYc9ClYtouYKI19u4Iy 4fIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=1FeWc72M3XxalunOkKPp7qicO2Zc7JgWuUHpUkVziRw=; b=MGUru2jshuTbZHBWKR3Gqwcwg7gN2WfCKkqmhORuzovVaVDDY+MZ1ajJZFl3Bgc9LP BAEZlYzh5IvV0ZurFZ5xLUxaGcDsD67zphI37Tf/5uy2qf8atdHZwUw0ZWeDxN9/9oAC bPUPPFJLGR0mM8mS1yCAMVCOLjxjs+UfnJD+LugvoIVq4GlJYWdf3Oao2qBMJthMj7Ex ufSF7F50LPbFAIqZ23Pmi5waJ5QPi9mKl9kkW+yCUu5pd4ga8BdlXxvqJ1XacSL9sMHJ 1xqdub8MlDnIQMJ0pR2/P3ZEEfM4H5uoFoNwuSW+0IhN42P7Al615Pv4PDnWc+/Bk0KE 2Eug== X-Gm-Message-State: AMke39mjaT8hTXal/PZlacm38Zfov7TdlFKZw6tLZiZNQRqng/X2gRHpBbfS1+F0aIjhoTr/ X-Received: by 10.84.179.165 with SMTP id b34mr6105316plc.147.1488564742476; Fri, 03 Mar 2017 10:12:22 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id t133sm24911835pgc.24.2017.03.03.10.12.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 10:12:21 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_CBE8E5AF-DB38-45BA-9244-2734678EEF6A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 Date: Fri, 3 Mar 2017 10:12:25 -0800 References: <96a5dfe9-0122-0f8c-5ad3-f98dc1867f25@gmail.com> <99749605-50a7-0920-9ace-2c0278efc750@gmail.com> To: 6man WG In-Reply-To: <99749605-50a7-0920-9ace-2c0278efc750@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 18:12:24 -0000 --Apple-Mail=_CBE8E5AF-DB38-45BA-9244-2734678EEF6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 3, 2017, at 02:28, Alexandre Petrescu = wrote: >=20 > So one wonders why64? One source is this EUI-64 originated at IEEE. = Then 'Modified' EUI-64 at IETF. Yet EUI-64 is no longer. It was = designed to replace 48bit MACs. It did not succeed: we dont see = 'EUI-64' on Ethernet-based devices, we continue to see 48bit MAC = addresses even on non-Ethernet devices. But we hear about EUI-128, = which would obviously couldnt work with IPv6. IEEE 802.15.4 is not remotely dead, and it uses EUI-64, not EUI-48. --james woodyatt > --Apple-Mail=_CBE8E5AF-DB38-45BA-9244-2734678EEF6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Mar 3, 2017, at 02:28, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

    So one wonders why64?  One source is this = EUI-64 originated at IEEE. Then 'Modified' EUI-64 at IETF.  Yet = EUI-64 is no longer. It was designed to replace 48bit MACs.  It did = not succeed: we dont see 'EUI-64' on Ethernet-based devices, we continue = to see 48bit MAC addresses even on non-Ethernet devices.  But we = hear about EUI-128, which would obviously couldnt work with = IPv6.

    IEEE 802.15.4 is not remotely dead, and = it uses EUI-64, not EUI-48.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_CBE8E5AF-DB38-45BA-9244-2734678EEF6A-- From nobody Fri Mar 3 10:14:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951B31295A3 for ; Fri, 3 Mar 2017 10:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 uK9g-wW9-vsQ for ; Fri, 3 Mar 2017 10:14:07 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD50129519 for ; Fri, 3 Mar 2017 10:14:07 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v23IE5FX000693 for ; Fri, 3 Mar 2017 19:14:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3F6FB20D6ED for ; Fri, 3 Mar 2017 19:14:05 +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 2CE6D20D348 for ; Fri, 3 Mar 2017 19:14:05 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23IE49R001403 for ; Fri, 3 Mar 2017 19:14:05 +0100 Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: <96a5dfe9-0122-0f8c-5ad3-f98dc1867f25@gmail.com> <99749605-50a7-0920-9ace-2c0278efc750@gmail.com> From: Alexandre Petrescu Message-ID: <101927d0-7b76-ce96-29e4-57b63297bb9f@gmail.com> Date: Fri, 3 Mar 2017 19:14:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 18:14:08 -0000 Le 03/03/2017 à 19:12, james woodyatt a écrit : > On Mar 3, 2017, at 02:28, Alexandre Petrescu > > wrote: >> >> So one wonders why64? One source is this EUI-64 originated at IEEE. >> Then 'Modified' EUI-64 at IETF. Yet EUI-64 is no longer. It was >> designed to replace 48bit MACs. It did not succeed: we dont see >> 'EUI-64' on Ethernet-based devices, we continue to see 48bit MAC >> addresses even on non-Ethernet devices. But we hear about EUI-128, >> which would obviously couldnt work with IPv6. > > IEEE 802.15.4 is not remotely dead, and it uses EUI-64, not EUI-48. But do I see "EUI-64" printed on some 802.15.4 device? Or do I see a 48bit MAC address? I agree 802.15.4 is live and well and it is very good. Alex > > > --james woodyatt > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Mar 3 11:00:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04FB129974 for ; Fri, 3 Mar 2017 11:00:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 YvNahY33xkRP for ; Fri, 3 Mar 2017 10:59:59 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7103812998A for ; Fri, 3 Mar 2017 10:59:59 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id 25so46752093pgy.0 for ; Fri, 03 Mar 2017 10:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=rh1du2htLNPL7vZ08JjsMI3n2XTuOI7GLjqCrpEgvT8=; b=eSY1s1vZauQJhio3827/7VifmTbFfSc/DjErokVGTaBC17pr7lzVMj9NYszttN4nKF 7wKY0B17Kehq3KBK0Mgt8yuyePWHQwYhfiIOf0gMC+RIyypbOe4n0lZdWMdtPHKOTuuJ 2CyjO7hUGznFLJhB0plROj4a9Hq8Vwk2UeDl9oG1rP14nvHQQR3XxYIij9TuW/+cdN9C S5lLfI2lntugh3FBRkBqy0iBXGriau5rlrFRqHunl3WqGFxCoBTbBBDU/D/8ivP0gm/c qbXR9X49Hk00pK0e+hZFNr81t27OQN0qDp8D5xBD6LZ0hCtpN6ZE9EYBKJfHciERcdBk f2Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=rh1du2htLNPL7vZ08JjsMI3n2XTuOI7GLjqCrpEgvT8=; b=VCLWVxYBayvgL1WrbO4uzovoE9t8DQ6eSsFI/nzoBmfsPvxEqNQWoi0L6aSFU2CXhb AZQFEhvbZtm4gtLo6C6gwK1NMLRn5zR5n5P4N0PlWzdnAs8ZvZTiLq9/EKBsJLNNns7F KkJPmBf7h6Yru6+6UgFP6G4i56Rn0uDpqrGqU66R3MCWXbCgf/eRGzWHIqevfCDvDPyA IHAvezSWpAN8jP5Va9HpgJOEk+hrgHFY+3XXs45okzlyL1ZVDP2+sZ9Vz7Gakh7XwWO9 CX7cyGwWxx7EFsyicqk88gnwtrpS8VPxI/vcgIpeA1rfcXNtGKYZH0rGk99bB516Q28W HoPg== X-Gm-Message-State: AMke39ma21OK8blkqWA1pbLcWg9E6b4T7i4NBThbkytJfz7/e5P3oTyXMSNgAdCd1to8/wHc X-Received: by 10.98.9.14 with SMTP id e14mr5201499pfd.117.1488567598757; Fri, 03 Mar 2017 10:59:58 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id a90sm4344223pfg.78.2017.03.03.10.59.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 10:59:57 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_7569BCFD-F142-4B94-89A3-D9B37C283E45" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 Date: Fri, 3 Mar 2017 10:59:56 -0800 References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> To: David Farmer , 6man WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:00:00 -0000 --Apple-Mail=_7569BCFD-F142-4B94-89A3-D9B37C283E45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 2, 2017, at 17:55, David Farmer wrote: > On Thu, Mar 2, 2017 at 7:29 PM, Brian E Carpenter = > = wrote: > On 03/03/2017 13:34, Manfredi, Albert E wrote: > > From: ipv6 [mailto:ipv6-bounces@ietf.org = ] On Behalf Of David Farmer > > > >> 3. IIDs are REQUIRED to be 64 bits > > > > I think that RFC 4291 bis should not retain a constraint that has = been applied so far, out of convenience, in the earliest stages of IPv6 = deployment. >=20 > Agreed. And I think there are actually two things to say here: >=20 > 3.1. Any IPv6-over-foo spec must specify a recommended IID length. > 3.2. In the absence of such a spec, the recommended IID length is 64 = bits. >=20 > Again, that breaks no running code, and it respects the architectural > statement that prefix_length + IID_length =3D=3D 128, and the use of = CIDR > routing and variable-length subnet masks. >=20 > Brian >=20 > I'd be fine with that, but others seem to feel otherwise. Lorenzo and = James? I=E2=80=99m not sure my response to this is necessary, but since it was = invited=E2=80=A6 p1. For consistency with IPv6 Stateless Address Autoconfiguration [RFC = 4862], I don=E2=80=99t think it=E2=80=99s a good idea to require = IPv6-over-foo documents to specify IID length. Okay to state that they = MAY do so, but not that they MUST do so, and if they don=E2=80=99t then = the length is 64 bits, citing [RFC 7421]. [*] p2. Section 5.5.3 Router Advertisement Processing in RFC 4862 discusses = at length how to process the Prefix Information Option (PIO) in Router = Advertisement (RA) messages. Some details relevant to this discussion: A. "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored." B. "The length of the interface identifier is defined in a separate link-type specific document, which should also be consistent with the address architecture [RFC4291] (see = Section 2). C. "It is the responsibility of the system administrator to ensure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type. It should be noted, however, that this does not mean the advertised prefix length is meaningless. [=E2=80=A6] [It] should be safe to validate the advertised prefix length here, = in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address = autoconfiguration.=E2=80=9D p3. There is another relevant point observed in Section 3 Design Goals = of RFC 4862: A. "A large site with multiple networks and routers should not require the presence of a DHCPv6 server for address configuration. In order to generate global addresses, hosts must determine the prefixes that identify the subnets to which they attach. Routers generate periodic Router Advertisements that include options listing the set of active prefixes on a link." I think this is a pretty clear statement to general purpose host = operating system developers that Prefix Length advertised in PIO = options, even those with zero for both A and L flags, are required to be = 64 bits on all the typical link types in general use today and for the = foreseeable future, because the IID for those links is specified to be = 64 bits. Give us a new link type with a 32 bit IID, and we would then = require all the PIO to have plen=3D96. At the risk of being excessively repetitive, I will again say that I = think it=E2=80=99s important to say that subnet prefixes for networks = intended to connect general purpose hosts to the Internet are always 64 = bits in length, and they should be 64 bits in length for all other = subnets except where expressly recommended otherwise by IETF standards = actions (including IPv6-over-foo specifications). I think that=E2=80=99s = a shorter way of expressing all that stuff above. =E2=80=94 [*] As an example, consider the case of IPv6 Over IEEE 802.15.4 = [RFC4944]. For some reason, it was carefully written not to specify a = limitation on the length of the IID except for use with stateless = autoconfiguration, which expressly limits the IID to exactly 64 bits. It = then proceeds to define the LOWPAN_HC1 common compressed header = encoding, which allows for address compression provided that either A) = the IID is derived accordingly from one of the two possible forms of = IEEE 802.15.4 address it recognizes, or B) the subnet prefix is exactly = 64 bits. These compression methods apply regardless of whether SLAAC is = used or not. This gets even more squirrelly in [RFC6282] where = LOWPAN_IPHC provides compression for addresses with a 64-bit IID derived = from either the EUI-64 address or the IEEE 802.15.4 =E2=80=9Cshort=E2=80=9D= 16-bit address. --james woodyatt > --Apple-Mail=_7569BCFD-F142-4B94-89A3-D9B37C283E45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 2, 2017, at 17:55, David Farmer <farmer@umn.edu> = wrote:
    On Thu, Mar 2, 2017 at 7:29 PM, Brian E Carpenter = <brian.e.carpenter@gmail.com> wrote:
    On = 03/03/2017 13:34, Manfredi, Albert E wrote:
    > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of = David Farmer
    >
    >> 3. IIDs are REQUIRED to be 64 bits
    >
    > I think that RFC 4291 bis should not retain a constraint that has = been applied so far, out of convenience, in the earliest stages of IPv6 = deployment.

    Agreed. And I think there are actually two things to say here:

    3.1. Any IPv6-over-foo spec must specify a recommended IID length.
    3.2. In the absence of such a spec, the recommended IID length is 64 = bits.

    Again, that breaks no running code, and it respects the architectural
    statement that prefix_length + IID_length =3D=3D 128, and the use of = CIDR
    routing and variable-length subnet masks.

        Brian

    I'd be fine with that, but others seem to feel = otherwise. Lorenzo and James?

    I=E2=80= =99m not sure my response to this is necessary, but since it was = invited=E2=80=A6

    p1. For consistency = with IPv6 Stateless Address Autoconfiguration [RFC 4862], I don=E2=80=99t = think it=E2=80=99s a good idea to require IPv6-over-foo documents to = specify IID length. Okay to state that they MAY do so, but not that they = MUST do so, and if they don=E2=80=99t then the length is 64 bits, citing = [RFC 7421]. [*]

    p2. Section 5.5.3 = Router Advertisement Processing in RFC 4862 discusses at length how to = process the Prefix Information Option (PIO) in Router Advertisement (RA) = messages. Some details relevant to this discussion:

      A. "If the sum of the prefix length and = interface identifier length
          = does not equal 128 bits, the Prefix Information option MUST be
          ignored."

      B. "The length of the interface identifier = is
          defined in a separate = link-type specific document, which should
      =     also be consistent with the address architecture [RFC4291] = (see Section 2).

      C. "It is the responsibility of the system = administrator to ensure
          that = the lengths of prefixes contained in Router Advertisements
          are consistent with the length of = interface identifiers for that
          = link type. It should be noted, however, that this does not = mean
          the advertised prefix = length is meaningless.  [=E2=80=A6]
      =     [It] should be safe to validate the advertised prefix = length here, in
          order to = detect and avoid a configuration error specifying an
          invalid prefix length in the context of = address autoconfiguration.=E2=80=9D

    p3. There is another relevant point = observed in Section 3 Design Goals of RFC 4862:

      A. "A large site with multiple = networks and routers should not require
      =     the presence of a DHCPv6 server for address configuration. =  In
          order to generate = global addresses, hosts must determine the
      =     prefixes that identify the subnets to which they attach. =  Routers
          generate = periodic Router Advertisements that include options
          listing the set of active prefixes on a = link."

    I think this is a pretty = clear statement to general purpose host operating system developers that = Prefix Length advertised in PIO options, even those with zero for both A = and L flags, are required to be 64 bits on all the typical link types in = general use today and for the foreseeable future, because the IID for = those links is specified to be 64 bits. Give us a new link type with a = 32 bit IID, and we would then require all the PIO to have = plen=3D96.

    At the risk of being = excessively repetitive, I will again say that I think it=E2=80=99s = important to say that subnet prefixes for networks intended to connect = general purpose hosts to the Internet are always 64 bits in length, and = they should be 64 bits in length for all other subnets except where = expressly recommended otherwise by IETF standards actions (including = IPv6-over-foo specifications). I think that=E2=80=99s a shorter way of = expressing all that stuff above.

    =E2=80=94

    [*] = As an example, consider the case of IPv6 Over IEEE 802.15.4 [RFC4944]. = For some reason, it was carefully written not to specify a limitation on = the length of the IID except for use with stateless autoconfiguration, = which expressly limits the IID to exactly 64 bits. It then proceeds to = define the LOWPAN_HC1 common compressed header encoding, which allows = for address compression provided that either A) the IID is derived = accordingly from one of the two possible forms of IEEE 802.15.4 address = it recognizes, or B) the subnet prefix is exactly 64 bits. These = compression methods apply regardless of whether SLAAC is used or not. = This gets even more squirrelly in [RFC6282] where LOWPAN_IPHC provides = compression for addresses with a 64-bit IID derived from either the = EUI-64 address or the IEEE 802.15.4 =E2=80=9Cshort=E2=80=9D 16-bit = address.

    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_7569BCFD-F142-4B94-89A3-D9B37C283E45-- From nobody Fri Mar 3 11:03:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAAE129990 for ; Fri, 3 Mar 2017 11:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PO2chyORAfNU for ; Fri, 3 Mar 2017 11:03:18 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC9512998E for ; Fri, 3 Mar 2017 11:03:18 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id g129so7761136qkd.1 for ; Fri, 03 Mar 2017 11:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WZEPhyzLOrQkwf6N/LJIR+6+BC9+5XHVYlfQXqxP4Og=; b=UdCk8RmLfo1YdSSdAXMP/hr8kNEnNdptt97cL5SrIsPXR6GftSk3KMLA1EaMV2cgXH AN19deWCuM2g6jZRJSaJndvwNHqaUPCb6kyz1IekU3wtQ6YmEkU/gSFBFwlppMu9OYAu 9glQdvhdQXVpNnjjFTP6ePlZPHBTdymXnA/8IyrQ5xIOwIej4RNc6RtoKCVTyolXyZsO O1NV5HeFb+RRLApyWpW4vLXGZSsKaOv5Q9RWS48AmgB+GdEgkU4a+vGCwwMl3uCdrGtI O7QHzw+djQ5DnXqwFPsg5a1JOEiNomvAojUe2WcacKx330U1eHiCNojD7iBLTEwXuy99 3nrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WZEPhyzLOrQkwf6N/LJIR+6+BC9+5XHVYlfQXqxP4Og=; b=cGKCtjJKk6yPnEzFah+jCaS8kBlDIjZ/rdW4bJCQFYu0sraIXT0uCNRlsXeykd8Qsg ozRy/t7GFhE3OTgZKS+vmHLT4uWuFz7EvsN2b0IAoW/8W+Y/cDMnULtpelwC+mo3eexQ hv9uJj9UPnzcy3ySjHoEMJzViCihbNTS2cq9ocBounRYCKzFn9WO+ZYFNjURtNIawgOj C2dRaZGLdfdaXoQccgQGCTcAL30QrkRwoLjiw2pDbSmG1k1h/9s+XdK6EoX0jkdwprSj RG200nAdCUcBOaNODtBQkPoXa7izP82mhE1TyGjwPZmXY8mr1SSAzKkrFsqGtz6IZxDm s5qg== X-Gm-Message-State: AMke39mwUOgSu+NT1BndgRoedwLMjSjlOWL2jGgFAkffpzdAilfMxzQM4GSfmhWtE+yChi7Sn88UqZCqv5DpjA== X-Received: by 10.55.122.130 with SMTP id v124mr3806659qkc.19.1488567797580; Fri, 03 Mar 2017 11:03:17 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Fri, 3 Mar 2017 11:03:17 -0800 (PST) In-Reply-To: <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 3 Mar 2017 11:03:17 -0800 X-Google-Sender-Auth: gWnONoGaa5qzWlZWNxRPo9vhqdk Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:03:20 -0000 At Thu, 2 Mar 2017 13:36:44 +0100, Alexandre Petrescu wrote: > Yes, the IP-over-Eth RFC2464 mandates "An IPv6 address prefix used for > stateless autoconfiguration [ACONF] of an Ethernet interface must have a > length of 64 bits". > > It does not say which prefix of [ACONF/RFC2462] must be /64? Is it a > global prefix in RA? Or is it the link-local prefix? Both these > prefixes are relevant for the above phrase, both are mentioned in ACONF, > yet only one is present in RA (the one linux complains about when at > 65). Is the mandate cited above applying to the prefix in RA? Or to > the link-local prefix? If the mandate applies to the prefix in RA then Both, and I believe at least most implementers have had no difficulty in interpreting the spec that way. > linux is right to complain, on Ethernet. If the mandate applies only to > the LL prefix, then linux is wrong to complain about 65 in RA. If the > mandate applies to both then RFC4291 is wrong when it says fe80::/10. Like in my previous message, I don't know what "it says fe80::/10" in this context. I also don't know implementation details of the Linux kernel either, but the BSD implementation uses: - uses the 64-bit IID (as specified in RFC2464) - uses the fe80::/64 prefix (as defined in RFC4291 Section 2.5.6) - combine these to configure a link-local address fe80::<64-bit IID> as specified in Section 5.3 of RFC4862 To me there's nothing confusing or unclear here, and I suspect the Linux implementation essentially does the same thing. > RFC2464 does not say "the prefix in an RA on Ethernet MUST be 64". That's fine. The only thing this RFC is expected to say is the length of IIDs. RFC4862 defines how we use the IID to (auto)configure addresses. And RFC4862 applies it to both link-local and global. > It does not forbid that that 64bit prefix be formed by self-appending a > 0 to a /63 from the RA, or other mechanism. It's not the job of RFC2464. RFC4862 imposes the restriction through its Section 5.5.3 bullet d): If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. > Besides, RFC4862 (successor to 2462) says "If the sum of the prefix > length and interface identifier length does not equal 128 bits, the > Prefix Information option MUST be ignored." And linux does _not_ ignore > a /63 in the RA: it adds a rt entry for that /63 prefix. That's not > normal either. I suspect you're probably conflating SLAAC with on-link prefix determination. I guess that "rt entry for that /63 prefix" is to treat the /63 prefix as on-link (assuming the corresponding PIO has L bit on). If so, that's the correct behavior per RFC4861 (not 4862). It's also correct to ignore that prefix for SLAAC per RFC4862 (not 4861). Nothing wrong here. -- JINMEI, Tatuya From nobody Fri Mar 3 11:05:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56C412998E for ; Fri, 3 Mar 2017 11:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 uJuH91Y0j3t5 for ; Fri, 3 Mar 2017 11:05:22 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E3112998F for ; Fri, 3 Mar 2017 11:05:22 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id e66so17393816pfe.1 for ; Fri, 03 Mar 2017 11:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=5HzhOJDgObJG4fY5uOKjN9R7j2dwMrlg1KM+KZd+70Q=; b=FED7qVo92+9k/9ZnyHMXf80QCcf2jKTg1DrrRbk2g/ClCTm+ovktI8I4/2tBtWO7R6 c68nMZuDY8ZuCT+DWD8M+npuLaUMXRVI8WOykvHR7++Np152Gcc8KsUP/ZsQQ0ZZeN8a JWuX9DukTY+ZhxftcDCDxVaMUSMIbmHmLobRQHecCY/zFEw11hlal3RC0aiZJpwnw+Zb 5VB70/ZOy9bVA6VUMxgumWYGSQ5CsbSk1kKyE8WN5f5u0yBCcZDJI/hk/YhBS9JRP5dW ShwDXpXQ+k3R5e4vXhosVwgAHpw3z3vk14EpSuwrkgfN6z+wmq7jolnyuOgbnZ+Ut7+I +CiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=5HzhOJDgObJG4fY5uOKjN9R7j2dwMrlg1KM+KZd+70Q=; b=GQPAirsLJLm20ru0tvWN0cUO4l9E53J/hLfDA/0w/+no5i0udNedd3gWk3ZCa7eF1a QP/C6qjMnf7ugS7YSpqMkw9zdZrZizieuoWxvYFqm8+ghXrCLv84WEHB8K8rlP+jAbz7 T0l6eGiQm6BTV9v0gGhq7R5+L4tdGCWNQe/I9pTqg2wNq69UjSp3wtdpYrTEo8yz6D7s EnTjdY4A7lE+EGy2JNIwywZPv3ackn0lxxvMvB76nZRp7UJDNuJd2RCY1E2p1wCUHpsC c5WFKMipHLFDecBVQAXyOFvwf5GQ15sbXjk2X40TjIfXfGDhlnu1oht+lxKDoIAiOPRC kD0g== X-Gm-Message-State: AMke39mpbXX/1BVYKs5S4Y0rDl/TwLTdDHburVGQmt8OVYcF1BXRTu5k+KWC5C7oEud6cQ9J X-Received: by 10.99.171.75 with SMTP id k11mr5226514pgp.16.1488567922247; Fri, 03 Mar 2017 11:05:22 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id h17sm24844194pfh.62.2017.03.03.11.05.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 11:05:21 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_119AFB0C-BF8F-485C-AD1F-9C0CD2DFFED6" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 Date: Fri, 3 Mar 2017 11:05:20 -0800 References: <96a5dfe9-0122-0f8c-5ad3-f98dc1867f25@gmail.com> <99749605-50a7-0920-9ace-2c0278efc750@gmail.com> <101927d0-7b76-ce96-29e4-57b63297bb9f@gmail.com> To: Alexandre Petrescu , 6man WG In-Reply-To: <101927d0-7b76-ce96-29e4-57b63297bb9f@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:05:23 -0000 --Apple-Mail=_119AFB0C-BF8F-485C-AD1F-9C0CD2DFFED6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 3, 2017, at 10:14, Alexandre Petrescu = wrote: > Le 03/03/2017 =C3=A0 19:12, james woodyatt a =C3=A9crit : >> On Mar 3, 2017, at 02:28, Alexandre Petrescu >> > = wrote: >>>=20 >>> So one wonders why64? One source is this EUI-64 originated at IEEE. >>> Then 'Modified' EUI-64 at IETF. Yet EUI-64 is no longer. It was >>> designed to replace 48bit MACs. It did not succeed: we dont see >>> 'EUI-64' on Ethernet-based devices, we continue to see 48bit MAC >>> addresses even on non-Ethernet devices. But we hear about EUI-128, >>> which would obviously couldnt work with IPv6. >>=20 >> IEEE 802.15.4 is not remotely dead, and it uses EUI-64, not EUI-48. >=20 > But do I see "EUI-64" printed on some 802.15.4 device? Or do I see a = 48bit MAC address? The MAC address printed on IEEE 802.15.4 devices are 64 bits not 48 = bits. --james woodyatt > --Apple-Mail=_119AFB0C-BF8F-485C-AD1F-9C0CD2DFFED6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 3, 2017, at 10:14, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
    Le 03/03/2017 =C3=A0 = 19:12, james woodyatt a =C3=A9crit :
    On Mar 3, 2017, at = 02:28, Alexandre Petrescu
    <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:

    So one = wonders why64?  One source is this EUI-64 originated at IEEE.
    Then 'Modified' EUI-64 at IETF.  Yet EUI-64 is no = longer. It was
    designed to replace 48bit MACs.  It = did not succeed: we dont see
    'EUI-64' on Ethernet-based = devices, we continue to see 48bit MAC
    addresses even on = non-Ethernet devices.  But we hear about EUI-128,
    which= would obviously couldnt work with IPv6.

    IEEE 802.15.4 is not remotely dead, and it uses EUI-64, not = EUI-48.

    But do I see "EUI-64" = printed on some 802.15.4 device?  Or do I see a 48bit MAC = address?

    The MAC address printed on IEEE = 802.15.4 devices are 64 bits not 48 bits.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_119AFB0C-BF8F-485C-AD1F-9C0CD2DFFED6-- From nobody Fri Mar 3 11:14:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDD91295C5 for ; Fri, 3 Mar 2017 11:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 onYTdDYHqgPI for ; Fri, 3 Mar 2017 11:14:02 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAC31204D9 for ; Fri, 3 Mar 2017 11:14:01 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id v125so12262804qkh.2 for ; Fri, 03 Mar 2017 11:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lC8IRVDxHVwvb8TSuV/PTVRBaj15EQZOt2wVKexNFtg=; b=dHOyQf8fqtTgVnR9LGZW+MFxmww+sIzBaTd3Fap1HaAmU7l72p/j6F5yNzUXnrH1uY J3CSV6qvIpwJNYxhHP/BfEoaSNjh6uaXH1iznFXobj9Ofj7CxaoHmikY5kDDEOx6bNGO KPqsFMfDleRn63EEEgY9IGIFDqoslc0k1Io+7Pk715QLVaTC7mUq4ll+kMzLXlvyf/MW o2Ou/sUxWSK/M4rTYFd/mhkp/vhOcag5cSU6hc+vC/fGeqm47kMmJ+qcRZsAKkS8gMJ5 LXvlfw5LvUs5WKuiMMMQ6OChdfYF4gDAllqgrN8PGCAKxbxHM3dtzT7cWktoN0auhtrH SkvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lC8IRVDxHVwvb8TSuV/PTVRBaj15EQZOt2wVKexNFtg=; b=j8pWeM1MkfwSbWhvG+oFwAkfnu3fhlOnk6SgbYd72G63Gb/9wIk9GmOj2pbGfzBGcY KZScqp3DUMcpRAWuhjpj0haHXZCQzvmhy4nzdigGHuJVURQyoR05mDjbM9H/Jwc4R0Yl npPvnrt95ZmkD9k8vYYEZhkYrqMVzhDJz9wBwbX4S0TxvW9Q9snRV/L7TNnQDb/iXFH2 G3LlUOplHUMzlUtemogm1+Z2p681fm43U8ildtxj2coXB6uZTJ8Xm234d3H0uOxqngAq BimEf7WID2iV59du76gfIYdZj1fxiqL+QkfTMCahV0Wxh8aJtKGB7buSjrOG7ngbVMl5 7Cfw== X-Gm-Message-State: AMke39kkkVu7Nd8JMLM+aMPr0E+SKK3iFRmEwpNgk9vaI0rBFmtpm13GxqQhYlA6UG0mB3tbYWTmVUwRrasbeg== X-Received: by 10.200.56.48 with SMTP id q45mr4501860qtb.220.1488568440934; Fri, 03 Mar 2017 11:14:00 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Fri, 3 Mar 2017 11:14:00 -0800 (PST) In-Reply-To: <0bab257c-878e-3a29-70e5-65f3367553c7@gmail.com> References: <20170223134026.GI5069@gir.theapt.org> <58AF726A.3040302@foobar.org> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <0bab257c-878e-3a29-70e5-65f3367553c7@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 3 Mar 2017 11:14:00 -0800 X-Google-Sender-Auth: O7bla3tS1BHEq7PTS5rxPG8VyWg Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:14:03 -0000 At Fri, 3 Mar 2017 10:58:59 +0100, Alexandre Petrescu wrote: > > but BSD variants use a 64-bit IID to configure (e.g) an ethernet > > interface with a link-local address, as specified in RFC4862 and > > RFC2464. > > > > They also only recognize addresses that match fe80::/64 as on-link: > > When you say 'recognize' you mean by using the below macro? No. I meant it wouldn't consider a destination address that matches fe80::/10 but not fe80::/64 to be on-link for any of its local links. > If so, it means BSD uses a 10bit mask to recognise a LL, but uses a > 64bit mask to generate an LL. Maybe it is prudent enough. > > BUt it may not be correct. The right way would be to use precisely same > generation and recognition masks. > > Otherwise there can be risks of incompatibility, address space waste, > and probably others. The BSD implementation doesn't (auto)generate a link-local address that does not match fe80::/64. It also doesn't send a packet to a destination that matches fe80::/10 but not fe80::/64 to outside of the node. So I don't see any possibility of incompatibility, at least in practice. You may not *like* that implementation, but to me, it's merely a matter of taste, not about correctness. > > But it has nothing to do with the length of IIDs. > > Well, if the length of the IID is 64, and the fe80::/10 recognition is > hardcoded at 10, then what does BSD put between position 10 and 64 when > trying to recognise an LL address it has just generated? zero, as specified in RFC4291 and RFC4862 (btw I don't understand what you mean by "when trying to recognise an LL address it has just generated" in this context). -- JINMEI, Tatuya From nobody Fri Mar 3 11:43:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDF11295E8 for ; Fri, 3 Mar 2017 11:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fundacionsadosky.org.ar 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 R1gC35AktHlJ for ; Fri, 3 Mar 2017 11:43:05 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CF4129593 for ; Fri, 3 Mar 2017 11:43:05 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id 1so74048025qkl.3 for ; Fri, 03 Mar 2017 11:43:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fundacionsadosky.org.ar; s=google; h=subject:references:from:to:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ugXKDjyeG9jiOZLtCI77qKOHF0mA2/HQO9mlZst4IQ4=; b=CxjIlJJznV2s4PDfSs8eb2KC/jDtTPKvfERc5wyQzXClyTD4tVFu4qYDudMt8IrLWA zbO7m0wgClf1ZZRaL2PrryC5h25icJMVaMYshP5EhuHN+N8e9RRtYl2hzcA3c/wLE/LF Y7qi0KfszQmiUsnTh1yxoWBtauTM01dmuOvo4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ugXKDjyeG9jiOZLtCI77qKOHF0mA2/HQO9mlZst4IQ4=; b=FfbdIfFrY5VMIsHY1zDl5JmPWREPRSuoJb2V+su4diA+OG51Nifpbn/4c2cR80IPT6 zxhoT7chR+IEzSxV5syoBQsA2DcXqwbA0CLy18bPDdZuQST5qe9Zw1k4G9tHvopWiCyY G/bIP0UppuBXanTvgPhDXvY2C7jg6fFcOeizwDhdp3w/yfllDPhIdPQCJ/nHg2eHKc4A PzlETz77z9hL2YBWDzltnDUk9jh/t9BIMEQwTuTuaR6+V4XvK7qE+V1tGjIhv+XK/kXH P2Vx927Kned2cD63Wr/PwSnTO4wdYw4ZvveGPobov6heuh0z2v91GqmP1c9gyC6WIn2S d1tw== X-Gm-Message-State: AMke39mYBYHhnf0O1MbxO/FOVeM9PbgEJgtX3Rb89Ig9gVM/SjLECL/YZrCWgaPzaUN/yQ== X-Received: by 10.237.63.39 with SMTP id p36mr4151790qtf.187.1488570183983; Fri, 03 Mar 2017 11:43:03 -0800 (PST) Received: from [192.168.100.103] ([186.158.218.178]) by smtp.googlemail.com with ESMTPSA id 29sm8228147qtn.51.2017.03.03.11.43.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 11:43:02 -0800 (PST) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 References: From: =?UTF-8?Q?Iv=c3=a1n_Arce?= To: 6man WG Organization: =?UTF-8?Q?Fundaci=c3=b3n_Dr._Manuel_Sadosky?= Message-ID: <8a23ae5e-1d75-4fa7-0be0-461d0d456c94@fundacionsadosky.org.ar> Date: Fri, 3 Mar 2017 16:43:00 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Lightning/4.7.7 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:43:07 -0000 Hello El 2/3/17 a las 22:49, David Farmer escribió: > > However, if a provider only delegates a /64, this new text ensures that > prefix could be further subnetted down below /64 using manual config or > possibly DHCPv6. This is NOT RECOMMENDED, /64 subnets are RECOMMENDED > and RFC6177 clearly RECOMMENDS sites be allow more than one /64 subnet. > > > > 3. IIDs are REQUIRED to be 64 bits > > I thought this interminable last call was specifically because many > of us object to this idea. With those exceptions such as SLAAC on > Ethernet. Or maybe IIDs should not be longer than 64 bits? > > > Variable length IIDs are a BIG CHANGE and it will break current code, > I'm not sure that is a really good idea. Is there data about that? Any specifics? Which/whose code? What is the scope of the alleged problem? A host OS implementor (OpenBSD) had said on this list that they will NOT accept /64 as fixed prefix len mandated in a Internet Standard. Some people on the list say allowing variable length prefix len will "break existing running code" while others say the exact opposite. There can't be a rational discussion about this without actual data. An alternative is to drop the entire discussion on the basis of a provable argument such as "it will break existing code" and move to a discussion where arguments for and against are just analyzed in abstract or where personal preferences, opinions and interests are stated as such. -ivan -- Iván Arce Director del Programa STIC Fundación Dr. Manuel Sadosky http://www.fundacionsadosky.org.ar TE: (+54-11) 4328-5164 GPG fingerprint: 4D97 3003 76C9 9DA4 7209 7982 0A1D 10BE CEA9 1B6E From nobody Fri Mar 3 12:42:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C92129622 for ; Fri, 3 Mar 2017 12:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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_tqrTL_zVf0 for ; Fri, 3 Mar 2017 12:42:44 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24A812961E for ; Fri, 3 Mar 2017 12:42:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v23Kgi5V065031; Fri, 3 Mar 2017 13:42:44 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v23KgYx3064958 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 3 Mar 2017 13:42:34 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Mar 2017 12:42:34 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 3 Mar 2017 12:42:34 -0800 From: "Manfredi, Albert E" To: james woodyatt , 6man WG Subject: RE: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Topic: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Index: AQHSlFBZc0GC3/s6VkejKSh9uOtZ66GDjGtw Date: Fri, 3 Mar 2017 20:42:34 +0000 Message-ID: <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:42:46 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGph bWVzIHdvb2R5YXR0DQoNCj4gcDEuIEZvciBjb25zaXN0ZW5jeSB3aXRoIElQdjYgU3RhdGVsZXNz IEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24NCj4gW1JGQyA0ODYyXSwgSSBkb27igJl0IHRoaW5r IGl04oCZcyBhIGdvb2QgaWRlYSB0byByZXF1aXJlIElQdjYtb3Zlci1mb28NCj4gZG9jdW1lbnRz IHRvIHNwZWNpZnkgSUlEIGxlbmd0aC4gT2theSB0byBzdGF0ZSB0aGF0IHRoZXkgTUFZIGRvIHNv LA0KPiBidXQgbm90IHRoYXQgdGhleSBNVVNUIGRvIHNvLCBhbmQgaWYgdGhleSBkb27igJl0IHRo ZW4gdGhlIGxlbmd0aCBpcyA2NA0KPiBiaXRzLCBjaXRpbmcgW1JGQyA3NDIxXS4gWypdDQoNCkkn bSBva2F5IHdpdGggc2F5aW5nIHRoYXQgU0xBQUMgc2hvdWxkIGJ5IGRlZmF1bHQgYXNzdW1lIDY0 LWJpdCBJSURzLCBhdCBsZWFzdCBvdmVyIEV0aGVybmV0IGFuZCBzb21lIG90aGVyIGxpbmsgbGF5 ZXJzLCBpbiB0b2RheSdzIHJlYWxpdHkuDQoNCj4gcDIuIFNlY3Rpb24gNS41LjMgUm91dGVyIEFk dmVydGlzZW1lbnQgUHJvY2Vzc2luZyBpbiBSRkMgNDg2MiBkaXNjdXNzZXMNCj4gYXQgbGVuZ3Ro IGhvdyB0byBwcm9jZXNzIHRoZSBQcmVmaXggSW5mb3JtYXRpb24gT3B0aW9uIChQSU8pIGluIFJv dXRlcg0KPiBBZHZlcnRpc2VtZW50IChSQSkgbWVzc2FnZXMuIFNvbWUgZGV0YWlscyByZWxldmFu dCB0byB0aGlzIGRpc2N1c3Npb246DQoNCsKgIEEuICJJZiB0aGUgc3VtIG9mIHRoZSBwcmVmaXgg bGVuZ3RoIGFuZCBpbnRlcmZhY2UgaWRlbnRpZmllciBsZW5ndGgNCsKgIMKgIMKgIGRvZXMgbm90 IGVxdWFsIDEyOCBiaXRzLCB0aGUgUHJlZml4IEluZm9ybWF0aW9uIG9wdGlvbiBNVVNUIGJlDQrC oCDCoCDCoCBpZ25vcmVkLiINCg0KwqAgQi4gIlRoZSBsZW5ndGggb2YgdGhlIGludGVyZmFjZSBp ZGVudGlmaWVyIGlzDQrCoCDCoCDCoCBkZWZpbmVkIGluIGEgc2VwYXJhdGUgbGluay10eXBlIHNw ZWNpZmljIGRvY3VtZW50LCB3aGljaCBzaG91bGQNCsKgIMKgIMKgIGFsc28gYmUgY29uc2lzdGVu dCB3aXRoIHRoZSBhZGRyZXNzIGFyY2hpdGVjdHVyZSBbUkZDNDI5MV0gKHNlZSBTZWN0aW9uIDIp Lg0KDQrCoCBDLiAiSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBzeXN0ZW0gYWRtaW5p c3RyYXRvciB0byBlbnN1cmUNCsKgIMKgIMKgIHRoYXQgdGhlIGxlbmd0aHMgb2YgcHJlZml4ZXMg Y29udGFpbmVkIGluIFJvdXRlciBBZHZlcnRpc2VtZW50cw0KwqAgwqAgwqAgYXJlIGNvbnNpc3Rl bnQgd2l0aCB0aGUgbGVuZ3RoIG9mIGludGVyZmFjZSBpZGVudGlmaWVycyBmb3IgdGhhdA0KwqAg wqAgwqAgbGluayB0eXBlLiBJdCBzaG91bGQgYmUgbm90ZWQsIGhvd2V2ZXIsIHRoYXQgdGhpcyBk b2VzIG5vdCBtZWFuDQrCoCDCoCDCoCB0aGUgYWR2ZXJ0aXNlZCBwcmVmaXggbGVuZ3RoIGlzIG1l YW5pbmdsZXNzLiDCoFvigKZdDQrCoCDCoCDCoCBbSXRdIHNob3VsZCBiZSBzYWZlIHRvIHZhbGlk YXRlIHRoZSBhZHZlcnRpc2VkIHByZWZpeCBsZW5ndGggaGVyZSwgaW4NCsKgIMKgIMKgIG9yZGVy IHRvIGRldGVjdCBhbmQgYXZvaWQgYSBjb25maWd1cmF0aW9uIGVycm9yIHNwZWNpZnlpbmcgYW4N CsKgIMKgIMKgIGludmFsaWQgcHJlZml4IGxlbmd0aCBpbiB0aGUgY29udGV4dCBvZiBhZGRyZXNz IGF1dG9jb25maWd1cmF0aW9uLuKAnQ0KDQpPa2F5LCBub3RoaW5nIGhlcmUgc3VnZ2VzdHMgdGhh dCA2NC1iaXQgSUlEcyBzaG91bGQgYmUgbWFuZGF0b3J5LiBNYXR0ZXIgb2YgZmFjdCwgUkZDIDQ4 NjIgc2F5cyBleHBsaWNpdGx5LA0KDQogICAgICBOb3RlIHRoYXQgYSBmdXR1cmUgcmV2aXNpb24g b2YgdGhlIGFkZHJlc3MgYXJjaGl0ZWN0dXJlIFtSRkM0MjkxXQ0KICAgICAgYW5kIGEgZnV0dXJl IGxpbmstdHlwZS1zcGVjaWZpYyBkb2N1bWVudCwgd2hpY2ggd2lsbCBzdGlsbCBiZQ0KICAgICAg Y29uc2lzdGVudCB3aXRoIGVhY2ggb3RoZXIsIGNvdWxkIHBvdGVudGlhbGx5IGFsbG93IGZvciBh bg0KICAgICAgaW50ZXJmYWNlIGlkZW50aWZpZXIgb2YgbGVuZ3RoIG90aGVyIHRoYW4gdGhlIHZh bHVlIGRlZmluZWQgaW4gdGhlDQogICAgICBjdXJyZW50IGRvY3VtZW50cy4gIFRodXMsIGFuIGlt cGxlbWVudGF0aW9uIHNob3VsZCBub3QgYXNzdW1lIGENCiAgICAgIHBhcnRpY3VsYXIgY29uc3Rh bnQuICBSYXRoZXIsIGl0IHNob3VsZCBleHBlY3QgYW55IGxlbmd0aHMgb2YNCiAgICAgIGludGVy ZmFjZSBpZGVudGlmaWVycy4NCg0KQW5kIHdlIGFyZSBqdXN0IG5vdyBkaXNjdXNzaW5nIHN1Y2gg YW4gUkZDIDQyOTEgcmV2LiBTYXlzIHF1aXRlIGNsZWFybHkgaGVyZSB0byBub3QgYXNzdW1lIDY0 IGJpdCBJSUQgdG8gYmUgYSBjb25zdGFudC4NCg0KPiBwMy4gVGhlcmUgaXMgYW5vdGhlciByZWxl dmFudCBwb2ludCBvYnNlcnZlZCBpbiBTZWN0aW9uIDMgRGVzaWduIEdvYWxzIG9mIFJGQyA0ODYy Og0KDQrCoCBBLiAiQSBsYXJnZSBzaXRlIHdpdGggbXVsdGlwbGUgbmV0d29ya3MgYW5kIHJvdXRl cnMgc2hvdWxkIG5vdCByZXF1aXJlDQrCoCDCoCDCoCB0aGUgcHJlc2VuY2Ugb2YgYSBESENQdjYg c2VydmVyIGZvciBhZGRyZXNzIGNvbmZpZ3VyYXRpb24uIMKgSW4NCsKgIMKgIMKgIG9yZGVyIHRv IGdlbmVyYXRlIGdsb2JhbCBhZGRyZXNzZXMsIGhvc3RzIG11c3QgZGV0ZXJtaW5lIHRoZQ0KwqAg wqAgwqAgcHJlZml4ZXMgdGhhdCBpZGVudGlmeSB0aGUgc3VibmV0cyB0byB3aGljaCB0aGV5IGF0 dGFjaC4gwqBSb3V0ZXJzDQrCoCDCoCDCoCBnZW5lcmF0ZSBwZXJpb2RpYyBSb3V0ZXIgQWR2ZXJ0 aXNlbWVudHMgdGhhdCBpbmNsdWRlIG9wdGlvbnMNCsKgIMKgIMKgIGxpc3RpbmcgdGhlIHNldCBv ZiBhY3RpdmUgcHJlZml4ZXMgb24gYSBsaW5rLiINCg0KSSBpbnRlcnByZXQgdGhhdCB0byBzYXkg dGhhdCBnbG9iYWwgYWRkcmVzc2VzIHNob3VsZCBub3QgT05MWSBiZSBhc3NpZ25lZCB3aXRoIERI Q1B2Ni4gVGhlcmUgc2hvdWxkIGFsc28gYmUgYSBTTEFBQyBvcHRpb24gYW5kL29yLCBwcmVzdW1h Ymx5LCBzdGF0aWMgY29uZmlndXJhdGlvbi4gVGhhdCBjb21tZW50IGRvZXMgbm90IG1ha2UgYSBj YXNlIGZvciBtYW5kYXRpbmcgNjQtYml0IElJRHMuIE9ubHkgaWYgU0xBQUMgdXNlcyA2NC1iaXQg SUlEcyB3b3VsZCB0aGUgU0xBQUMtZ2VuZXJhdGVkIGdsb2JhbCBhZGRyZXNzZXMgbmVjZXNzYXJp bHkgdXNlIDY0LWJpdCBJSURzLiBSQXMgY291bGQgYmUgYWR2ZXJ0aXNpbmcgcHJlZml4ZXMgPiA2 NCwgd2hpY2ggbWF5IGJlIHVzZWQgd2l0aCBJSURzIDwgNjQgYXNzaWduZWQgYnkgREhDUHY2LCBv ciBwb3RlbnRpYWxseSBhbHNvIHdpdGggYSBub24tNjQtYml0IElJRCBTTEFBQz8NCg0KPiBJIHRo aW5rIHRoaXMgaXMgYSBwcmV0dHkgY2xlYXIgc3RhdGVtZW50IHRvIGdlbmVyYWwgcHVycG9zZSBo b3N0DQo+IG9wZXJhdGluZyBzeXN0ZW0gZGV2ZWxvcGVycyB0aGF0IFByZWZpeCBMZW5ndGggYWR2 ZXJ0aXNlZCBpbiBQSU8NCj4gb3B0aW9ucywgZXZlbiB0aG9zZSB3aXRoIHplcm8gZm9yIGJvdGgg QSBhbmQgTCBmbGFncywgYXJlIHJlcXVpcmVkIHRvDQo+IGJlIDY0IGJpdHMgb24gYWxsIHRoZSB0 eXBpY2FsIGxpbmsgdHlwZXMgaW4gZ2VuZXJhbCB1c2UgdG9kYXkgYW5kIGZvciB0aGUNCj4gZm9y ZXNlZWFibGUgZnV0dXJlLCBiZWNhdXNlIHRoZSBJSUQgZm9yIHRob3NlIGxpbmtzIGlzIHNwZWNp ZmllZCB0byBiZSA2NA0KPiBiaXRzLg0KDQpJIGRvbid0IHRoaXMgdGhpcyBpbXBsaWVkLiBQbHVz LCBSRkMgNDg2MiBpcyBvbmx5IGFib3V0IFNMQUFDLg0KDQpCZXJ0DQoNCg== From nobody Fri Mar 3 13:09:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C3612896F for ; Fri, 3 Mar 2017 13:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 FrYHYAZq-HGF for ; Fri, 3 Mar 2017 13:09:47 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8341294AE for ; Fri, 3 Mar 2017 13:09:46 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v23L9hBT028188; Fri, 3 Mar 2017 22:09:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D160920D852; Fri, 3 Mar 2017 22:09:43 +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 C385B20D7ED; Fri, 3 Mar 2017 22:09:43 +0100 (CET) Received: from [132.166.84.88] ([132.166.84.88]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23L9hYu029375; Fri, 3 Mar 2017 22:09:43 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> From: Alexandre Petrescu Message-ID: <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> Date: Fri, 3 Mar 2017 22:09:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:09:49 -0000 Le 03/03/2017 à 20:03, 神明é”哉 a écrit : > At Thu, 2 Mar 2017 13:36:44 +0100, Alexandre Petrescu > wrote: > >> Yes, the IP-over-Eth RFC2464 mandates "An IPv6 address prefix used >> for stateless autoconfiguration [ACONF] of an Ethernet interface >> must have a length of 64 bits". >> >> It does not say which prefix of [ACONF/RFC2462] must be /64? Is it >> a global prefix in RA? Or is it the link-local prefix? Both these >> prefixes are relevant for the above phrase, both are mentioned in >> ACONF, yet only one is present in RA (the one linux complains about >> when at 65). Is the mandate cited above applying to the prefix in >> RA? Or to the link-local prefix? If the mandate applies to the >> prefix in RA then > > Both, and I believe at least most implementers have had no > difficulty in interpreting the spec that way. If it is both, then it requires that the prefix used for address autoconfiguration of LL addresses to be 64bit length. But the LL prefix is fe80::/10. "fe80::/10" means it is a prefix. It does not mean it is "a mask for implementation in BSD and other OSs C macros to recognise the LL address". So, what goes between /10 and /64? Why? >> linux is right to complain, on Ethernet. If the mandate applies >> only to the LL prefix, then linux is wrong to complain about 65 in >> RA. If the mandate applies to both then RFC4291 is wrong when it >> says fe80::/10. > > Like in my previous message, I don't know what "it says fe80::/10" > in this context. I also don't know implementation details of the > Linux kernel either, but the BSD implementation uses: > > - uses the 64-bit IID (as specified in RFC2464) - uses the fe80::/64 > prefix (as defined in RFC4291 Section 2.5.6) And ignores the same document's fe80::/10. And some implementer does not appreciate that. > - combine these to configure a link-local address fe80::<64-bit IID> > as specified in Section 5.3 of RFC4862 And who tells the implementer what to put between /10 and /64? Should that be 0s? 1s? An arbitrary random mix of 0s and 1s? > To me there's nothing confusing or unclear here, and I suspect the > Linux implementation essentially does the same thing. I think you dont want to see the potential confusion because you do not ask yourself what to put between /10 and /64. I think you silently assume that should be 0s. >> RFC2464 does not say "the prefix in an RA on Ethernet MUST be 64". > > That's fine. The only thing this RFC is expected to say is the > length of IIDs. Well, let's clarify: the RFC2464 does say too that the prefix length should be. It does say it must be 64. > RFC4862 defines how we use the IID to (auto)configure addresses. And > RFC4862 applies it to both link-local and global. Yes. >> It does not forbid that that 64bit prefix be formed by >> self-appending a 0 to a /63 from the RA, or other mechanism. > > It's not the job of RFC2464. RFC4862 imposes the restriction > through its Section 5.5.3 bullet d): Well then, it should. BEcause currently RFC2464 says "An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an Ethernet interface must have a length of 64 bits". If we go by your recommendation above, then it means RFC2464 must not say that. > If the sum of the prefix length and interface identifier length does > not equal 128 bits, the Prefix Information option MUST be ignored. YEs, that's what RFC4862 says, and I agree. >> Besides, RFC4862 (successor to 2462) says "If the sum of the >> prefix length and interface identifier length does not equal 128 >> bits, the Prefix Information option MUST be ignored." And linux >> does _not_ ignore a /63 in the RA: it adds a rt entry for that /63 >> prefix. That's not normal either. > > I suspect you're probably conflating SLAAC with on-link prefix > determination. I dont conflate. > I guess that "rt entry for that /63 prefix" is to treat the /63 > prefix as on-link (assuming the corresponding PIO has L bit on). YEs. > If so, that's the correct behavior per RFC4861 (not 4862). So RFC4862 should not require the Host to ignore a received non 128 plen+IID, because RFC4861 accepts it. As such, either rfc4862 or rfc4861 should be modified to make it work together. Maybe rfc4862 should not require the Host to refuse a received plen+IID not making for 128. > It's also correct to ignore that prefix for SLAAC per RFC4862 (not > 4861). If some RFC requires the Host to ignore the PIO and some other RFC requires the Host to interpret it, and both RFCs are mandatory to implement, under the same conditions, isn't there a conflict? > Nothing wrong here. That is your view, and I respect it. Alex > > -- JINMEI, Tatuya > From nobody Fri Mar 3 13:18:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7DE129598 for ; Fri, 3 Mar 2017 13:18: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 CgKKwhvIwQvi for ; Fri, 3 Mar 2017 13:18:41 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FB321294AE for ; Fri, 3 Mar 2017 13:18:41 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 77so3453606pgc.1 for ; Fri, 03 Mar 2017 13:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EXP8vH6Dmpj8M9UIUh6hCGkgfwTYJ+/xuhiCLbnLRkI=; b=gEqMDTRkb5E0rnKxJFMrzpWIOz1CIm8Gy5sKEaEp3nygOHipS5HqGvQSU0M9XCGj3k X6AwrdHnYBvv44CO6eo6VXqvevZFCJZHMKi3GsmgkWuLKZPjh1OwG8ON0dpGRY7quLiN CLas6lBwNAS7I58Mt30AoEPHOl7L74rpgcaeBhK2mW+NAig7vxbiVei8cPaG+NrXsOAp xYum/sFaYiDpAYftlYpApbS+ZYpxDu4xJLHkUHZCnGeHd2ibuET0/WYu0xieGhNF+v09 +xqF7X1DHK8NypeCOMWxfvvkGvYrr78wv2/ELz3iQd7+iRvTP7o5YpYaIjn9v/MzbyEg k+0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EXP8vH6Dmpj8M9UIUh6hCGkgfwTYJ+/xuhiCLbnLRkI=; b=q+K23b+0WhKm4LvjAkW6jry7n38aYSsFQsEI7QD6Eb0QlfxXQDmqe33/tfP7fdgK8J MEPeP2BinKgcjq1kHFf+GkozE7UTJGuU0CRNnwVPeIAJSs5lpg+zRpm3a+09E5to5FXS Otr6YHJtgYUdZ/OlUXzr/5VTkJy+RD7N0Ay8aDOVksEyuoFYlT1RGYw4aFDgF9n9mLUM /S+PINYLVqnYOXj5V9UXf/acWTEYtBRN2v5i2j3RXUKEIiXFeOdzTJHt5XH+bpddMFK9 sXMQSCrpPD57wdGD8xDdDYseUY07hZLTn/YZPPkEtipc22oOmkhl5F3HS/0KHz1RMppe KBUQ== X-Gm-Message-State: AMke39kArXHdFjaOnPadPJUwygseicAicjbItMrYcbrOn86jB07xzZAZ+p04ipsaKx8whtQP X-Received: by 10.84.217.68 with SMTP id e4mr6968725plj.99.1488575921037; Fri, 03 Mar 2017 13:18:41 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id v186sm25249274pgv.44.2017.03.03.13.18.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 13:18:40 -0800 (PST) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_72082E09-F3B3-4A83-8389-AAE7C98586F0" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 Date: Fri, 3 Mar 2017 13:18:39 -0800 In-Reply-To: <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:18:43 -0000 --Apple-Mail=_72082E09-F3B3-4A83-8389-AAE7C98586F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 3, 2017, at 12:42, Manfredi, Albert E = wrote: >=20 > [=E2=80=A6] Okay, nothing here suggests that 64-bit IIDs should be = mandatory. [=E2=80=A6] No, but it does say that valid IID lengths are defined for link types by = their specification, and that invalid prefix lengths for a given link = type MUST be ignored=E2=80=94 and not just for stateless auto = configuration but *ALSO* for on-link determination. Shorter james: if IETF will insist that I modify my host IPv6 stack so = that, on Wi-Fi links, it will do on-link determination with prefix = lengths other than 64 bits, then I want to see that in its own draft and = not in the successor to RFC 4291. --james woodyatt > --Apple-Mail=_72082E09-F3B3-4A83-8389-AAE7C98586F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Mar 3, 2017, at 12:42, = Manfredi, Albert E <albert.e.manfredi@boeing.com> wrote:

    [=E2=80=A6] Okay, nothing here suggests that 64-bit IIDs = should be mandatory. [=E2=80=A6]

    No, = but it does say that valid IID lengths are defined for link types by = their specification, and that invalid prefix lengths for a given link = type MUST be ignored=E2=80=94 and not just for stateless auto = configuration but *ALSO* for on-link determination.

    Shorter james: if IETF will = insist that I modify my host IPv6 stack so that, on Wi-Fi links, it will = do on-link determination with prefix lengths other than 64 bits, then I = want to see that in its own draft and not in the successor to RFC = 4291.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_72082E09-F3B3-4A83-8389-AAE7C98586F0-- From nobody Fri Mar 3 14:02:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E1912963E for ; Fri, 3 Mar 2017 14:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 J_vk-ZiwcdMg for ; Fri, 3 Mar 2017 14:02:12 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817A21295CE for ; Fri, 3 Mar 2017 14:02:12 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id g129so15282976qkd.1 for ; Fri, 03 Mar 2017 14:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uT9gEqrIg7dN6w+C4TnM9CKOM/2n5nTo587ukB0KyPg=; b=nNrvFXFNo2c2nfTxwbsmP/9t5609+smc7wOLu6DAqq2tl79Jzvj5zeA8z0qWzOGzdZ R/cqWIo3JaBs1SF1w4KTIJW+C5pfRumSVqYo2+Dfb1qJ6c2SVSiIBuSPDiICyUzcmpWv Pizdw/BbBDd3thI1yar+AF4XpN4iny5P6N2Rn/WaBLxiwTKs2P5Y7/83pHG0MMP9x2eh LCgoEllipvQTnTaByyEHQBeUsIQ9/5GvksABfnoDKU6kuoMVI16bxO5jOPue5guVRyfO UmXdKj9AfSB+2EsbWhVwT4FgAZpCaLeF0oU0oD3ffw/3KjY0gGvco+SwNaToyUnGya/t Mxpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uT9gEqrIg7dN6w+C4TnM9CKOM/2n5nTo587ukB0KyPg=; b=teZC2ja3ufIM9uuRYkkxBl4ElndnYkkzAoFiGOJFqg89wZrj5xzCmowWhmOpqvkBuq XW5yTep42akKO2cZGSD//BKxNN/ErvS3/45tAdF4lIed7spX8XEl8RlW2J18iMiSP7U+ L6xKHr0Q31o8D1YvfQXo8E1CH8XhFQKsVlADKtr5WOMos1kmdHaucbvEN08HQAbzKgsW YRXsv3vWmh2SendZ5Z4FbnZdV8TcihM+MuqoJ+Z/Rr4solkdPSIzX9XHq9nvfcKmmoK1 IPIzXXxgTrq535YduCyN9Bb7WMzrhF2fZTWgKcZnKin1RSFnLSLiotE0hgBmbiXs4pli gmJg== X-Gm-Message-State: AMke39lZf8vPqu9IlbniaW3VUrBfYmLKZ6qQkFz9Id+Vo17St/9yV3O5UNU2Ai4OzK39o9xQwQ1QhJbpO1AgQQ== X-Received: by 10.55.122.130 with SMTP id v124mr4492634qkc.19.1488578531348; Fri, 03 Mar 2017 14:02:11 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Fri, 3 Mar 2017 14:02:10 -0800 (PST) In-Reply-To: <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 3 Mar 2017 14:02:10 -0800 X-Google-Sender-Auth: iyHNJMqg2OzZYK4PJa8EEUSvzg4 Message-ID: Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:02:14 -0000 At Fri, 3 Mar 2017 22:09:47 +0100, Alexandre Petrescu wrote: > > Both, and I believe at least most implementers have had no > > difficulty in interpreting the spec that way. > > If it is both, then it requires that the prefix used for address > autoconfiguration of LL addresses to be 64bit length. > > But the LL prefix is fe80::/10. > > "fe80::/10" means it is a prefix. It does not mean it is "a mask for > implementation in BSD and other OSs C macros to recognise the LL address". > > So, what goes between /10 and /64? Why? For (auto)configuring a link-local address? If so, it's all-0 bits, as defined in Section 2.5.6 of RFC4291: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ > > - uses the 64-bit IID (as specified in RFC2464) - uses the fe80::/64 > > prefix (as defined in RFC4291 Section 2.5.6) > > And ignores the same document's fe80::/10. And some implementer does > not appreciate that. I'm not sure what you mean by this here, but out of curiosity, who is that implementer and what does it actually do by not appreciating that? Auto-configuring a link-local address that does not match fe80::/64? > > - combine these to configure a link-local address fe80::<64-bit IID> > > as specified in Section 5.3 of RFC4862 > > And who tells the implementer what to put between /10 and /64? > Should that be 0s? 1s? An arbitrary random mix of 0s and 1s? 0s, as described in RFC4291 Section 2.5.6. > > To me there's nothing confusing or unclear here, and I suspect the > > Linux implementation essentially does the same thing. > > I think you dont want to see the potential confusion because you do not > ask yourself what to put between /10 and /64. I think you silently > assume that should be 0s. If "what to put between /10 and /64" is for (auto)configuring link-local addresses, yes, I assume it's 0s. But not "silently" - it's based on Section 2.5.6 of RFC4291. BTW, I do not necessarily disagree that there may be "some confusion" if one sees this: Link-Local unicast 1111111010 FE80::/10 2.5.6 (Section 2.4 of RFC4291) and this: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ (Section 2.5.6 of RFC4291) like, wondering "what if the intermediate 54 bits are non-0? should it be called a link-local address?". But, at least in terms of auto-generating link-local addresses, the specs are clear enough to me that these bits should be set to 0. That's why I always try to clarify the context is to auto-generate a link-local address in this conversation. If you want to further clear any possible confusion between the intermediate 54 bits, I wouldn't discourage you to write a "mystery of the intermediate 54 bits for fe80::/10" draft:-) > >> It does not forbid that that 64bit prefix be formed by > >> self-appending a 0 to a /63 from the RA, or other mechanism. > > > > It's not the job of RFC2464. RFC4862 imposes the restriction > > through its Section 5.5.3 bullet d): > > Well then, it should. > > BEcause currently RFC2464 says "An IPv6 address prefix used > for stateless autoconfiguration [ACONF] of an Ethernet interface > must have a length of 64 bits". > > If we go by your recommendation above, then it means RFC2464 must not > say that. I guess we're just not on the same page...trying to rephrase my point, it doesn't matter that RFC2464 "does not forbid that that 64bit prefix be formed by self-appending a 0 to a /63 from the RA", since RFC4862 forbids it anyway (by the "sum must be 128" requirement). > > I guess that "rt entry for that /63 prefix" is to treat the /63 > > prefix as on-link (assuming the corresponding PIO has L bit on). > > YEs. > > > If so, that's the correct behavior per RFC4861 (not 4862). > > So RFC4862 should not require the Host to ignore a received non 128 > plen+IID, because RFC4861 accepts it. Here I actually see conflating. RFC4862 only says the host MUST ignore such prefix *for SLAAC*. It doesn't say, for example, it should ignore the entire RA or even for that particular PIO for other purposes than SLAAC. But I admit this point may be subtle and can easily be misunderstood. RFC4862 tried to clarify that subtlety a bit in the following paragraph of that section (that was actually written by me): It is the responsibility of the system administrator to ensure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type. It should be noted, however, that this does not mean the advertised prefix length is meaningless. In fact, the advertised length has non-trivial meaning for on-link determination in [RFC4861] where the sum of the prefix length and the interface identifier length may not be equal to 128. Thus, it should be safe to validate the advertised prefix length here, in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration. but this conversation seems to suggest it's still not clear enough. > As such, either rfc4862 or rfc4861 should be modified to make it work > together. 4861 and 4862 already work together. But, we could make it even clearer that prefix length validation for on-link determination (actually there's no restriction for this) and prefix length validation for SLAAC are independent, if and when we want to update these RFCs. > Maybe rfc4862 should not require the Host to refuse a > received plen+IID not making for 128. No, it should still require that, as there's currently no defect in the spec even if it may still not be crystal clear for some. However, you have the right to propose loosening the requirement, so if you think that change is necessary, please feel free to write a draft. > > It's also correct to ignore that prefix for SLAAC per RFC4862 (not > > 4861). > > If some RFC requires the Host to ignore the PIO and some other RFC > requires the Host to interpret it, and both RFCs are mandatory to > implement, under the same conditions, isn't there a conflict? No, there's no conflict, once one understands the two types validations are independent: - RFC4861 does not impose any restriction on the prefix length in PIO for on-link determination purpose (and therefore the host is expected to accept any length of prefix for on-link determination) - RFC4862 requires the host to ignore the PIO of some particular length for the purpose of SLAAC (and therefore the host is expected to not use a prefix of "invalid length" to configure an address) Both can coexist. BSDs literally implement it. From your previous message, I guess so does Linux. I also suspect so do other major OS implementations such as Windows or Solaris, as this separation has been in fact one of common test cases in IPv6 protocol conformance test suites. -- JINMEI, Tatuya From nobody Fri Mar 3 14:05:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA16129643 for ; Fri, 3 Mar 2017 14:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bmrtktZR4gIH for ; Fri, 3 Mar 2017 14:05:34 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAEA129633 for ; Fri, 3 Mar 2017 14:05:34 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id j5so37205936pfb.2 for ; Fri, 03 Mar 2017 14:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ocEJ8K98yGzYRlu2ES6GCJqlIYoMQ3IkmVxCcwh+1N4=; b=L9xf5Xysop5GQthohRFN/5W/wvRjakLEdBr/0PekGEIsoGNsag0H25nqRrIVNoMB2P NbIULqgd/TxaUQ4VhXqVgB9vzSRnsVY8tZwhRwpBd+mWYTVxEqEuKPIX/Moq44eiTL/n g0r6iLUWlX+6URfpyVdvJfXyK+qL10tmwJaBYrhkYrMg+yqGyijA0mvbupEmaXBZSndO BEq6CwoOP1C7ovdgGFNft8+S7DVnVZAi3DQB3qsTv+sDmzfI7tOPdgjHgmzAiQKoffGz dI3neZw09yHIub22UC9KOld6BQPZBw/7bzXgwsXOQVRS0U46609n4Dgjd3bljsFw2mof dyKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ocEJ8K98yGzYRlu2ES6GCJqlIYoMQ3IkmVxCcwh+1N4=; b=EIxE8y+ic99HDQ1TtjYphFIvKAmcO/vMaazNLxdtDg2HhCdK6Ij7q5r80mCyo/+I9n zj2gSzvk/w26zXQj/CJp/cq9l6MkittXLtcVpMQwzMZazG4Gk/LH0dGdYFm/GvB3P5Mr AAQM75OXOdPJOHusXI2uheRYccyQIWw8N4llEECJZiE5AH3ld/vIwiR3wHnJAkxKsuXg Ea2R3kF/4I4zC3n6q4IlKenmeF7qJwhUjO9wYqpa1aMQ4ZPktNx39oT4A0GUvgTMlWMK 1SNh5TsF55zBthVg9sM6Ak7B5oDnUoEMEugq6PiuNAuP3bGTHISGdTNQj00Vhhul+zBO A+lA== X-Gm-Message-State: AMke39mLWDHnL9uKE1nxbuT05peNi1Lj2CCCC2KFp6dDyHBpSjbQ9fQnBvDYC8TTaFePpg== X-Received: by 10.84.228.208 with SMTP id y16mr7335346pli.168.1488578733773; Fri, 03 Mar 2017 14:05:33 -0800 (PST) Received: from ?IPv6:2406:e007:4e9f:1:28cc:dc4c:9703:6781? ([2406:e007:4e9f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i127sm9149730pfe.15.2017.03.03.14.05.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 14:05:33 -0800 (PST) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: otroan@employees.org References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <851D594B-7E32-4C40-AA89-F95E66FBF35B@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4a2aa7c0-e344-1635-4f7d-4b9bb696d86e@gmail.com> Date: Sat, 4 Mar 2017 11:05:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <851D594B-7E32-4C40-AA89-F95E66FBF35B@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:05:35 -0000 On 03/03/2017 20:46, otroan@employees.org wrote: > Brian, > > [...] > >>> I think that RFC 4291 bis should not retain a constraint that has been applied so far, out of convenience, in the earliest stages of IPv6 deployment. >> >> Agreed. And I think there are actually two things to say here: > > It is of course not done because of "convenience". > >> 3.1. Any IPv6-over-foo spec must specify a recommended IID length. > > Why? Why and how does data-link layer type influence the recommended IID length? > It made sense in the past when we created "modified EUI-64"s that were based on the data-link layer address, but why now? For out-of-the-box interoperability. No other reason that I can see. Brian > >> 3.2. In the absence of such a spec, the recommended IID length is 64 bits. >> >> Again, that breaks no running code, and it respects the architectural >> statement that prefix_length + IID_length == 128, and the use of CIDR >> routing and variable-length subnet masks. > > Cheers, > Ole > From nobody Fri Mar 3 14:30:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02EE129648 for ; Fri, 3 Mar 2017 14:30:56 -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 autolearn_force=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 HpxAsTk4eaIa for ; Fri, 3 Mar 2017 14:30:55 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id D62D9129642 for ; Fri, 3 Mar 2017 14:30:54 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cjviu-0000EYC; Fri, 3 Mar 2017 23:30:52 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Fri, 3 Mar 2017 13:18:39 -0800 ." Date: Fri, 03 Mar 2017 23:30:51 +0100 Archived-At: Cc: james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:30:57 -0000 > Shorter james: if IETF will insist that I modify my host IPv6 > stack so that, on Wi-Fi links, it will do on-link determination > with prefix lengths other than 64 bits, then I want to see that > in its own draft and not in the successor to RFC 4291. Did I miss a couple of rounds somewhere? Onlink prefixes come from PIO options in RAs with the L bit set. Since forever, these options have a prefix length field. Section 4.6.2 of RFC 4861 has this to say about prefix length: "8-bit unsigned integer. The number of leading bits "in the Prefix that are valid. The value ranges "from 0 to 128. The prefix length field provides "necessary information for on-link determination "(when combined with the L flag in the prefix "information option). It also assists with address "autoconfiguration as specified in [ADDRCONF], for "which there may be more restrictions on the prefix "length. So there are extra restriction for SLAAC, but not for use as an onlink prefix. Are you saying that your stack completely ignores that prefix length and hardcodes it to 64? From nobody Fri Mar 3 14:40:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B380129657 for ; Fri, 3 Mar 2017 14:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 8r06kfKiBbFW for ; Fri, 3 Mar 2017 14:40:07 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1052812964D for ; Fri, 3 Mar 2017 14:40:06 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v23Me4uW013196; Fri, 3 Mar 2017 23:40:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8C9C420D84B; Fri, 3 Mar 2017 23:40:04 +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 7E68020D7A2; Fri, 3 Mar 2017 23:40:04 +0100 (CET) Received: from [132.166.84.36] ([132.166.84.36]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23Me3hY023274; Fri, 3 Mar 2017 23:40:04 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <20170223134026.GI5069@gir.theapt.org> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 3 Mar 2017 23:40:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:40:09 -0000 Le 03/03/2017 à 23:02, 神明é”哉 a écrit : > At Fri, 3 Mar 2017 22:09:47 +0100, Alexandre Petrescu > wrote: > >>> Both, and I believe at least most implementers have had no >>> difficulty in interpreting the spec that way. >> >> If it is both, then it requires that the prefix used for address >> autoconfiguration of LL addresses to be 64bit length. >> >> But the LL prefix is fe80::/10. >> >> "fe80::/10" means it is a prefix. It does not mean it is "a mask >> for implementation in BSD and other OSs C macros to recognise the >> LL address". >> >> So, what goes between /10 and /64? Why? > > For (auto)configuring a link-local address? If so, it's all-0 bits, > as defined in Section 2.5.6 of RFC4291: > > | 10 | | bits | 54 bits | 64 bits > | +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ Is that figure picturing a fe80::/10 or a fe80::/64? Is the prefix extended from fe80::/10 to fe80::/64 with 0s? Or is the IID len extended from 64 to to become an IID len==108? If we stopped saying fe80::/10 then it would be clearer. But one seems to be forced to continue talking about fe80::/10. Otherwise we would never write text reading "fe80::/10". >>> - uses the 64-bit IID (as specified in RFC2464) - uses the >>> fe80::/64 prefix (as defined in RFC4291 Section 2.5.6) >> >> And ignores the same document's fe80::/10. And some implementer >> does not appreciate that. > > I'm not sure what you mean by this here, but out of curiosity, who is > that implementer and what does it actually do by not appreciating > that? Let us say that I talked to many IPv6 stack implementers and I continue to. So to answer this question there is not one person in particular that I could name, but rather the name of a few persons, and a sort of average I make from my discussions. Moreover, whenever I invoke such 3rd person, it is the very optimistic view. I avoid saying all the bad things that I heard, and I keep the good things. > Auto-configuring a link-local address that does not match fe80::/64? I mean this: is one implementer mandated to bzero() the bits from /10 to /64? Or not? Nobody is telling her so. If one writes code that generate an LL address by using a /64 mask, and then tries to make sure by recognising it by using a /10 macro, there is obviously place for false negatives or false positives. If the 4291 spec wrote everywhere that the prefix is "fe80::/64" (and never write "fe80::/10"), then the implementer would be helped a lot. She would generate and reognise by always using a 64bit mask. But that would be wrong to put in an IPv6 Addressing Archi, because 64 is too much of a limit, anyways. Additionally, when we talk about the first 3 bits 000, we dont write "::/3" because "::/3" is a prefix and there is a risk of confusion. You may remember the discussion about how to denote a default route. >>> - combine these to configure a link-local address fe80::<64-bit >>> IID> as specified in Section 5.3 of RFC4862 >> >> And who tells the implementer what to put between /10 and /64? > >> Should that be 0s? 1s? An arbitrary random mix of 0s and 1s? > > 0s, as described in RFC4291 Section 2.5.6. Are these 0s part of the plen or part of the IID? >>> To me there's nothing confusing or unclear here, and I suspect >>> the Linux implementation essentially does the same thing. >> >> I think you dont want to see the potential confusion because you >> do not ask yourself what to put between /10 and /64. I think you >> silently assume that should be 0s. > > If "what to put between /10 and /64" is for (auto)configuring > link-local addresses, yes, I assume it's 0s. But not "silently" - > it's based on Section 2.5.6 of RFC4291. That section 2.5.6 does not say whether the 0s are part of the plen or part of the IID. It is your reading, with an inclined view to make everything work, that makes it read so. But read it with an inquiring view: is the 0 part of the IID or of the plen? The section does not answer. > BTW, I do not necessarily disagree that there may be "some confusion" > if one sees this: > > Link-Local unicast 1111111010 FE80::/10 2.5.6 > (Section 2.4 of RFC4291) > > and this: > > | 10 | | bits | 54 bits | 64 bits > | +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ > (Section 2.5.6 of RFC4291) > > like, wondering "what if the intermediate 54 bits are non-0? should > it be called a link-local address?". I agree with the doubt. > But, at least in terms of auto-generating link-local addresses, the > specs are clear enough to me that these bits should be set to 0. > That's why I always try to clarify the context is to auto-generate a > link-local address in this conversation. Yes, it's clear it should be 0. But it's not clear whether the 0s are part of the plen or part of the IID. > If you want to further clear any possible confusion between the > intermediate 54 bits, I wouldn't discourage you to write a "mystery > of the intermediate 54 bits for fe80::/10" draft:-) I agree :-) When I hear this I think I need to stop talking because I cant write so many drafts as I write emails :-) But some of these things are indeed doubts there for a long time. > >>>> It does not forbid that that 64bit prefix be formed by >>>> self-appending a 0 to a /63 from the RA, or other mechanism. >>> >>> It's not the job of RFC2464. RFC4862 imposes the restriction >>> through its Section 5.5.3 bullet d): >> >> Well then, it should. >> >> BEcause currently RFC2464 says "An IPv6 address prefix used for >> stateless autoconfiguration [ACONF] of an Ethernet interface must >> have a length of 64 bits". >> >> If we go by your recommendation above, then it means RFC2464 must >> not say that. > > I guess we're just not on the same page...trying to rephrase my > point, it doesn't matter that RFC2464 "does not forbid that that > 64bit prefix be formed by self-appending a 0 to a /63 from the RA", > since RFC4862 forbids it anyway (by the "sum must be 128" > requirement). I dont understand you. I want to say this: RFC2464 does require the prefix len to be 64. >>> I guess that "rt entry for that /63 prefix" is to treat the /63 >>> prefix as on-link (assuming the corresponding PIO has L bit on). >> >> YEs. >> >>> If so, that's the correct behavior per RFC4861 (not 4862). >> >> So RFC4862 should not require the Host to ignore a received non 128 >> plen+IID, because RFC4861 accepts it. > > Here I actually see conflating. RFC4862 only says the host MUST > ignore such prefix *for SLAAC*. That emphasis is yours, it's not in the document. The document says it must ignore it. > It doesn't say, for example, it should ignore the entire RA or even > for that particular PIO for other purposes than SLAAC. It says it must ignore the PIO. IT does not say for what to ignore it. > But I admit this point may be subtle and can easily be misunderstood. > RFC4862 tried to clarify that subtlety a bit in the following > paragraph of that section (that was actually written by me): > > It is the responsibility of the system administrator to ensure that > the lengths of prefixes contained in Router Advertisements are > consistent with the length of interface identifiers for that link > type. It should be noted, however, that this does not mean the > advertised prefix length is meaningless. In fact, the advertised > length has non-trivial meaning for on-link determination in > [RFC4861] where the sum of the prefix length and the interface > identifier length may not be equal to 128. Thus, it should be safe > to validate the advertised prefix length here, in order to detect and > avoid a configuration error specifying an invalid prefix length in > the context of address autoconfiguration. It reads reasonable. But the other paragraph requiring to ignore the PIO which is non 64 is still there. These two paragraphs are contradictory. One requires consistency, the other requires 64. We are going to write the same for IPv6 Addressing Architecture? A paragraph requiring 64 and another requiring variable length? > but this conversation seems to suggest it's still not clear enough. BEcause when writing RFCs it is not by adding paragraphs that things get clearer. Clarification paragraphs may be good, but often removing some paragraphs can also improve clarity. There are readers out there, most often the programmers. They dont care about the earlier discussion involving pride and other feelings. They want consistency - things that can be easily implemented. >> As such, either rfc4862 or rfc4861 should be modified to make it >> work together. > > 4861 and 4862 already work together. But, we could make it even > clearer that prefix length validation for on-link determination > (actually there's no restriction for this) and prefix length > validation for SLAAC are independent, if and when we want to update > these RFCs. > >> Maybe rfc4862 should not require the Host to refuse a received >> plen+IID not making for 128. > > No, it should still require that, as there's currently no defect in > the spec even if it may still not be crystal clear for some. However, > you have the right to propose loosening the requirement, so if you > think that change is necessary, please feel free to write a draft. Ah this invitation. The title reads great! "Mistery of...". Thanks, but no, not at this time :-) >>> It's also correct to ignore that prefix for SLAAC per RFC4862 >>> (not 4861). >> >> If some RFC requires the Host to ignore the PIO and some other RFC >> requires the Host to interpret it, and both RFCs are mandatory to >> implement, under the same conditions, isn't there a conflict? > > No, there's no conflict, once one understands the two types > validations are independent: > > - RFC4861 does not impose any restriction on the prefix length in PIO > for on-link determination purpose (and therefore the host is expected > to accept any length of prefix for on-link determination) - RFC4862 > requires the host to ignore the PIO of some particular length for the > purpose of SLAAC (and therefore the host is expected to not use a > prefix of "invalid length" to configure an address) > > Both can coexist. BSDs literally implement it. From your previous > message, I guess so does Linux. I also suspect so do other major OS > implementations such as Windows or Solaris, as this separation has > been in fact one of common test cases in IPv6 protocol conformance > test suites. Ok. Alex > > -- JINMEI, Tatuya > From nobody Fri Mar 3 14:51:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3691293DB for ; Fri, 3 Mar 2017 14:51:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pHwo9MddkyUA for ; Fri, 3 Mar 2017 14:51:20 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBC3124281 for ; Fri, 3 Mar 2017 14:51:20 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id s67so48306763pgb.3 for ; Fri, 03 Mar 2017 14:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PQaMeHQ7M/YkOLCHmIpVwojNooH1dbBjm/6LP8rPJUs=; b=EoNwyhz5lD5ExffSvcv36tZDX0y2nI4YqNgRvRXzC50YYDpn3DIo6ov0QvUHoiD4Zv D1tPMiZ/YHkKSg/u19E/5ILCO70qP41mdWl+bhKBGRXdGxm9lkzdsfseG/Koq7GzJpQJ m+gS6Dcp5sOrShm43JOYy60+Vp9qurmnK4haO5qBig9TfCcKluRdVP3AaHdQOJ55Ygur 5xts9uPWuKasqc1juRno2tf6YNRNjn3p3Z1ky8hbTu9vZqt99+qcUMYY+4B3gTMeyf8h xEqfzXCEOktNTFxF+q0+3dUC2DT5qk8t2lhpA2PyM/7Xug9EEYJY0ftHpfDcVOlH+nGj SDvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PQaMeHQ7M/YkOLCHmIpVwojNooH1dbBjm/6LP8rPJUs=; b=hT5/odNaEacpSsDsGenPuGNWxrEqUai3U8q49m1i+cfCelaH7QYGhuFulRN446wjXu hKD4Gx8N4a5TO7HIQXlEbqE2rFprsSYkgdPufGiv9HmFCV8MGFYguVcPliETtkjkXT1+ oci9uC+SGPl0+/1ERtlZcm9mfTTl2Bhu+S8aNBYKTT3BHrsiKiiHhTAbD3ZHvGSSaTsg M/LPA4X181d2IVDDTUiKjn97olkhChrs5v3wSXePDEX3z8hZc9fwovWNVbjTP3oPMy3T gIJzJVsc6951Zqx2ghM/uwPjpz32gM31RiuMWAJSHr6aQ2cg0zNovbthg2RXpyLDlGxK 8UOQ== X-Gm-Message-State: AMke39kWYmIpFz/r3KD75ZGi1wh4wF7wvEE27aMsMZtCfBoveV5nXF4k+af7FNTptqr8jQ== X-Received: by 10.98.134.142 with SMTP id x136mr6300952pfd.64.1488581480118; Fri, 03 Mar 2017 14:51:20 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id y187sm25252545pfy.123.2017.03.03.14.51.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 14:51:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux From: Fred Baker In-Reply-To: Date: Fri, 3 Mar 2017 14:51:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com> References: <20170223134026.GI5069@gir.theapt.org> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 IPv6 List , =?utf-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:51:22 -0000 Read the fine RFC, Alexandre. We used to have something called a = site-local address, which was fe80::/10 with 54 bits that were not all = zero and a 64 bit IID, and the link-local address was fe80::/10 with 54 = bits of zero. We deprecated the site-local address, but link-local is = still fe80::/10 followed by 54 bits that are all zero. > On Mar 3, 2017, at 2:40 PM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 03/03/2017 =C3=A0 23:02, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a = =C3=A9crit : >> At Fri, 3 Mar 2017 22:09:47 +0100, Alexandre Petrescu >> wrote: >>=20 >>>> Both, and I believe at least most implementers have had no >>>> difficulty in interpreting the spec that way. >>>=20 >>> If it is both, then it requires that the prefix used for address >>> autoconfiguration of LL addresses to be 64bit length. >>>=20 >>> But the LL prefix is fe80::/10. >>>=20 >>> "fe80::/10" means it is a prefix. It does not mean it is "a mask >>> for implementation in BSD and other OSs C macros to recognise the >>> LL address". >>>=20 >>> So, what goes between /10 and /64? Why? >>=20 >> For (auto)configuring a link-local address? If so, it's all-0 bits, >> as defined in Section 2.5.6 of RFC4291: >>=20 >> | 10 | | bits | 54 bits | 64 bits >> | +----------+-------------------------+----------------------------+ >> |1111111010| 0 | interface ID | >> +----------+-------------------------+----------------------------+ >=20 > Is that figure picturing a fe80::/10 or a fe80::/64? >=20 > Is the prefix extended from fe80::/10 to fe80::/64 with 0s? Or is the > IID len extended from 64 to to become an IID len=3D=3D108? >=20 > If we stopped saying fe80::/10 then it would be clearer. >=20 > But one seems to be forced to continue talking about fe80::/10. >=20 > Otherwise we would never write text reading "fe80::/10". >=20 >>>> - uses the 64-bit IID (as specified in RFC2464) - uses the >>>> fe80::/64 prefix (as defined in RFC4291 Section 2.5.6) >>>=20 >>> And ignores the same document's fe80::/10. And some implementer >>> does not appreciate that. >>=20 >> I'm not sure what you mean by this here, but out of curiosity, who is >> that implementer and what does it actually do by not appreciating >> that? >=20 > Let us say that I talked to many IPv6 stack implementers and I = continue > to. So to answer this question there is not one person in particular > that I could name, but rather the name of a few persons, and a sort of > average I make from my discussions. >=20 > Moreover, whenever I invoke such 3rd person, it is the very optimistic > view. I avoid saying all the bad things that I heard, and I keep the > good things. >=20 >> Auto-configuring a link-local address that does not match fe80::/64? >=20 > I mean this: is one implementer mandated to bzero() the bits from /10 = to > /64? Or not? Nobody is telling her so. >=20 > If one writes code that generate an LL address by using a /64 mask, = and > then tries to make sure by recognising it by using a /10 macro, there = is > obviously place for false negatives or false positives. >=20 > If the 4291 spec wrote everywhere that the prefix is "fe80::/64" (and > never write "fe80::/10"), then the implementer would be helped a lot. > She would generate and reognise by always using a 64bit mask. >=20 > But that would be wrong to put in an IPv6 Addressing Archi, because 64 > is too much of a limit, anyways. >=20 > Additionally, when we talk about the first 3 bits 000, we dont write > "::/3" because "::/3" is a prefix and there is a risk of confusion. >=20 > You may remember the discussion about how to denote a default route. >=20 >>>> - combine these to configure a link-local address fe80::<64-bit >>>> IID> as specified in Section 5.3 of RFC4862 >>>=20 >>> And who tells the implementer what to put between /10 and /64? >>=20 >>> Should that be 0s? 1s? An arbitrary random mix of 0s and 1s? >>=20 >> 0s, as described in RFC4291 Section 2.5.6. >=20 > Are these 0s part of the plen or part of the IID? >=20 >>>> To me there's nothing confusing or unclear here, and I suspect >>>> the Linux implementation essentially does the same thing. >>>=20 >>> I think you dont want to see the potential confusion because you >>> do not ask yourself what to put between /10 and /64. I think you >>> silently assume that should be 0s. >>=20 >> If "what to put between /10 and /64" is for (auto)configuring >> link-local addresses, yes, I assume it's 0s. But not "silently" - >> it's based on Section 2.5.6 of RFC4291. >=20 > That section 2.5.6 does not say whether the 0s are part of the plen or > part of the IID. >=20 > It is your reading, with an inclined view to make everything work, = that > makes it read so. >=20 > But read it with an inquiring view: is the 0 part of the IID or of the > plen? The section does not answer. >=20 >> BTW, I do not necessarily disagree that there may be "some confusion" >> if one sees this: >>=20 >> Link-Local unicast 1111111010 FE80::/10 2.5.6 >> (Section 2.4 of RFC4291) >>=20 >> and this: >>=20 >> | 10 | | bits | 54 bits | 64 bits >> | +----------+-------------------------+----------------------------+ >> |1111111010| 0 | interface ID | >> +----------+-------------------------+----------------------------+ >> (Section 2.5.6 of RFC4291) >>=20 >> like, wondering "what if the intermediate 54 bits are non-0? should >> it be called a link-local address?". >=20 > I agree with the doubt. >=20 >> But, at least in terms of auto-generating link-local addresses, the >> specs are clear enough to me that these bits should be set to 0. >> That's why I always try to clarify the context is to auto-generate a >> link-local address in this conversation. >=20 > Yes, it's clear it should be 0. But it's not clear whether the 0s are > part of the plen or part of the IID. >=20 >> If you want to further clear any possible confusion between the >> intermediate 54 bits, I wouldn't discourage you to write a "mystery >> of the intermediate 54 bits for fe80::/10" draft:-) >=20 > I agree :-) When I hear this I think I need to stop talking because I > cant write so many drafts as I write emails :-) >=20 > But some of these things are indeed doubts there for a long time. >>=20 >>>>> It does not forbid that that 64bit prefix be formed by >>>>> self-appending a 0 to a /63 from the RA, or other mechanism. >>>>=20 >>>> It's not the job of RFC2464. RFC4862 imposes the restriction >>>> through its Section 5.5.3 bullet d): >>>=20 >>> Well then, it should. >>>=20 >>> BEcause currently RFC2464 says "An IPv6 address prefix used for >>> stateless autoconfiguration [ACONF] of an Ethernet interface must >>> have a length of 64 bits". >>>=20 >>> If we go by your recommendation above, then it means RFC2464 must >>> not say that. >>=20 >> I guess we're just not on the same page...trying to rephrase my >> point, it doesn't matter that RFC2464 "does not forbid that that >> 64bit prefix be formed by self-appending a 0 to a /63 from the RA", >> since RFC4862 forbids it anyway (by the "sum must be 128" >> requirement). >=20 > I dont understand you. >=20 > I want to say this: RFC2464 does require the prefix len to be 64. >=20 >=20 >>>> I guess that "rt entry for that /63 prefix" is to treat the /63 >>>> prefix as on-link (assuming the corresponding PIO has L bit on). >>>=20 >>> YEs. >>>=20 >>>> If so, that's the correct behavior per RFC4861 (not 4862). >>>=20 >>> So RFC4862 should not require the Host to ignore a received non 128 >>> plen+IID, because RFC4861 accepts it. >>=20 >> Here I actually see conflating. RFC4862 only says the host MUST >> ignore such prefix *for SLAAC*. >=20 > That emphasis is yours, it's not in the document. The document says = it > must ignore it. >=20 >> It doesn't say, for example, it should ignore the entire RA or even >> for that particular PIO for other purposes than SLAAC. >=20 > It says it must ignore the PIO. IT does not say for what to ignore = it. >=20 >> But I admit this point may be subtle and can easily be misunderstood. >> RFC4862 tried to clarify that subtlety a bit in the following >> paragraph of that section (that was actually written by me): >>=20 >> It is the responsibility of the system administrator to ensure that >> the lengths of prefixes contained in Router Advertisements are >> consistent with the length of interface identifiers for that link >> type. It should be noted, however, that this does not mean the >> advertised prefix length is meaningless. In fact, the advertised >> length has non-trivial meaning for on-link determination in >> [RFC4861] where the sum of the prefix length and the interface >> identifier length may not be equal to 128. Thus, it should be safe >> to validate the advertised prefix length here, in order to detect and >> avoid a configuration error specifying an invalid prefix length in >> the context of address autoconfiguration. >=20 > It reads reasonable. But the other paragraph requiring to ignore the = PIO which is non 64 is still there. These two paragraphs are = contradictory. >=20 > One requires consistency, the other requires 64. >=20 > We are going to write the same for IPv6 Addressing Architecture? A = paragraph requiring 64 and another requiring variable length? >=20 >> but this conversation seems to suggest it's still not clear enough. >=20 > BEcause when writing RFCs it is not by adding paragraphs that things = get clearer. Clarification paragraphs may be good, but often removing = some paragraphs can also improve clarity. >=20 > There are readers out there, most often the programmers. They dont = care about the earlier discussion involving pride and other feelings. = They want consistency - things that can be easily implemented. >=20 >>> As such, either rfc4862 or rfc4861 should be modified to make it >>> work together. >>=20 >> 4861 and 4862 already work together. But, we could make it even >> clearer that prefix length validation for on-link determination >> (actually there's no restriction for this) and prefix length >> validation for SLAAC are independent, if and when we want to update >> these RFCs. >>=20 >>> Maybe rfc4862 should not require the Host to refuse a received >>> plen+IID not making for 128. >>=20 >> No, it should still require that, as there's currently no defect in >> the spec even if it may still not be crystal clear for some. However, >> you have the right to propose loosening the requirement, so if you >> think that change is necessary, please feel free to write a draft. >=20 > Ah this invitation. The title reads great! "Mistery of...". Thanks, = but no, not at this time :-) >=20 >>>> It's also correct to ignore that prefix for SLAAC per RFC4862 >>>> (not 4861). >>>=20 >>> If some RFC requires the Host to ignore the PIO and some other RFC >>> requires the Host to interpret it, and both RFCs are mandatory to >>> implement, under the same conditions, isn't there a conflict? >>=20 >> No, there's no conflict, once one understands the two types >> validations are independent: >>=20 >> - RFC4861 does not impose any restriction on the prefix length in PIO >> for on-link determination purpose (and therefore the host is expected >> to accept any length of prefix for on-link determination) - RFC4862 >> requires the host to ignore the PIO of some particular length for the >> purpose of SLAAC (and therefore the host is expected to not use a >> prefix of "invalid length" to configure an address) >>=20 >> Both can coexist. BSDs literally implement it. =46rom your previous >> message, I guess so does Linux. I also suspect so do other major OS >> implementations such as Windows or Solaris, as this separation has >> been in fact one of common test cases in IPv6 protocol conformance >> test suites. >=20 > Ok. >=20 > Alex >=20 >>=20 >> -- JINMEI, Tatuya >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Mar 3 14:54:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE071293DB for ; Fri, 3 Mar 2017 14:54:57 -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 autolearn_force=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 Eee-H8ZHfXu1 for ; Fri, 3 Mar 2017 14:54:56 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABF0124281 for ; Fri, 3 Mar 2017 14:54:56 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cjw6B-0000EzC; Fri, 3 Mar 2017 23:54:55 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <20170223134026.GI5069@gir.theapt.org> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> In-reply-to: Your message of "Fri, 3 Mar 2017 23:40:08 +0100 ." Date: Fri, 03 Mar 2017 23:54:54 +0100 Archived-At: Cc: Alexandre Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:54:57 -0000 > > If "what to put between /10 and /64" is for (auto)configuring > > link-local addresses, yes, I assume it's 0s. But not "silently" - > > it's based on Section 2.5.6 of RFC4291. > > That section 2.5.6 does not say whether the 0s are part of the plen > or part of the IID. > > It is your reading, with an inclined view to make everything work, > that makes it read so. > > But read it with an inquiring view: is the 0 part of the IID or of > the plen? The section does not answer. Section 5.3 of RFC 4862 spells it out in great detail: A link-local address is formed by combining the well-known link-local prefix FE80::0 [RFC4291] (of appropriate length) with an interface identifier as follows: 1. The left-most 'prefix length' bits of the address are those of the link-local prefix. 2. The bits in the address to the right of the link-local prefix are set to all zeroes. 3. If the length of the interface identifier is N bits, the right- most N bits of the address are replaced by the interface identifier. If the sum of the link-local prefix length and N is larger than 128, autoconfiguration fails and manual configuration is required. The length of the interface identifier is defined in a separate link- type-specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2). These documents will carefully define the length so that link-local addresses can be autoconfigured on the link. A link-local address has an infinite preferred and valid lifetime; it is never timed out. From nobody Fri Mar 3 15:44:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7055F128B38 for ; Fri, 3 Mar 2017 15:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 NlR8kMvqmAbO for ; Fri, 3 Mar 2017 15:44:05 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26173126D73 for ; Fri, 3 Mar 2017 15:44:05 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id j5so37810389pfb.2 for ; Fri, 03 Mar 2017 15:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6XKal/eAqVGE8BrS1pWKI4N3pVrt1rBGUQKyNNmIM80=; b=DJX3j3EUisBGY9wiLVcemzT+7jGEaMei3gyr7xErTYLBUhG8LUcUT+r4Pz2qKuGLyH qUEEk+MkJv5TdKnH9PLPl8Vp9f0xMd2N1H01QTRAGWZMIJX6+0L1VZmFgR9wCh9phann 8xy/rP/knb1uySeZNcsFSa6Vz/M0YvLZQbYyYxu9/kk4r6TNiP0Myhn9pkIssIq2b5YW sR8grK+5M35mq0PgVmZsgNLIhBO/OD1zG8H7NIyugO41XCF2GyzTExJzaUArtiTA+tmw snIjilDFaIhueuQvptTMjnHJrFgPgGpaY8zifiZq/vq62JM7IUVKGLUr2z4jnjbu1zXe IJxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6XKal/eAqVGE8BrS1pWKI4N3pVrt1rBGUQKyNNmIM80=; b=VhmihIc5KDMcpSPxjB0+4EHRVYchiLVkUyK02IcCIoB3Zo+NxHgHlnr02DF4KECpna 4aIP07vsSJHKzgDtbisFZh+m3/HUfHIKuIADA7yyRIyrkbStfvVtyuhgDsjrro6BqNRY 3RZHeaOLkJrzlHZKOikQukoqxe36PfcZAqBf44rvSvUgkCOfJftfUaoXbGgnCKuAseQL W2rmou37B5rtjpD3NhJfg7EYkRStgWA/7q+PTQCRZ2psuLnpk4M5YJ66hB9x//vhIGAC 4/xi9ogQPmEXddZMCjyewpFnLe7pswaGBJVA2xBCFX07T9t01xwRSW5BIDb4ZY7Qha+U 6FTQ== X-Gm-Message-State: AMke39k1+i1DAX+1vj3nyckP/cnF1gIWLqGnH+n36Uq+H8wnTrOITexBYuXkmHJD1AzwVWC0 X-Received: by 10.99.43.216 with SMTP id r207mr1311576pgr.214.1488584644548; Fri, 03 Mar 2017 15:44:04 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id s21sm25553567pgg.65.2017.03.03.15.44.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 15:44:03 -0800 (PST) From: james woodyatt Message-Id: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_882D4D36-46BD-4E6B-860B-F18BAF1BC256" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 Date: Fri, 3 Mar 2017 15:44:02 -0800 In-Reply-To: To: Philip Homburg References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:44:06 -0000 --Apple-Mail=_882D4D36-46BD-4E6B-860B-F18BAF1BC256 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 3, 2017, at 14:30, Philip Homburg = wrote: >=20 >> Shorter james: if IETF will insist that I modify my host IPv6 >> stack so that, on Wi-Fi links, it will do on-link determination >> with prefix lengths other than 64 bits, then I want to see that >> in its own draft and not in the successor to RFC 4291. >=20 > Did I miss a couple of rounds somewhere? It looks like you=E2=80=99re assuming that I don=E2=80=99t have to = comply with requirements in RFC 4862 when processing RA messages with = Prefix Information Options (PIO). Like every good IPv6 host = implementation, mine implements SLAAC. It therefore needs to comply with = RFC 4862, especially if I ever hope for it to achieve IPv6 Ready = certification for hosts. Lots of hosts are required to implement RFC = 4862. You probably have one in your pocket. > Onlink prefixes come from PIO options in RAs with the L bit set. Since > forever, these options have a prefix length field. >=20 > Section 4.6.2 of RFC 4861 has this to say about prefix length: > "8-bit unsigned integer. The number of leading bits > "in the Prefix that are valid. The value ranges > "from 0 to 128. The prefix length field provides > "necessary information for on-link determination > "(when combined with the L flag in the prefix > "information option). It also assists with address > "autoconfiguration as specified in [ADDRCONF], for > "which there may be more restrictions on the prefix > "length. >=20 > So there are extra restriction for SLAAC, but not for use as an onlink > prefix. >=20 > Are you saying that your stack completely ignores that prefix length = and > hardcodes it to 64? I=E2=80=99m saying that my stack tries to comply with RFC 4862 which = requires that it ignore PIO options where the Prefix Length is not 64 on = link types that define the length of the IID as 64 bits in the relevant = IPv6-over-link document. My stack does that in the hopes of eventually = passing the IPv6 Ready certification test, which I=E2=80=99ve been = through before, and, yes, it tests for that MUST In RFC 4862. It tests = both the requirements for processing the A flag as well as the = requirements for processing the L flag. If you send me a Prefix Length other than 64 bits, then I=E2=80=99m = gonna ignore it. Just as RFC 4862 commands. It=E2=80=99s technically true that *if* my stack did not implement = SLAAC, then it would have no need to comply with RFC 4862, and it could = therefore accept Prefix Length other than 64 bits on Ethernet (and = Wi-Fi) link types, by complying only with RFC 4861 and not RFC 4862. But let=E2=80=99s be honest. Who would buy gear intended for home = networks that cannot do SLAAC? --james woodyatt > --Apple-Mail=_882D4D36-46BD-4E6B-860B-F18BAF1BC256 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 3, 2017, at 14:30, Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com> wrote:

      Shorter = james: if IETF will insist that I modify my host IPv6
    =   stack so that, on Wi-Fi links, it will do on-link = determination
      with prefix lengths other than = 64 bits, then I want to see that
      in its own = draft and not in the successor to RFC 4291.
    Did I miss a couple of rounds somewhere?

    It = looks like you=E2=80=99re assuming that I don=E2=80=99t have to comply = with requirements in RFC 4862 when processing RA messages with Prefix = Information Options (PIO). Like every good IPv6 host implementation, = mine implements SLAAC. It therefore needs to comply with RFC 4862, = especially if I ever hope for it to achieve IPv6 Ready certification for = hosts. Lots of hosts are required to implement RFC 4862. You probably = have one in your pocket.

    Onlink prefixes come from PIO = options in RAs with the L bit set. Since
    forever, these = options have a prefix length field.

    Section = 4.6.2 of RFC 4861 has this to say about prefix length:
    "8-bit unsigned integer.  The number of leading bits
    "in the Prefix that are valid.  The value ranges
    "from 0 to 128.  The prefix length field provides
    "necessary information for on-link determination
    "(when combined with the L flag in the prefix
    "information option).  It also assists with address
    "autoconfiguration as specified in [ADDRCONF], for
    "which there may be more restrictions on the prefix
    "length.

    So there are extra = restriction for SLAAC, but not for use as an onlink
    prefix.

    Are you saying that your = stack completely ignores that prefix length and
    hardcodes = it to 64?
    I=E2=80=99m saying that my stack tries = to comply with RFC 4862 which requires that it ignore PIO options where = the Prefix Length is not 64 on link types that define the length of the = IID as 64 bits in the relevant IPv6-over-link document. My stack does = that in the hopes of eventually passing the IPv6 Ready certification = test, which I=E2=80=99ve been through before, and, yes, it tests for = that MUST In RFC 4862. It tests both the requirements for processing the = A flag as well as the requirements for processing the L flag.

    If you send me a Prefix = Length other than 64 bits, then I=E2=80=99m gonna ignore it. Just as RFC = 4862 commands.

    It=E2=80=99s technically true that *if* my stack did not = implement SLAAC, then it would have no need to comply with RFC 4862, and = it could therefore accept Prefix Length other than 64 bits on Ethernet = (and Wi-Fi) link types, by complying only with RFC 4861 and not RFC = 4862.

    But = let=E2=80=99s be honest. Who would buy gear intended for home networks = that cannot do SLAAC?


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_882D4D36-46BD-4E6B-860B-F18BAF1BC256-- From nobody Fri Mar 3 15:58:35 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D61294D2; Fri, 3 Mar 2017 15:55:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , <6man-chairs@ietf.org> Subject: 6man - Requested session has been scheduled for IETF 98 X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532731.15846.15384676887239826879.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:27 -0800 Archived-At: Cc: ipv6@ietf.org, suresh.krishnan@ericsson.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:29 -0000 Dear Ole Troan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. 6man Session 1 (2:30:00) Thursday, Morning Session I 0900-1130 Room Name: Zurich D size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 Maintenance Area Name: Internet Area Session Requester: Ole Troan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6lo 6tisch dhc homenet intarea v6ops softwire spring Second Priority: mtgvenue People who must be present: Robert M. Hinden Ole Troan Suresh Krishnan Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Fri Mar 3 16:53:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277F61293E4 for ; Fri, 3 Mar 2017 16:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WO5xiTaQ5DCD for ; Fri, 3 Mar 2017 16:53:31 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD9D12706D for ; Fri, 3 Mar 2017 16:53:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v240rUkr042077; Fri, 3 Mar 2017 17:53:30 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v240rN7d042061 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 3 Mar 2017 17:53:23 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Mar 2017 16:53:23 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 3 Mar 2017 16:53:23 -0800 From: "Manfredi, Albert E" To: james woodyatt Subject: RE: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Topic: A proposal for draft-ietf-6man-rfc4291bis-07 Thread-Index: AQHSlHgYBO+OWub53keQ56BZKFhxHqGD1tWQ Date: Sat, 4 Mar 2017 00:53:23 +0000 Message-ID: <59a0bc68e13643c48476c4ce4f75e59c@XCH15-06-11.nw.nos.boeing.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> In-Reply-To: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:53:32 -0000 RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGph bWVzIHdvb2R5YXR0DQoNCj4gSeKAmW0gc2F5aW5nIHRoYXQgbXkgc3RhY2sgdHJpZXMgdG8gY29t cGx5IHdpdGggUkZDIDQ4NjIgd2hpY2gNCj4gcmVxdWlyZXMgdGhhdCBpdCBpZ25vcmUgUElPIG9w dGlvbnMgd2hlcmUgdGhlIFByZWZpeCBMZW5ndGggaXMNCj4gbm90IDY0IG9uIGxpbmsgdHlwZXMg dGhhdCBkZWZpbmUgdGhlIGxlbmd0aCBvZiB0aGUgSUlEIGFzIDY0IGJpdHMNCj4gaW4gdGhlIHJl bGV2YW50IElQdjYtb3Zlci1saW5rIGRvY3VtZW50Lg0KDQpUaGF0J3MgNjQtYml0IElJRHMgZm9y IFNMQUFDIGFuZCBsaW5rLWxvY2FsLiBBY2NvcmRpbmcgdG8gUkZDIDI0NjQuIE5vdCBhIGNvbnN0 YW50IGZvciBhbGwgSUlEcywgYXMgSSByZWFkIGl0ICh1c2VkIGluIHByZXNlbnQgYW5kIHBhc3Qg dGVuc2UpLg0KDQo+IElmIHlvdSBzZW5kIG1lIGEgUHJlZml4IExlbmd0aCBvdGhlciB0aGFuIDY0 IGJpdHMsIHRoZW4gSeKAmW0gZ29ubmENCj4gaWdub3JlIGl0LiBKdXN0IGFzIFJGQyA0ODYyIGNv bW1hbmRzLg0KDQpGb3IgU0xBQUMuDQoNCj4gSXTigJlzIHRlY2huaWNhbGx5IHRydWUgdGhhdCAq aWYqIG15IHN0YWNrIGRpZCBub3QgaW1wbGVtZW50IFNMQUFDLCB0aGVuDQo+IGl0IHdvdWxkIGhh dmUgbm8gbmVlZCB0byBjb21wbHkgd2l0aCBSRkMgNDg2MiwgYW5kIGl0IGNvdWxkIHRoZXJlZm9y ZQ0KPiBhY2NlcHQgUHJlZml4IExlbmd0aCBvdGhlciB0aGFuIDY0IGJpdHMgb24gRXRoZXJuZXQg KGFuZCBXaS1GaSkgbGluaw0KPiB0eXBlcywNCg0KVG8gbWUsIHRoaXMgY291bGQgYmUgYSBwcm9i bGVtLiBFdmVuIG9uIEV0aGVybmV0LCBpdCBzaG91bGQgYWNjZXB0IG90aGVyIHRoYW4gLzY0IHBy ZWZpeGVzLiBJZiBJJ20gYXNzaWduZWQgYSAvNjQsIG9yIGEgLzYwLCBvciB3aGF0ZXZlciwgYW5k IEkgZGV0ZXJtaW5lIHRvIGJlIGluYWRlcXVhdGUsIEkgc2hvdWxkIGJlIGFibGUgdG8gdXNlIFJB IGFuZCBESENQdjYsIGJlaGluZCBteSBlZGdlIHJvdXRlciwgdG8gY3JlYXRlIGFueSBudW1iZXIg b2Ygc3VibmV0cy4gUkZDIDQyOTEgYmlzIG5lZWRzIHRvIGFjY2VwdCB0aGlzIGFzIGxlZ2l0aW1h dGUsIGJlY2F1c2Ugb3RoZXIgUkZDcyBhbHJlYWR5IGRvLg0KDQpBbmQsIG1vcmUgaW1wb3J0YW50 bHksIFJGQyA0ODYyIGl0c2VsZiBsZWF2ZXMgdGhlIGRvb3Igb3BlbmVkIGZvciBhIHJldmlzZWQg aW1wbGVtZW50YXRpb24gb2YgU0xBQUMsIGFsbG93aW5nIGV2ZW4gU0xBQUMgdG8gYmUgdXNlZCBp biBzdWNoIGEgc3VibmV0dGVkIGNhc2UuDQoNCkJlcnQNCg0K From nobody Sat Mar 4 01:15:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D79C1294B5 for ; Sat, 4 Mar 2017 01:15:45 -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 autolearn_force=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 epULbmEYogSc for ; Sat, 4 Mar 2017 01:15:43 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3460112943C for ; Sat, 4 Mar 2017 01:15:42 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1ck5mu-0000GaC; Sat, 4 Mar 2017 10:15:40 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> In-reply-to: Your message of "Fri, 3 Mar 2017 15:44:02 -0800 ." <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> Date: Sat, 04 Mar 2017 10:15:39 +0100 Archived-At: Cc: james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 09:15:45 -0000 > Im saying that my stack tries to comply with RFC 4862 which > requires that it ignore PIO options where the Prefix Length is > not 64 on link types that define the length of the IID as 64 > bits in the relevant IPv6-over-link document. My stack does that > in the hopes of eventually passing the IPv6 Ready certification > test, which Ive been through before, and, yes, it tests for that > MUST In RFC 4862. It tests both the requirements for processing > the A flag as well as the requirements for processing the L > flag. > > If you send me a Prefix Length other than 64 bits, then Im gonna > ignore it. Just as RFC 4862 commands. I find this confusing, you are ignoring an onlink prefix because of auto configuration? That is IPv4 thinking. In IPv6 they are supposed to be decoupled. But in any case, ignoring an onlink prefix should be safe from an interoperability point of view. Without the prefix you have to send the traffic to the default router, which will send redirects. So slightly less efficient but no big deal. What I really don't understand is that if you implement RFC 4861 (ND) and you get a PIO option with the A bit clear, that you would drop that prefix because the address configuration that you are not doing anyhow would not allow it. To me that seems like a completely perverse reading of RFC 4861. Maybe the host requirements RFC should clarify this issue. Note that this prefix could be used for DHCPv6. And even if you stack cannnot use those addresses for address configuration, they may still be onlink. Also note that RFC 4861 clearly distinguishes between onlink and autoconfiguration with the text: "It also assists with address autoconfiguration as specified in [ADDRCONF], for which there may be more restrictions on the prefix length." It would be really weird that assume that RFC 4862 can silently update 4861 in this regard. Ah, RFC 4862 (Section 5.5.3) is even specific about this problem: "In fact, the "advertised length has non-trivial meaning for on-link "determination in [RFC4861] where the sum of the prefix length and "the interface identifier length may not be equal to 128. Thus, it "should be safe to validate the advertised prefix length here, in "order to detect and avoid a configuration error specifying an "invalid prefix length in the context of address autoconfiguration. So this consistency check should only be done if the A bit is set. And even then, it is not clear of RFC 4862 can change behavior specified by RFC 4861 without explictly saying so. From nobody Sat Mar 4 04:09:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFD912946A for ; Sat, 4 Mar 2017 04:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 bu8NKqsfWWmM for ; Sat, 4 Mar 2017 04:09:35 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CBBD129481 for ; Sat, 4 Mar 2017 04:09:34 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v24C9W0C014247; Sat, 4 Mar 2017 13:09:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 64E4D201037; Sat, 4 Mar 2017 13:09:32 +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 5507E200CD2; Sat, 4 Mar 2017 13:09:32 +0100 (CET) Received: from [132.166.84.69] ([132.166.84.69]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v24C9V1G029031; Sat, 4 Mar 2017 13:09:31 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes To: Fred Baker References: <20170223134026.GI5069@gir.theapt.org> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com> From: Alexandre Petrescu Message-ID: <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com> Date: Sat, 4 Mar 2017 13:09:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 IPv6 List , =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 12:09:38 -0000 Fred, I think the problem I have - agreed, on my side - is that "fe80::/10" is sometimes read as a link-local address, other times as a prefix configured on a computer, other times as just the first 10bits of an LL address. The difficulty is in that people say "prefix" meaning the first bits from left to right, and other times "prefix" meaning what is configured on a computer. They are different. This "fe80::/10" seems to be the first ten bits of a link-local address; "fe80::/10" is not an address and not a prefix to be configured on a computer, even though whenever we write "P::/X" we understand it as a prefix configured on a computer. The prefix configured on a computer is "fe80::/64" and the LL address is "fe80::1". I had the same problem with textual representation of site-local "fec0", with the default route "2001::/3", with the two ULAs "fc00::/7" "fd00::/7" and recently with the 16 prefixes denoted by 2001:db8:ffff:cafe::/60 despite the mandatory presence of a single character (the 'e' in cafe could have been 0, 1, 2... f). I propose to introduce new ASCII characters in the textual representation of IPv6 addresses: fe80:://10 means the first 10 bits of an address, it does not mean it is the configured prefix of an address in the rt table, nor is it a prefix used for on-link determination. fg00:://7 means the first 7 bits of a ULA, also represented as "fc00::/7" or as "fd00::/7". 2001:db8:ffff:caf*::/60 means one or more configured prefixes from 0 to f at the place of *. I will try to use these characters in conversation to see what it gives. Alex Le 03/03/2017 à 23:51, Fred Baker a écrit : > Read the fine RFC, Alexandre. We used to have something called a > site-local address, which was fe80::/10 with 54 bits that were not > all zero and a 64 bit IID, and the link-local address was fe80::/10 > with 54 bits of zero. We deprecated the site-local address, but > link-local is still fe80::/10 followed by 54 bits that are all zero. > >> On Mar 3, 2017, at 2:40 PM, Alexandre Petrescu >> wrote: >> >> >> >> Le 03/03/2017 à 23:02, 神明é”哉 a écrit : >>> At Fri, 3 Mar 2017 22:09:47 +0100, Alexandre Petrescu >>> wrote: >>> >>>>> Both, and I believe at least most implementers have had no >>>>> difficulty in interpreting the spec that way. >>>> >>>> If it is both, then it requires that the prefix used for >>>> address autoconfiguration of LL addresses to be 64bit length. >>>> >>>> But the LL prefix is fe80::/10. >>>> >>>> "fe80::/10" means it is a prefix. It does not mean it is "a >>>> mask for implementation in BSD and other OSs C macros to >>>> recognise the LL address". >>>> >>>> So, what goes between /10 and /64? Why? >>> >>> For (auto)configuring a link-local address? If so, it's all-0 >>> bits, as defined in Section 2.5.6 of RFC4291: >>> >>> | 10 | | bits | 54 bits | 64 >>> bits | >>> +----------+-------------------------+----------------------------+ >>> >>> >>> |1111111010| 0 | interface ID | >>> +----------+-------------------------+----------------------------+ >> >> >>> >>> Is that figure picturing a fe80::/10 or a fe80::/64? >> >> Is the prefix extended from fe80::/10 to fe80::/64 with 0s? Or is >> the IID len extended from 64 to to become an IID len==108? >> >> If we stopped saying fe80::/10 then it would be clearer. >> >> But one seems to be forced to continue talking about fe80::/10. >> >> Otherwise we would never write text reading "fe80::/10". >> >>>>> - uses the 64-bit IID (as specified in RFC2464) - uses the >>>>> fe80::/64 prefix (as defined in RFC4291 Section 2.5.6) >>>> >>>> And ignores the same document's fe80::/10. And some >>>> implementer does not appreciate that. >>> >>> I'm not sure what you mean by this here, but out of curiosity, >>> who is that implementer and what does it actually do by not >>> appreciating that? >> >> Let us say that I talked to many IPv6 stack implementers and I >> continue to. So to answer this question there is not one person >> in particular that I could name, but rather the name of a few >> persons, and a sort of average I make from my discussions. >> >> Moreover, whenever I invoke such 3rd person, it is the very >> optimistic view. I avoid saying all the bad things that I heard, >> and I keep the good things. >> >>> Auto-configuring a link-local address that does not match >>> fe80::/64? >> >> I mean this: is one implementer mandated to bzero() the bits from >> /10 to /64? Or not? Nobody is telling her so. >> >> If one writes code that generate an LL address by using a /64 >> mask, and then tries to make sure by recognising it by using a /10 >> macro, there is obviously place for false negatives or false >> positives. >> >> If the 4291 spec wrote everywhere that the prefix is "fe80::/64" >> (and never write "fe80::/10"), then the implementer would be >> helped a lot. She would generate and reognise by always using a >> 64bit mask. >> >> But that would be wrong to put in an IPv6 Addressing Archi, >> because 64 is too much of a limit, anyways. >> >> Additionally, when we talk about the first 3 bits 000, we dont >> write "::/3" because "::/3" is a prefix and there is a risk of >> confusion. >> >> You may remember the discussion about how to denote a default >> route. >> >>>>> - combine these to configure a link-local address >>>>> fe80::<64-bit IID> as specified in Section 5.3 of RFC4862 >>>> >>>> And who tells the implementer what to put between /10 and /64? >>> >>>> Should that be 0s? 1s? An arbitrary random mix of 0s and 1s? >>> >>> 0s, as described in RFC4291 Section 2.5.6. >> >> Are these 0s part of the plen or part of the IID? >> >>>>> To me there's nothing confusing or unclear here, and I >>>>> suspect the Linux implementation essentially does the same >>>>> thing. >>>> >>>> I think you dont want to see the potential confusion because >>>> you do not ask yourself what to put between /10 and /64. I >>>> think you silently assume that should be 0s. >>> >>> If "what to put between /10 and /64" is for (auto)configuring >>> link-local addresses, yes, I assume it's 0s. But not "silently" >>> - it's based on Section 2.5.6 of RFC4291. >> >> That section 2.5.6 does not say whether the 0s are part of the >> plen or part of the IID. >> >> It is your reading, with an inclined view to make everything work, >> that makes it read so. >> >> But read it with an inquiring view: is the 0 part of the IID or of >> the plen? The section does not answer. >> >>> BTW, I do not necessarily disagree that there may be "some >>> confusion" if one sees this: >>> >>> Link-Local unicast 1111111010 FE80::/10 2.5.6 >>> (Section 2.4 of RFC4291) >>> >>> and this: >>> >>> | 10 | | bits | 54 bits | 64 >>> bits | >>> +----------+-------------------------+----------------------------+ >>> >>> >>> |1111111010| 0 | interface ID | >>> +----------+-------------------------+----------------------------+ >>> >>> >>> (Section 2.5.6 of RFC4291) >>> >>> like, wondering "what if the intermediate 54 bits are non-0? >>> should it be called a link-local address?". >> >> I agree with the doubt. >> >>> But, at least in terms of auto-generating link-local addresses, >>> the specs are clear enough to me that these bits should be set >>> to 0. That's why I always try to clarify the context is to >>> auto-generate a link-local address in this conversation. >> >> Yes, it's clear it should be 0. But it's not clear whether the 0s >> are part of the plen or part of the IID. >> >>> If you want to further clear any possible confusion between the >>> intermediate 54 bits, I wouldn't discourage you to write a >>> "mystery of the intermediate 54 bits for fe80::/10" draft:-) >> >> I agree :-) When I hear this I think I need to stop talking >> because I cant write so many drafts as I write emails :-) >> >> But some of these things are indeed doubts there for a long time. >>> >>>>>> It does not forbid that that 64bit prefix be formed by >>>>>> self-appending a 0 to a /63 from the RA, or other >>>>>> mechanism. >>>>> >>>>> It's not the job of RFC2464. RFC4862 imposes the restriction >>>>> through its Section 5.5.3 bullet d): >>>> >>>> Well then, it should. >>>> >>>> BEcause currently RFC2464 says "An IPv6 address prefix used for >>>> stateless autoconfiguration [ACONF] of an Ethernet interface >>>> must have a length of 64 bits". >>>> >>>> If we go by your recommendation above, then it means RFC2464 >>>> must not say that. >>> >>> I guess we're just not on the same page...trying to rephrase my >>> point, it doesn't matter that RFC2464 "does not forbid that that >>> 64bit prefix be formed by self-appending a 0 to a /63 from the >>> RA", since RFC4862 forbids it anyway (by the "sum must be 128" >>> requirement). >> >> I dont understand you. >> >> I want to say this: RFC2464 does require the prefix len to be 64. >> >> >>>>> I guess that "rt entry for that /63 prefix" is to treat the >>>>> /63 prefix as on-link (assuming the corresponding PIO has L >>>>> bit on). >>>> >>>> YEs. >>>> >>>>> If so, that's the correct behavior per RFC4861 (not 4862). >>>> >>>> So RFC4862 should not require the Host to ignore a received >>>> non 128 plen+IID, because RFC4861 accepts it. >>> >>> Here I actually see conflating. RFC4862 only says the host MUST >>> ignore such prefix *for SLAAC*. >> >> That emphasis is yours, it's not in the document. The document >> says it must ignore it. >> >>> It doesn't say, for example, it should ignore the entire RA or >>> even for that particular PIO for other purposes than SLAAC. >> >> It says it must ignore the PIO. IT does not say for what to >> ignore it. >> >>> But I admit this point may be subtle and can easily be >>> misunderstood. RFC4862 tried to clarify that subtlety a bit in >>> the following paragraph of that section (that was actually >>> written by me): >>> >>> It is the responsibility of the system administrator to ensure >>> that the lengths of prefixes contained in Router Advertisements >>> are consistent with the length of interface identifiers for that >>> link type. It should be noted, however, that this does not mean >>> the advertised prefix length is meaningless. In fact, the >>> advertised length has non-trivial meaning for on-link >>> determination in [RFC4861] where the sum of the prefix length >>> and the interface identifier length may not be equal to 128. >>> Thus, it should be safe to validate the advertised prefix length >>> here, in order to detect and avoid a configuration error >>> specifying an invalid prefix length in the context of address >>> autoconfiguration. >> >> It reads reasonable. But the other paragraph requiring to ignore >> the PIO which is non 64 is still there. These two paragraphs are >> contradictory. >> >> One requires consistency, the other requires 64. >> >> We are going to write the same for IPv6 Addressing Architecture? >> A paragraph requiring 64 and another requiring variable length? >> >>> but this conversation seems to suggest it's still not clear >>> enough. >> >> BEcause when writing RFCs it is not by adding paragraphs that >> things get clearer. Clarification paragraphs may be good, but >> often removing some paragraphs can also improve clarity. >> >> There are readers out there, most often the programmers. They >> dont care about the earlier discussion involving pride and other >> feelings. They want consistency - things that can be easily >> implemented. >> >>>> As such, either rfc4862 or rfc4861 should be modified to make >>>> it work together. >>> >>> 4861 and 4862 already work together. But, we could make it even >>> clearer that prefix length validation for on-link determination >>> (actually there's no restriction for this) and prefix length >>> validation for SLAAC are independent, if and when we want to >>> update these RFCs. >>> >>>> Maybe rfc4862 should not require the Host to refuse a received >>>> plen+IID not making for 128. >>> >>> No, it should still require that, as there's currently no defect >>> in the spec even if it may still not be crystal clear for some. >>> However, you have the right to propose loosening the >>> requirement, so if you think that change is necessary, please >>> feel free to write a draft. >> >> Ah this invitation. The title reads great! "Mistery of...". >> Thanks, but no, not at this time :-) >> >>>>> It's also correct to ignore that prefix for SLAAC per RFC4862 >>>>> (not 4861). >>>> >>>> If some RFC requires the Host to ignore the PIO and some other >>>> RFC requires the Host to interpret it, and both RFCs are >>>> mandatory to implement, under the same conditions, isn't there >>>> a conflict? >>> >>> No, there's no conflict, once one understands the two types >>> validations are independent: >>> >>> - RFC4861 does not impose any restriction on the prefix length >>> in PIO for on-link determination purpose (and therefore the host >>> is expected to accept any length of prefix for on-link >>> determination) - RFC4862 requires the host to ignore the PIO of >>> some particular length for the purpose of SLAAC (and therefore >>> the host is expected to not use a prefix of "invalid length" to >>> configure an address) >>> >>> Both can coexist. BSDs literally implement it. From your >>> previous message, I guess so does Linux. I also suspect so do >>> other major OS implementations such as Windows or Solaris, as >>> this separation has been in fact one of common test cases in >>> IPv6 protocol conformance test suites. >> >> Ok. >> >> Alex >> >>> >>> -- JINMEI, Tatuya >>> >> >> -------------------------------------------------------------------- >> >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > From nobody Sat Mar 4 04:24:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A01129539 for ; Sat, 4 Mar 2017 04:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 VL-m6bJ8Jsv7 for ; Sat, 4 Mar 2017 04:24:49 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17CD12952C for ; Sat, 4 Mar 2017 04:24:48 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v24COkBe001702 for ; Sat, 4 Mar 2017 13:24:46 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8E2D52027AD for ; Sat, 4 Mar 2017 13:24: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 8501B2008E9 for ; Sat, 4 Mar 2017 13:24:46 +0100 (CET) Received: from [132.166.84.69] ([132.166.84.69]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v24COjvB026485 for ; Sat, 4 Mar 2017 13:24:46 +0100 Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> From: Alexandre Petrescu Message-ID: Date: Sat, 4 Mar 2017 13:24:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 12:24:50 -0000 Le 04/03/2017 à 10:15, Philip Homburg a écrit : >> Im saying that my stack tries to comply with RFC 4862 which >> requires that it ignore PIO options where the Prefix Length is not >> 64 on link types that define the length of the IID as 64 bits in >> the relevant IPv6-over-link document. My stack does that in the >> hopes of eventually passing the IPv6 Ready certification test, >> which Ive been through before, and, yes, it tests for that MUST In >> RFC 4862. It tests both the requirements for processing the A flag >> as well as the requirements for processing the L flag. >> >> If you send me a Prefix Length other than 64 bits, then Im gonna >> ignore it. Just as RFC 4862 commands. > > I find this confusing, you are ignoring an onlink prefix because of > auto configuration? That is IPv4 thinking. In IPv6 they are supposed > to be decoupled. > > But in any case, ignoring an onlink prefix should be safe from an > interoperability point of view. I agree with the IPv6 facility to have many on-link prefixes. IPv4 does it too these days anyways. But I do not agree with mandating there to be multiple on-link prefixes. The fe80::/64 is there by default. So if I add a 2001:db8:abba:abb*::/60 on some computer it will get two different onlink prefixes with different prefix lengths. Two is too much, because it means ND messages for that /64. That is noise that can create interference. Ideally, freedom from /64 means that I would only have that /60 prefix on the link if that's what I mnaually added. To realize that freedom (avoid ND noise for /64) I have to add the /60 _and_ delete the /64. Ideally just add the /60 should be sufficient. Alex > Without the prefix you have to send the traffic to the default > router, which will send redirects. So slightly less efficient but no > big deal. > > What I really don't understand is that if you implement RFC 4861 (ND) > and you get a PIO option with the A bit clear, that you would drop > that prefix because the address configuration that you are not doing > anyhow would not allow it. > > To me that seems like a completely perverse reading of RFC 4861. > Maybe the host requirements RFC should clarify this issue. > > Note that this prefix could be used for DHCPv6. And even if you > stack cannnot use those addresses for address configuration, they may > still be onlink. > > Also note that RFC 4861 clearly distinguishes between onlink and > autoconfiguration with the text: "It also assists with address > autoconfiguration as specified in [ADDRCONF], for which there may be > more restrictions on the prefix length." It would be really weird > that assume that RFC 4862 can silently update 4861 in this regard. > > Ah, RFC 4862 (Section 5.5.3) is even specific about this problem: > "In fact, the "advertised length has non-trivial meaning for on-link > "determination in [RFC4861] where the sum of the prefix length and > "the interface identifier length may not be equal to 128. Thus, it > "should be safe to validate the advertised prefix length here, in > "order to detect and avoid a configuration error specifying an > "invalid prefix length in the context of address autoconfiguration. > > So this consistency check should only be done if the A bit is set. > And even then, it is not clear of RFC 4862 can change behavior > specified by RFC 4861 without explictly saying so. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Mar 4 04:31:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D394129539 for ; Sat, 4 Mar 2017 04:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 1JW4vvlxjwRS for ; Sat, 4 Mar 2017 04:31:34 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC7912952C for ; Sat, 4 Mar 2017 04:31:33 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v24CVWu0012068 for ; Sat, 4 Mar 2017 13:31:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 13DC4203AA1 for ; Sat, 4 Mar 2017 13:31:32 +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 0A0232027AD for ; Sat, 4 Mar 2017 13:31:32 +0100 (CET) Received: from [132.166.84.69] ([132.166.84.69]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v24CVUK7003885 for ; Sat, 4 Mar 2017 13:31:31 +0100 Subject: Re: 6MAN IETF98 Call for agenda items To: ipv6@ietf.org References: <90F2B6EE-E8DB-4204-95DD-712E1EE828E8@employees.org> From: Alexandre Petrescu Message-ID: <8a62f361-4850-a69f-e271-0bfdf9116736@gmail.com> Date: Sat, 4 Mar 2017 13:31:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 12:31:35 -0000 I do not oppose a slot presenting PIO-X if time allows. However, as I understand it, PIO-X has a single goal - that to accomodate 64share. I wonder whether PIO-X could work with DHCPv6-PD? Would PIO-X help DHCPv6-PD deployment? This is what I am going to ask at the mic. Alex Le 01/03/2017 à 11:27, Erik Kline a écrit : > Ole, > > It's on me to get a -02 of PIO-X written and uploaded. Might it be > possible to get 5 minutes on that? > > -ek > > On 27 February 2017 at 06:16, > wrote: > > The 6MAN chairs are planning the meeting in Chicago at IETF98. > > If you have a draft you would like to discuss, please send your > request for agenda time to the 6man chairs. Please include in the > request, the title of the presentation, file name of the draft, the > speaker's name (and email), and how much time you would like. > > We will prioritise drafts that are working group items and drafts > that have been actively discussed on the list. > > We expect at least half of each talk’s presentation time to be used > for open discussion, > please plan your presentation accordingly. > > New drafts not discussed on the mailing list prior to the meeting, > or drafts that do not appear to have support from the working group > are unlikely to get time at the meeting. > > Please have agenda items to us by 2017-03-15. > > Regards, > > Bob & Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Mar 4 04:33:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED351294F0 for ; Sat, 4 Mar 2017 04:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 xHIwByY7la-Y for ; Sat, 4 Mar 2017 04:33:06 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF0F1294A1 for ; Sat, 4 Mar 2017 04:33:05 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v24CX2oZ003496; Sat, 4 Mar 2017 13:33:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A1F1E203EA6; Sat, 4 Mar 2017 13:33:02 +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 92285201037; Sat, 4 Mar 2017 13:33:02 +0100 (CET) Received: from [132.166.84.69] ([132.166.84.69]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v24CX1bQ004508; Sat, 4 Mar 2017 13:33:01 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes - DOI To: Fred Baker References: <20170223134026.GI5069@gir.theapt.org> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com> <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com> From: Alexandre Petrescu Message-ID: <1693b650-f79b-e569-be94-2bcb8d9af522@gmail.com> Date: Sat, 4 Mar 2017 13:33:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 IPv6 List , =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 12:33:08 -0000 This proposal has now a DOI: 10.13140/RG.2.2.30828.36484 Alex Le 04/03/2017 à 13:09, Alexandre Petrescu a écrit : > Fred, > > I think the problem I have - agreed, on my side - is that "fe80::/10" is > sometimes read as a link-local address, other times as a prefix > configured on a computer, other times as just the first 10bits of an LL > address. > > The difficulty is in that people say "prefix" meaning the first bits > from left to right, and other times "prefix" meaning what is configured > on a computer. They are different. > > This "fe80::/10" seems to be the first ten bits of a link-local address; > "fe80::/10" is not an address and not a prefix to be configured on a > computer, even though whenever we write "P::/X" we understand it as a > prefix configured on a computer. > > The prefix configured on a computer is "fe80::/64" and the LL address is > "fe80::1". > > I had the same problem with textual representation of site-local "fec0", > with the default route "2001::/3", with the two ULAs "fc00::/7" > "fd00::/7" and recently with the 16 prefixes denoted by > 2001:db8:ffff:cafe::/60 despite the mandatory presence of a single > character (the 'e' in cafe could have been 0, 1, 2... f). > > I propose to introduce new ASCII characters in the textual > representation of IPv6 addresses: > > fe80:://10 means the first 10 bits of an address, it does not mean it is > the configured prefix of an address in the rt table, nor is it a prefix > used for on-link determination. > > fg00:://7 means the first 7 bits of a ULA, also represented as > "fc00::/7" or as "fd00::/7". > > 2001:db8:ffff:caf*::/60 means one or more configured prefixes from 0 to > f at the place of *. > > I will try to use these characters in conversation to see what it gives. > > Alex > > > Le 03/03/2017 à 23:51, Fred Baker a écrit : >> Read the fine RFC, Alexandre. We used to have something called a >> site-local address, which was fe80::/10 with 54 bits that were not >> all zero and a 64 bit IID, and the link-local address was fe80::/10 >> with 54 bits of zero. We deprecated the site-local address, but >> link-local is still fe80::/10 followed by 54 bits that are all zero. >> >>> On Mar 3, 2017, at 2:40 PM, Alexandre Petrescu >>> wrote: >>> >>> >>> >>> Le 03/03/2017 à 23:02, 神明é”哉 a écrit : >>>> At Fri, 3 Mar 2017 22:09:47 +0100, Alexandre Petrescu >>>> wrote: >>>> >>>>>> Both, and I believe at least most implementers have had no >>>>>> difficulty in interpreting the spec that way. >>>>> >>>>> If it is both, then it requires that the prefix used for >>>>> address autoconfiguration of LL addresses to be 64bit length. >>>>> >>>>> But the LL prefix is fe80::/10. >>>>> >>>>> "fe80::/10" means it is a prefix. It does not mean it is "a >>>>> mask for implementation in BSD and other OSs C macros to >>>>> recognise the LL address". >>>>> >>>>> So, what goes between /10 and /64? Why? >>>> >>>> For (auto)configuring a link-local address? If so, it's all-0 >>>> bits, as defined in Section 2.5.6 of RFC4291: >>>> >>>> | 10 | | bits | 54 bits | 64 >>>> bits | >>>> +----------+-------------------------+----------------------------+ >>>> >>>> >>>> > |1111111010| 0 | interface ID | >>>> +----------+-------------------------+----------------------------+ >>> >>> >>>> >>>> > Is that figure picturing a fe80::/10 or a fe80::/64? >>> >>> Is the prefix extended from fe80::/10 to fe80::/64 with 0s? Or is >>> the IID len extended from 64 to to become an IID len==108? >>> >>> If we stopped saying fe80::/10 then it would be clearer. >>> >>> But one seems to be forced to continue talking about fe80::/10. >>> >>> Otherwise we would never write text reading "fe80::/10". >>> >>>>>> - uses the 64-bit IID (as specified in RFC2464) - uses the >>>>>> fe80::/64 prefix (as defined in RFC4291 Section 2.5.6) >>>>> >>>>> And ignores the same document's fe80::/10. And some >>>>> implementer does not appreciate that. >>>> >>>> I'm not sure what you mean by this here, but out of curiosity, >>>> who is that implementer and what does it actually do by not >>>> appreciating that? >>> >>> Let us say that I talked to many IPv6 stack implementers and I >>> continue to. So to answer this question there is not one person >>> in particular that I could name, but rather the name of a few >>> persons, and a sort of average I make from my discussions. >>> >>> Moreover, whenever I invoke such 3rd person, it is the very >>> optimistic view. I avoid saying all the bad things that I heard, >>> and I keep the good things. >>> >>>> Auto-configuring a link-local address that does not match >>>> fe80::/64? >>> >>> I mean this: is one implementer mandated to bzero() the bits from >>> /10 to /64? Or not? Nobody is telling her so. >>> >>> If one writes code that generate an LL address by using a /64 >>> mask, and then tries to make sure by recognising it by using a /10 >>> macro, there is obviously place for false negatives or false >>> positives. >>> >>> If the 4291 spec wrote everywhere that the prefix is "fe80::/64" >>> (and never write "fe80::/10"), then the implementer would be >>> helped a lot. She would generate and reognise by always using a >>> 64bit mask. >>> >>> But that would be wrong to put in an IPv6 Addressing Archi, >>> because 64 is too much of a limit, anyways. >>> >>> Additionally, when we talk about the first 3 bits 000, we dont >>> write "::/3" because "::/3" is a prefix and there is a risk of >>> confusion. >>> >>> You may remember the discussion about how to denote a default >>> route. >>> >>>>>> - combine these to configure a link-local address >>>>>> fe80::<64-bit IID> as specified in Section 5.3 of RFC4862 >>>>> >>>>> And who tells the implementer what to put between /10 and /64? >>>> >>>>> Should that be 0s? 1s? An arbitrary random mix of 0s and 1s? >>>> >>>> 0s, as described in RFC4291 Section 2.5.6. >>> >>> Are these 0s part of the plen or part of the IID? >>> >>>>>> To me there's nothing confusing or unclear here, and I >>>>>> suspect the Linux implementation essentially does the same >>>>>> thing. >>>>> >>>>> I think you dont want to see the potential confusion because >>>>> you do not ask yourself what to put between /10 and /64. I >>>>> think you silently assume that should be 0s. >>>> >>>> If "what to put between /10 and /64" is for (auto)configuring >>>> link-local addresses, yes, I assume it's 0s. But not "silently" >>>> - it's based on Section 2.5.6 of RFC4291. >>> >>> That section 2.5.6 does not say whether the 0s are part of the >>> plen or part of the IID. >>> >>> It is your reading, with an inclined view to make everything work, >>> that makes it read so. >>> >>> But read it with an inquiring view: is the 0 part of the IID or of >>> the plen? The section does not answer. >>> >>>> BTW, I do not necessarily disagree that there may be "some >>>> confusion" if one sees this: >>>> >>>> Link-Local unicast 1111111010 FE80::/10 2.5.6 >>>> (Section 2.4 of RFC4291) >>>> >>>> and this: >>>> >>>> | 10 | | bits | 54 bits | 64 >>>> bits | >>>> +----------+-------------------------+----------------------------+ >>>> >>>> >>>> > |1111111010| 0 | interface ID | >>>> +----------+-------------------------+----------------------------+ >>>> >>>> >>>> > (Section 2.5.6 of RFC4291) >>>> >>>> like, wondering "what if the intermediate 54 bits are non-0? >>>> should it be called a link-local address?". >>> >>> I agree with the doubt. >>> >>>> But, at least in terms of auto-generating link-local addresses, >>>> the specs are clear enough to me that these bits should be set >>>> to 0. That's why I always try to clarify the context is to >>>> auto-generate a link-local address in this conversation. >>> >>> Yes, it's clear it should be 0. But it's not clear whether the 0s >>> are part of the plen or part of the IID. >>> >>>> If you want to further clear any possible confusion between the >>>> intermediate 54 bits, I wouldn't discourage you to write a >>>> "mystery of the intermediate 54 bits for fe80::/10" draft:-) >>> >>> I agree :-) When I hear this I think I need to stop talking >>> because I cant write so many drafts as I write emails :-) >>> >>> But some of these things are indeed doubts there for a long time. >>>> >>>>>>> It does not forbid that that 64bit prefix be formed by >>>>>>> self-appending a 0 to a /63 from the RA, or other >>>>>>> mechanism. >>>>>> >>>>>> It's not the job of RFC2464. RFC4862 imposes the restriction >>>>>> through its Section 5.5.3 bullet d): >>>>> >>>>> Well then, it should. >>>>> >>>>> BEcause currently RFC2464 says "An IPv6 address prefix used for >>>>> stateless autoconfiguration [ACONF] of an Ethernet interface >>>>> must have a length of 64 bits". >>>>> >>>>> If we go by your recommendation above, then it means RFC2464 >>>>> must not say that. >>>> >>>> I guess we're just not on the same page...trying to rephrase my >>>> point, it doesn't matter that RFC2464 "does not forbid that that >>>> 64bit prefix be formed by self-appending a 0 to a /63 from the >>>> RA", since RFC4862 forbids it anyway (by the "sum must be 128" >>>> requirement). >>> >>> I dont understand you. >>> >>> I want to say this: RFC2464 does require the prefix len to be 64. >>> >>> >>>>>> I guess that "rt entry for that /63 prefix" is to treat the >>>>>> /63 prefix as on-link (assuming the corresponding PIO has L >>>>>> bit on). >>>>> >>>>> YEs. >>>>> >>>>>> If so, that's the correct behavior per RFC4861 (not 4862). >>>>> >>>>> So RFC4862 should not require the Host to ignore a received >>>>> non 128 plen+IID, because RFC4861 accepts it. >>>> >>>> Here I actually see conflating. RFC4862 only says the host MUST >>>> ignore such prefix *for SLAAC*. >>> >>> That emphasis is yours, it's not in the document. The document >>> says it must ignore it. >>> >>>> It doesn't say, for example, it should ignore the entire RA or >>>> even for that particular PIO for other purposes than SLAAC. >>> >>> It says it must ignore the PIO. IT does not say for what to >>> ignore it. >>> >>>> But I admit this point may be subtle and can easily be >>>> misunderstood. RFC4862 tried to clarify that subtlety a bit in >>>> the following paragraph of that section (that was actually >>>> written by me): >>>> >>>> It is the responsibility of the system administrator to ensure >>>> that the lengths of prefixes contained in Router Advertisements >>>> are consistent with the length of interface identifiers for that >>>> link type. It should be noted, however, that this does not mean >>>> the advertised prefix length is meaningless. In fact, the >>>> advertised length has non-trivial meaning for on-link >>>> determination in [RFC4861] where the sum of the prefix length >>>> and the interface identifier length may not be equal to 128. >>>> Thus, it should be safe to validate the advertised prefix length >>>> here, in order to detect and avoid a configuration error >>>> specifying an invalid prefix length in the context of address >>>> autoconfiguration. >>> >>> It reads reasonable. But the other paragraph requiring to ignore >>> the PIO which is non 64 is still there. These two paragraphs are >>> contradictory. >>> >>> One requires consistency, the other requires 64. >>> >>> We are going to write the same for IPv6 Addressing Architecture? >>> A paragraph requiring 64 and another requiring variable length? >>> >>>> but this conversation seems to suggest it's still not clear >>>> enough. >>> >>> BEcause when writing RFCs it is not by adding paragraphs that >>> things get clearer. Clarification paragraphs may be good, but >>> often removing some paragraphs can also improve clarity. >>> >>> There are readers out there, most often the programmers. They >>> dont care about the earlier discussion involving pride and other >>> feelings. They want consistency - things that can be easily >>> implemented. >>> >>>>> As such, either rfc4862 or rfc4861 should be modified to make >>>>> it work together. >>>> >>>> 4861 and 4862 already work together. But, we could make it even >>>> clearer that prefix length validation for on-link determination >>>> (actually there's no restriction for this) and prefix length >>>> validation for SLAAC are independent, if and when we want to >>>> update these RFCs. >>>> >>>>> Maybe rfc4862 should not require the Host to refuse a received >>>>> plen+IID not making for 128. >>>> >>>> No, it should still require that, as there's currently no defect >>>> in the spec even if it may still not be crystal clear for some. >>>> However, you have the right to propose loosening the >>>> requirement, so if you think that change is necessary, please >>>> feel free to write a draft. >>> >>> Ah this invitation. The title reads great! "Mistery of...". >>> Thanks, but no, not at this time :-) >>> >>>>>> It's also correct to ignore that prefix for SLAAC per RFC4862 >>>>>> (not 4861). >>>>> >>>>> If some RFC requires the Host to ignore the PIO and some other >>>>> RFC requires the Host to interpret it, and both RFCs are >>>>> mandatory to implement, under the same conditions, isn't there >>>>> a conflict? >>>> >>>> No, there's no conflict, once one understands the two types >>>> validations are independent: >>>> >>>> - RFC4861 does not impose any restriction on the prefix length >>>> in PIO for on-link determination purpose (and therefore the host >>>> is expected to accept any length of prefix for on-link >>>> determination) - RFC4862 requires the host to ignore the PIO of >>>> some particular length for the purpose of SLAAC (and therefore >>>> the host is expected to not use a prefix of "invalid length" to >>>> configure an address) >>>> >>>> Both can coexist. BSDs literally implement it. From your >>>> previous message, I guess so does Linux. I also suspect so do >>>> other major OS implementations such as Windows or Solaris, as >>>> this separation has been in fact one of common test cases in >>>> IPv6 protocol conformance test suites. >>> >>> Ok. >>> >>> Alex >>> >>>> >>>> -- JINMEI, Tatuya >>>> >>> >>> -------------------------------------------------------------------- >>> >>> >>> > IETF IPv6 working group mailing list >>> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >>> >>> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Mar 4 04:58:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FA21295B2 for ; Sat, 4 Mar 2017 04:58: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 autolearn_force=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 f0MCSNnekP17 for ; Sat, 4 Mar 2017 04:58:34 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5D985129596 for ; Sat, 4 Mar 2017 04:58:34 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1ck9Ga-0000GJC; Sat, 4 Mar 2017 13:58:32 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> In-reply-to: Your message of "Sat, 4 Mar 2017 13:24:49 +0100 ." Date: Sat, 04 Mar 2017 13:58:31 +0100 Archived-At: Cc: Alexandre Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 12:58:36 -0000 >I agree with the IPv6 facility to have many on-link prefixes. IPv4 does >it too these days anyways. > >But I do not agree with mandating there to be multiple on-link prefixes. Currently at home I have 4 different /64 prefixes as onlink (in addition to link local). I think all implementations should support that. >The fe80::/64 is there by default. Just a note, my stack considers fe80::/10 as onlink. There is no fe80::/64 in my stack. Of course addr. conf has to treat link local special. But that is already spelled out in the RFC. >So if I add a 2001:db8:abba:abb*::/60 on some computer it will get two >different onlink prefixes with different prefix lengths. So in my implementation adding a /64 creates two different prefix sizes. It is not clear to me why you would care. >Two is too much, because it means ND messages for that /64. That is >noise that can create interference. Onlink prefixes don't generate traffic. It is only when you use them to configure addresses or when addresses covered by the prefix are the destination of a packet. But that is exactly the way it should be. >Ideally, freedom from /64 means that I would only have that /60 prefix >on the link if that's what I mnaually added. True, you should be able to consider a /60 onlink. >To realize that freedom (avoid ND noise for /64) I have to add the /60 >_and_ delete the /64. Address configuration should not create onlink prefixs, so I'm not sure where the /64 comes from. From nobody Sat Mar 4 09:15:01 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C51A1294E8; Sat, 4 Mar 2017 09:14:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Susan Hares To: Subject: Review of draft-ietf-6man-rfc1981bis-04 X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148864769030.23464.9110014115039938058.idtracker@ietfa.amsl.com> Date: Sat, 04 Mar 2017 09:14:50 -0800 Archived-At: Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc1981bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 17:14:50 -0000 Reviewer: Susan Hares Review result: Has Issues ack, Steve,Jeffrey, and Bob: Thank you for taking on this important revision to the document. I hope my comments help to improve the document so this important change can ge deployed. I have reviewed this as part of the routing directorate review. This review should be treated as any IETF LC comments. Sue Hares RTG-DIR Review Status: I have three concern plus editorial nits. #1 - Concern 1 is technical regarding the interaction with the MTU option in ND/SEND plus ditorial nits. See the comments below. I am not an ND/SEND Expert, please have an imoplementer look at the requirements. Concern: I cannot tell how this interacts with the ND/SEND protocol in the following areas below. 1) Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes, including host-to-host, host-to-router, and router-to-host communication. If the source node is on the link and the destination node available through the router, and the router is in the process of sending a MTU option to increase the size? How does your algorithm work? Are the packetization layer notified? Is the original value a stale notification over time? You indicate it MUST NOT be done in less than 5 minutes, and that 10 minutes is the norm. Is 10 minutes really the best response time for this particular case? Or did I miss something in your draft? 2) Assume the same situation as #1, but the router sends an MTU option to decrease the size. In this case, the router is sending information that the MTU has changed, but the first indication for the end system is based on a Packet-too-Big Message after sending. 3) For a multicast packet (3000 bytes), assume that the multicast path reaches two different routers (router-a and router-b). Assume the on-link MTU is 3500 bytes, but the previous router-A and router-B MTU is 2500 bytes. Router-a responds to the packet with 10ms sending a MTU option that changes the MTU to support this packet. Router-B sends a redirect for multicast address to Router-A after 30 ms. What happens to your path calculation? Is this again, the 5 minutes (minimum) and 10 minute normal to reset this value. 4) What happens if the ND process is instantiated by SEND protocol, and the host does not contain the appropriate certification information to timely updates? Again, the host guessing at the appropriate value? #2 - Concern 2 - How does SEND's implementation of MTU option. mitigate or have no effect on this MTU. Is there a recommendation that should be made in section 6. Again, please ask a SEND expert for review. #3 - Concern 3 - content of document This document has two parts: protocol requirements and implementation requirements. 8 paragraphs (1 page) indicates the IPv6 specification and 6 pages gives the implementation? Why did this get split in to 2 documents? Even if this was a bis, document would it not be better to provide minimal specification for the protocol change and a larger document with implementation information. I'm fine with the WG/ADs deciding, this is the way the document has to go forward -- but the question should be asked. Editorial nits: #1 nit - section 5.2 page 8, paragraph beginning Old /Note: if the / New/Note: If the/ #2 nit - section 5.2 page 9 paragraph begin Old /Note: even if/ New /Note: Even if/ #3 nit - section 5.3 page 10 paragraph beginning Old /Note: an implementation/ New/Note: An implementation/ From nobody Sat Mar 4 11:29:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C40129594 for ; Sat, 4 Mar 2017 11:29: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 p-3-739kjieV for ; Sat, 4 Mar 2017 11:29:49 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18261294F7 for ; Sat, 4 Mar 2017 11:29:49 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id 25so54259720pgy.0 for ; Sat, 04 Mar 2017 11:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fF5vQAGrpv3v6rKCJG/D3op5OTYyN+u4Z6964R3LF5c=; b=B0JG9nu/pUAQJCFJGCckh89m3iYLa/RjDLBRTiW61LiHO8a40k6kimYzFQqXNzjdgB P9azSnrsXtLe791zY2qwsNM7WWRQRbpLtx3dgKebc3pmXmswU9Oe4S9ju5kIihw2UC5J lrFZxubyZsc3kwagROsDOwFyBYPRcGrB/9+6R92z6kxv+Qw9GKrNMR7mNrRjIDZ9h1Yn WJu9f6UUkEAQvtXPg/o9G+qPydHAZTK84EYWoswMYhWrebg+583tOQnrcOuSQm8ZPIl3 q71qs2D+2K9S/itIW0KLZwyM9gG8oitVdnuQL4owNKjQrrTDeGfGk0YexXCCgwwVLX/T QHiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=fF5vQAGrpv3v6rKCJG/D3op5OTYyN+u4Z6964R3LF5c=; b=TlXNOq4R7MWPVLtp+eNNKiaBv8mMu854DFIXdT4NBULcpnX4zVgH2MN01DfXK1ehkF 3DZsPkJ0ephvpaRxn7E+BcieBTT3cFfkhMQ3FYWYmfenO6wEe9eYnrYCGELdxj7JSaIx aCIayfYBkzpZhYEbQcqk6hrPqZwNUm/4E0ffc9g8++99gFPecdaCn0V+rt1XCeUbq3ez hT+NPVOwUVRznv42c6dCGt+qam2SGKzb8UwxW1MelRb0eMVUK53d9jAaIpZID9lsmyfi Pcxj197vtnCvqfbZ6qqx5ilP2qi0Dj4MitndgqkDmBzDLj8ADeQySNdxBTuO+YNquNkc /KbA== X-Gm-Message-State: AMke39lUopTibjO+vo3Epu/k1eHpytgV+XRmSSptxwID8eXXf3V76SO8Dgu4H8UDm5DRHw== X-Received: by 10.84.224.74 with SMTP id a10mr14115867plt.28.1488655789250; Sat, 04 Mar 2017 11:29:49 -0800 (PST) Received: from ?IPv6:2406:e007:7204:1:28cc:dc4c:9703:6781? ([2406:e007:7204:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y21sm30789530pgh.52.2017.03.04.11.29.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Mar 2017 11:29:48 -0800 (PST) Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes To: Alexandre Petrescu References: <20170223134026.GI5069@gir.theapt.org> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com> <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <401d81b3-f8e5-d38c-826b-167ca6b1f917@gmail.com> Date: Sun, 5 Mar 2017 08:29:44 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 19:29:51 -0000 On 05/03/2017 01:09, Alexandre Petrescu wrote: > Fred, >=20 > I think the problem I have - agreed, on my side - is that "fe80::/10" i= s > sometimes read as a link-local address, other times as a prefix > configured on a computer, other times as just the first 10bits of an LL= > address. It's a prefix. ("Point, =C3=A0 la ligne.", comme on dit en francais.) The problem isn't there. It's that in a router, a prefix is the thing you perform longest match against. In a host, it's what you use in source address selection, next-hop router selection, and on-link determination, and during address auto-configuration. So it has many roles. And fe80::/x is just a special case. No way round that. Also, it's meaningless without an interface, but we don't write fe80::/10%eth0. Brian From nobody Sun Mar 5 04:39:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049611295C1 for ; Sun, 5 Mar 2017 04:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 1sUfBK9eK2Ph for ; Sun, 5 Mar 2017 04:39:47 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CB81294E4 for ; Sun, 5 Mar 2017 04:39:46 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v25Cdjmt012642; Sun, 5 Mar 2017 13:39:45 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 154B5204692; Sun, 5 Mar 2017 13:39:45 +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 075432029DB; Sun, 5 Mar 2017 13:39:45 +0100 (CET) Received: from [132.166.84.87] ([132.166.84.87]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v25CdiY2003043; Sun, 5 Mar 2017 13:39:44 +0100 Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes To: Brian E Carpenter References: <20170223134026.GI5069@gir.theapt.org> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com> <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com> <401d81b3-f8e5-d38c-826b-167ca6b1f917@gmail.com> From: Alexandre Petrescu Message-ID: <42a4a6df-cc25-765f-b7c7-650601f72670@gmail.com> Date: Sun, 5 Mar 2017 13:39:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <401d81b3-f8e5-d38c-826b-167ca6b1f917@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 12:39:48 -0000 Le 04/03/2017 à 20:29, Brian E Carpenter a écrit : > On 05/03/2017 01:09, Alexandre Petrescu wrote: >> Fred, >> >> I think the problem I have - agreed, on my side - is that >> "fe80::/10" is sometimes read as a link-local address, other times >> as a prefix configured on a computer, other times as just the first >> 10bits of an LL address. > > It's a prefix. ("Point, à la ligne.", comme on dit en francais.) > > The problem isn't there. It's that in a router, a prefix is the > thing you perform longest match against. In a host, it's what you use > in source address selection, next-hop router selection, and on-link > determination, and during address auto-configuration. So it has many > roles. YEs, it has many roles. An additional role is that of recognising an address based on its X leading bits. Even though the prefix of that address is not only its X leading bits. This is in itself confusing. > And fe80::/x is just a special case. No way round that. ...there are so many special cases: fc00 an fd00 meaning the same, the ::/0, the 1::1/128 meaning an address _and_ a prefix, and so on. > Also, it's meaningless without an interface, but we don't write > fe80::/10%eth0. I think that %iface should be mandatory in notation of LLs. Otherwise there can be collision. Alex > > Brian > > From nobody Sun Mar 5 16:14:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B948912955D for ; Sun, 5 Mar 2017 16:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZtMRubDag5le for ; Sun, 5 Mar 2017 16:14:43 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FC012956A for ; Sun, 5 Mar 2017 16:14:43 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ckgIT-0001Za-Rn for ipv6@ietf.org; Mon, 06 Mar 2017 01:14:42 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ckgIS-0006WS-Cr for ipv6@ietf.org; Sun, 05 Mar 2017 19:14:41 -0500 Received: (qmail 28960 invoked from network); 6 Mar 2017 00:14:40 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.251]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Mar 2017 00:14:39 -0000 To: Alexandre Petrescu , Brian E Carpenter References: <20170223134026.GI5069@gir.theapt.org> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com> <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com> <401d81b3-f8e5-d38c-826b-167ca6b1f917@gmail.com> <42a4a6df-cc25-765f-b7c7-650601f72670@gmail.com> From: Christian Huitema Message-ID: Date: Sun, 5 Mar 2017 16:14:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <42a4a6df-cc25-765f-b7c7-650601f72670@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.03) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpzB+mA2qyGiWpshqM7KdLERcOb18WfxGyg6Om6u4YYm487AErZRllNtCvl HaELcsU5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+g3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0rVi/LFcx xQic0uvot497+7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWHxcEeYXaEh7Ip8nBmIzXZwpqT8auRNlXQctohljUCg+Z9KJloL0zOKsR tQI96RZLKhBaevb8pkwVq3+XN9bPyjRMyLUEno1frs9vZR0iI5iTGneI1cCMIcE6R6jtJ8btb7sy ltanepIHrA9+HqSAzfrQq23LWyXZeC7ahMm5trYQxK4Q6pnz1PG2i0Jcu7De X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 00:14:46 -0000 On 3/5/2017 4:39 AM, Alexandre Petrescu wrote: > > I think that %iface should be mandatory in notation of LLs. Otherwise > there can be collision. Mandatory in what context? The interface ID is only defined in the context of a machine. %Eth0 on one machine may designate the same link as %10 on another. -- Christian Huitema From nobody Mon Mar 6 09:19:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD6D1294EE for ; Mon, 6 Mar 2017 09:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 vlRGhY059jZU for ; Mon, 6 Mar 2017 09:19:19 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88282129497 for ; Mon, 6 Mar 2017 09:19:19 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id v190so26129922pfb.1 for ; Mon, 06 Mar 2017 09:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=yv8rMFrM3YJtTELNoQlHLVvxCMjALUM3b5UFrBNGZdE=; b=A2tqMTkmCNy2/aJjexU3So3bjDcNxZas/tOGYUl5u56LUaHImbeC4jkIqIfvr11MUc 9/t607T9Dq8Y/IfULJ7myD+pF25qreABCA6pQqjlLPjpQtSap/GvXzkRtOuuf18nD08r WjRg3P9BaCxGiWAOYbVHL+B4ic/O16rRS9Iopno42lqfa78ldr2MjmJvrNp/omRcfU19 ClGqRAaWGBIzax8hcvjBKIibUDB7TBS7jhD2ZAeAK1Yzsl+BhE3klmPLPS/rBM6mM/db IijyEE1sjmx2hWtOELDGR1YEbHL19yS0tCZMRTrXt4+CW9Sow3zxn3mtyeID/0hVxy/6 lHrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=yv8rMFrM3YJtTELNoQlHLVvxCMjALUM3b5UFrBNGZdE=; b=N+RG1qmG049bW2XTKru1mSRFOCAyXDT9lJM5G3JGNUT6s9QW8U6VO/7lQDAHVJE/Fk YMER/DpA3XJIx8arE+lor41hbJNTDurFOVpVBXBZdEc4Z/8xQHy1hgp3ZoH0d+V/H5p+ cofBpkBRtq9TTwuHWjumsIPUYH3bMvibCDGnfpB27dWyF8IfB8umUPJzBZ9M8li6CZVe td9w/WjBhKBMt5C0Son2akawxFyg+pBwLXP4Y7sXbMHgxYB0LE78czWNkCKUvx0hQQxg IbwPb5yDpXnWV7knYTcMwr6twuX2FblfErZjcbuhriyIyyxn7+cTluefGtKT5QdowN3h nopg== X-Gm-Message-State: AMke39m/uCkuDTCjuQLIgvphcJglHxh+qKSL+Z7Ezd4v+ffeP+c7qYDn9aZxN7AkbILRtUBZ X-Received: by 10.98.252.211 with SMTP id e202mr22255005pfh.118.1488820758960; Mon, 06 Mar 2017 09:19:18 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id q194sm40726047pfq.43.2017.03.06.09.19.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 09:19:18 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_65693B11-08D9-4435-A259-9568F5ACAA0F" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 Date: Mon, 6 Mar 2017 09:19:26 -0800 References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> To: Philip Homburg , 6man WG In-Reply-To: Message-Id: <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 17:19:21 -0000 --Apple-Mail=_65693B11-08D9-4435-A259-9568F5ACAA0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 4, 2017, at 01:15, Philip Homburg = wrote: > [I wrote:] >> If you send me a Prefix Length other than 64 bits, then I'm gonna = ignore it. Just as RFC 4862 commands. >=20 > I find this confusing, you are ignoring an onlink prefix because of = auto configuration? [=E2=80=A6] I found it confusing at first too, but the RFC 2119 keyword language in = RFC 4862 is pretty unambiguous, and it makes sense too if you think = about PIO updates that only change the lifetimes and the value of the A = flag. The requirement to drop all PIO with invalid prefix length for the = link type, regardless of the A flag, ensures with a simple-to-implement = rule that you never take a misconfigured prefix as on-link if you cannot = ever auto-configure an address in the prefix when the update to A=3D1 = arrives. This may not be the behavior you=E2=80=99d prefer that RFC 4862 require, = but the requirement is clearly there and certification tests are within = their ambit to check for it. Moreover, this proposed successor to RFC = 4291 doesn=E2=80=99t even have an informative reference to RFC 4862 in = it, much less an explicitly declared update. And I don=E2=80=99t believe = it should. --james woodyatt > --Apple-Mail=_65693B11-08D9-4435-A259-9568F5ACAA0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 4, 2017, at 01:15, Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com> wrote:
    [I = wrote:]
    If you send me a Prefix Length other than 64 = bits, then I'm gonna ignore it. Just as RFC 4862 = commands.

    I find this = confusing, you are ignoring an onlink prefix because of = auto configuration? [=E2=80=A6]

    I found it confusing at first too, but = the RFC 2119 keyword language in RFC 4862 is pretty unambiguous, and it = makes sense too if you think about PIO updates that only change the = lifetimes and the value of the A flag. The requirement to drop all PIO = with invalid prefix length for the link type, regardless of the A flag, = ensures with a simple-to-implement rule that you never take a = misconfigured prefix as on-link if you cannot ever auto-configure an = address in the prefix when the update to A=3D1 arrives.

    This may not be the = behavior you=E2=80=99d prefer that RFC 4862 require, but the requirement = is clearly there and certification tests are within their ambit to check = for it. Moreover, this proposed successor to RFC 4291 doesn=E2=80=99t = even have an informative reference to RFC 4862 in it, much less an = explicitly declared update. And I don=E2=80=99t believe it = should.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_65693B11-08D9-4435-A259-9568F5ACAA0F-- From nobody Mon Mar 6 10:06:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E1712957D for ; Mon, 6 Mar 2017 10:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 xnSdJ_kvgNaZ for ; Mon, 6 Mar 2017 10:06:34 -0800 (PST) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EC41294FA for ; Mon, 6 Mar 2017 10:06:34 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 96CE469F for ; Mon, 6 Mar 2017 18:06:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF-08WaJOy31 for ; Mon, 6 Mar 2017 12:06:33 -0600 (CST) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 450A6603 for ; Mon, 6 Mar 2017 12:06:33 -0600 (CST) Received: by mail-ua0-f198.google.com with SMTP id 62so52227274uas.1 for ; Mon, 06 Mar 2017 10:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:from:date:message-id:subject:to; bh=cVZFF9NR4V4uhcQwv7Ge40omrJVYCqmUhY7TWDaZqcQ=; b=Mv2gv7NUO15VGanSYarUnLPvKp1vSblje0trY9xGAnzLaTEYG9IqRtTtHkdyI92RDe FWxsYWY6PzYQJM9o7QE71eCEQsK9GmfJ8AUVXFIfwB+HJ4Rct5oCD5vxEOoPrTMyAhNL gOCWupowwJO+HOy3KXUTnWVof9FbIo2XKViq77DTZ03tL+t4aMX3YeMnJGEO7aC0jByZ LhjuJQjbLTmiF28bPgQmJAJjhswHeJVbC+DB7aDyR2xQquwKRqaieoxSoEARzDpRSK/L lUHn+9lH2SIiTBOcPubgcS2dqOhQyHIJzzkNM7bk9xU2z3G8SSZxhTGpTO19kSZl7BzM +ceA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cVZFF9NR4V4uhcQwv7Ge40omrJVYCqmUhY7TWDaZqcQ=; b=O3w4CxV+8et+f8MjKiL1MVrHIqwa767tx2x9njpkanIKHI7MTy6DQiP4gG1IyTTz/r PDMoudiIysK1OVHLpu2AS0314bttzzeZQNbr7kHN26vb7VVeCFwMZEkh0/7KBoQcyIaN 8lazzLearcPcEh4XdwQ+4b58meiW8Zh9zFQV8Nac5o6ylKhsQd/77+C8AVI8791+fg77 XPs0SQaOiMoqTWoyJLvwFYth3GsF6NKuga4YXPjTTzaRtzaMzc0VbuXQtxqPzbIm7J0h bT2VvigD7Kyu3+PP3ydmgVzMfvlKX53UzwieLNIqvT9Z0SPcpIVdYMDBQTCi5sMH/LLc 6ENw== X-Gm-Message-State: AMke39kw1XhPl1kH7BrmXTruznInPKgGonqwYi9PygGb6PVR53nFb5aJE6QAm63f8DcBiycTN/CaKRCEaFMmptcKKt/pmgkPgE5P5wlVErU9E/8V5sVkQUy95U5xtLI0ZX8oaF5gkW6DqfMTU7s= X-Received: by 10.176.5.136 with SMTP id e8mr8261290uae.108.1488823592360; Mon, 06 Mar 2017 10:06:32 -0800 (PST) X-Received: by 10.176.5.136 with SMTP id e8mr8261271uae.108.1488823591995; Mon, 06 Mar 2017 10:06:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.134.129 with HTTP; Mon, 6 Mar 2017 10:06:31 -0800 (PST) From: David Farmer Date: Mon, 6 Mar 2017 12:06:31 -0600 Message-ID: Subject: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: 6man WG Content-Type: multipart/alternative; boundary=94eb2c12487455a16f054a13c1ee Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:06:36 -0000 --94eb2c12487455a16f054a13c1ee Content-Type: text/plain; charset=UTF-8 A few more tweaks, corrections and other changes some based on feed back; 1. IPv6 unicast routing is 128 bits in length [BCP198]/[RFC7608], AKA not classful! 2. SLAAC is commonly used to generate unicast addresses, therefore subnet prefixes and IIDs are 64 bits for most address. 3. Explicitly allow subnet prefix lengths other than 64 bits for manually config and DHCPv6 while still recommending 64 bits (most code does this now and has since the beginning) 4. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by an IPv6-over-foo doc (we really can't change 64 bit IIDs for SLAAC, it would break running code, at least not right now, maybe in the future) 5. Sites should get more than a single /64 [BCP157]/[RFC6177], and sites include mobile 6. Avoid other explicit exceptions or recommendations for longer prefixes, like RFC6164 7. include references to [BCP204]/[RFC7934] and [RFC6052] in the right places In the current draft, remove the 2nd paragraph of 2.4, then add the following sentence to the end of the first paragraph of 2.4; Furthermore, IPv6 unicast routing is based on prefixes of any length up to 128 bits [BCP198]. Then add the following two paragraphs at the end of section 2.4; Stateless Address Autoconfiguration(SLAAC)[RFC4862] is commonly used to automatically create unicast addresses, therefore most unicast addresses have 64-bit subnet prefixes and 64-bit interface IDs. The rationale for the 64-bit boundary in IPv6 addresses can be found in [RFC7421]. Nevertheless, unicast addresses may also be provided from a node's internal configuration (AKA manual or static configuration) or via Dynamic Host Configuration Protocol version 6(DHCPv6)[RFC3315]. Such addresses are assumed to be opaque 128-bit strings without any internal structure. These addresses may be associated with subnet prefixes of any length, while 64-bit subnet prefixes are recommended. Then replace the 4th paragraph of 2.4.1 with; When unicast addresses are automatically created from a subnet prefix and a interface ID (e.g. Stateless Address Autoconfiguration(SLAAC) [RFC4862]), a 64-bit interface ID length is required. An "IPv6 over " specification may modify this requirement for a specific link type. The rationale for the 64-bit boundary in IPv6 addresses can be found in [RFC7421]. And replace 2.4.4 with; The general format for IPv6 Global Unicast addresses is as follows: | n bits | m bits | 128-n-m bits | +------------------------+-----------+----------------------------+ | global routing prefix | subnet ID | interface ID | +------------------------+-----------+----------------------------+ where the global routing prefix is a (typically hierarchically- structured) value assigned to a site (a cluster of subnets/links in a location or mobile), the subnet ID is an identifier of a link within the site, and the interface ID is as defined in Section 2.4.1. As noted in Section 2.4, most unicast addresses, including Global Unicast addresses, have 64-bit interface IDs (i.e., n + m = 64). As discussed in [BCP 157], "it should be easy for an end site to obtain address space to number multiple subnets (i.e., a block larger than a single /64)" or in other words the subnet ID length should be greater than or equal to 1 (i.e., m >= 1). Subnet ID lengths of 4, 8, 12, and 16 bits, and therefore global routing prefix lengths of 60, 56, 52, and 48 bits respectively, are in common use and recommended. Dynamic Host Configuration Protocol version 6 - Prefix Delegation (DHCPv6-PD)[RFC3633] is commonly used to automate the distribution of global routing prefixes to sites. Global Unicast addresses, and their format, are discussed further in [RFC3587]. A couple other quickies; Insert new paragraph at the end of 2.1 [BCP 204] recommends that networks provide general-purpose nodes with multiple global IPv6 addresses per interface when they attach to a link, it also describes the benefits of and the options for doing so. Insert new sentence at the end of 2.4.5 Additional IPv6 address that carry an IPv4 address are defined in IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c12487455a16f054a13c1ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    A few more tweaks, correc= tions and other changes some based on feed back;

    = 1. IPv6 unicast routing is 128 bits in length [BCP198]/[RFC7608], AKA not c= lassful!
    2. SLAAC is commonly used to generate unicast addresses,=C2=A0therefore subnet prefixes and IIDs are 64 bi= ts for most address.
    3. Explici= tly allow subnet prefix lengths other than 64 bits for manually config and = DHCPv6 while still recommending 64 bits (most code does this now and has si= nce the beginning)
    4. IID= s of 64 bit are REQUIRED for SLAAC, except when overridden by an IPv6-over-= foo doc =C2=A0(we really can't change 64 bit IIDs for SLAAC, it would b= reak running code,=C2=A0at least no= t right now, maybe in the future)
    5. Sites should get more than a single /64 [BCP157]/[RFC6177], and sites= include mobile
    6. Avoid other e= xplicit exceptions or recommendations for longer prefixes, like RFC6164=C2= =A0
    7. include references to [B= CP204]/[RFC7934] and [RFC6052] in the right places

    In the current draft, remove the 2nd p= aragraph of 2.4, then add the following sentence to the end of the first pa= ragraph of 2.4;

    =C2=A0 =C2=A0Furthermore, IPv6 unicast routing is ba= sed on prefixes of any length up to 128 bits
    =C2=A0 =C2=A0[BCP198].

    Then add the following two paragraphs at the end of section 2.4;<= /div>
    =C2=A0 =C2=A0Stateless Address Autoconfiguration(SLAAC)[RFC4862] i= s commonly used
    =C2=A0 =C2=A0to automatically create unicast addresses,= therefore most unicast
    =C2=A0 =C2=A0addresses have 64-bit subnet prefix= es and 64-bit interface IDs. The
    =C2=A0 =C2=A0rationale for the 64-bit b= oundary in IPv6 addresses can be found in
    =C2=A0 =C2=A0[RFC7421].
    <= div>
    =C2=A0 =C2=A0Nevertheless, unicast addresses may also be provi= ded from a node's
    =C2=A0 =C2=A0internal configuration (AKA manual or= static configuration) or via
    =C2=A0 =C2=A0Dynamic Host Configuration Pr= otocol version 6(DHCPv6)[RFC3315]. Such
    =C2=A0 =C2=A0addresses are assum= ed to be opaque 128-bit strings without any
    =C2=A0 =C2=A0internal struc= ture. These addresses may be associated with subnet
    =C2=A0 =C2=A0prefix= es of any length, while 64-bit subnet prefixes are recommended.
    <= br>Then replace the 4th paragraph of 2.4.1 with;

    =C2=A0 =C2=A0When u= nicast addresses are automatically created from a subnet prefix
    =C2=A0 = =C2=A0and a interface ID (e.g. Stateless Address Autoconfiguration(SLAAC)=C2=A0 =C2=A0[RFC4862]), a 64-bit interface ID length is required. An &qu= ot;IPv6 over
    =C2=A0 =C2=A0<link>" specification may modify t= his requirement for a specific link
    =C2=A0 =C2=A0type. The rationale fo= r the 64-bit boundary in IPv6 addresses can be
    =C2=A0 =C2=A0found in [R= FC7421].

    And replace 2.4.4 with;

    =C2=A0 =C2=A0The general f= ormat for IPv6 Global Unicast addresses is as follows:

    =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 n bits =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 m= bits =C2=A0| =C2=A0 =C2=A0 =C2=A0 128-n-m bits =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
    =C2=A0 =C2=A0+------------------------+-----------+------------------= ----------+
    =C2=A0 =C2=A0| global routing prefix =C2=A0| subnet ID | =C2= =A0 =C2=A0 =C2=A0 interface ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 =C2= =A0+------------------------+-----------+----------------------------+

    =C2=A0 =C2=A0where the global routing prefix is a (typically hier= archically-
    =C2=A0 =C2=A0structured) value assigned to a site (a cluster= of subnets/links in
    =C2=A0 =C2=A0a location or mobile), the subnet ID i= s an identifier of a link
    =C2=A0 =C2=A0within the site, and the interfac= e ID is as defined in Section 2.4.1.

    =C2=A0 =C2=A0As noted in Sectio= n 2.4, most unicast addresses, including Global
    =C2=A0 =C2=A0Unicast add= resses, have 64-bit interface IDs (i.e., n + m =3D 64).

    =C2=A0 =C2= =A0As discussed in [BCP 157], "it should be easy for an end site to=C2=A0 =C2=A0obtain address space to number multiple subnets (i.e., a bloc= k larger
    =C2=A0 =C2=A0than a single /64)" or in other words the sub= net ID length should be
    =C2=A0 =C2=A0greater than or equal to 1 (i.e., m= >=3D 1). Subnet ID lengths of 4, 8,
    =C2=A0 =C2=A012, and 16 bits, an= d therefore global routing prefix lengths of 60,
    =C2=A0 =C2=A056, 52, an= d 48 bits respectively, are in common use and recommended.

    =C2=A0 = =C2=A0Dynamic Host Configuration Protocol version 6 - Prefix Delegation
    = =C2=A0 =C2=A0(DHCPv6-PD)[RFC3633] is commonly used to automate the distribu= tion of
    =C2=A0 =C2=A0global routing prefixes to sites.

    =C2=A0 = =C2=A0Global Unicast addresses, and their format, are discussed further in<= br>=C2=A0 =C2=A0[RFC3587].

    A couple other quickies;
    <= br>Insert new paragraph at the end of 2.1

    =C2=A0 =C2=A0[BCP 204] rec= ommends that networks provide general-purpose nodes with
    =C2=A0 =C2=A0mu= ltiple global IPv6 addresses per interface when they attach to a
    =C2=A0= =C2=A0link, it also describes the benefits of and the options for doing so= .

    Insert new sentence at the end of 2.4.5

    =C2=A0 =C2=A0Addit= ional IPv6 address that carry an IPv4 address are defined in IPv6
    =C2=A0= =C2=A0Addressing of IPv4/IPv6 Translators [RFC6052].

    Thanks

    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Email:fa= rmer@umn.edu
    Networking & Telecommunication Services
    Office o= f Information Technology
    University of Minnesota=C2=A0=C2=A0
    2218 Un= iversity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --94eb2c12487455a16f054a13c1ee-- From nobody Mon Mar 6 10:46:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C0129962 for ; Mon, 6 Mar 2017 10:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 5rlYPFNza2Cp for ; Mon, 6 Mar 2017 10:46:23 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E910129967 for ; Mon, 6 Mar 2017 10:46:23 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id f54so179159831uaa.1 for ; Mon, 06 Mar 2017 10:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xuUTSQ0mU/qsE5OusBNSeqU1HSwnHg9sehsgBqTwe28=; b=WnPgqZm8UMTamGVMVjxodQEMIgOiqapgA2mNRajekQUHs/NleKYeZhgO9+iiVCS8L9 w5BFEW86ojPyThs6buTnquHbjsUAe9bvgs7/46HuxZ5INlJoKxuzd06pRHnHXXhgTJjZ MnvILgp1cyMcpZ094s4zMftxB4fNp62CjY6T9xsDTPGE1iZ1uzggSheFQ1TyAu+DUoeX zTUYOp9wB/7d/hC3/BZ7yy6aHJ+l3JLI0uMB2og4Zkgyce26Ij1RWLfXUWHKAXs3yVoO 1pnZKMsQFxZDg3hXJ4ddAIg6GCcCQWywdPW1//tV1a6I1ncJETwrZ0gqe5LU3o0GuJBu 0+Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xuUTSQ0mU/qsE5OusBNSeqU1HSwnHg9sehsgBqTwe28=; b=hJHbHDf3c0cCtwnCjMd+1RYG7xCRkaMM2YygQBr1u3LSPmG+KXXYxMYm9TqqZWWWO0 XFb1YYeg8VL3fg/kl96kTCS7ttMu4vmYw8ZsnsXTkhr2DXaVJav3LiRWtohZZMwnsyH9 MMeM/vWBDawKAmy6ih51yV4oDJsQrHoKz4qo7k+ciTygnsAdmmbH1+uNNWEUNsH/ppDQ iAseZNMkrTodA8tlEzAN/AxtFcy+yyf2nwtFyK3V4OX6EfrGRXHlO2LO7Ke77BC70FxH rgukQI6v+/XDOKRa5SgzhFCImfZk1YFyue+F8WB9sbjJd97kFiC2o2i2dj6+PTQ428Kh 8Gsg== X-Gm-Message-State: AMke39kkyzdaU2udRsSpVemA1bwwS+DeTY3jUfmTVJMzczAw8CKP8LXb1OnJ9ZPe9pcmPty/O0dlsreVkuluCNoR X-Received: by 10.176.1.5 with SMTP id 5mr7074029uak.30.1488825982065; Mon, 06 Mar 2017 10:46:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 6 Mar 2017 10:46:01 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 7 Mar 2017 03:46:01 +0900 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: David Farmer Content-Type: multipart/alternative; boundary=001a113d058ccb7fa5054a144f97 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:46:25 -0000 --001a113d058ccb7fa5054a144f97 Content-Type: text/plain; charset=UTF-8 Wow. That's a lot of for what started off as a reclassification. I don't think it's a good idea to attempt to wordsmith RFC4291 hoping that one of the formulations we end up with will somehow reach consensus. Instead, I would suggest another approach: see what the problems with 4291 are, *write them down*, and only then write a document explaining what should be changed and why. In other words: start with a problem statement. As for the suggestions themselves: I think allowing non-/64 prefix lengths on any network that provides service to general purpose hosts is a bad idea, regardless of whether it uses SLAAC, DHCPv6, or any other address assignment protocol (no objection to manual configuration). I think it will lead to some networks will shooting themselves in the foot, or, worse, impairing their users' connectivity by creating subnets that are too small. Before everyone rushes to tell me "nobody will do something that silly", "it's not the IETF's place to prevent people from doing something stupid", or even "I will recommend that to my competitors" - please think a little bit bigger. The reality is that there are lots of networks out there, and lots of administrators that have never read an RFC and will just copy over whatever configuration they have from IPv4. (I have a /24 today? Ok, so I need to use a /120. I have DHCPv4, so I should use DHCPv6 and everything will work. Easy!) There are also lots of host developers who are similarly uninformed, and will just try stuff until it works, or just port whatever code they have in IPv4 to IPv6. If we allow the boundary to change, there is a near certainty that too-small subnets *will* be configured in some places, and over time, host software will adapt to the lowest common denominator. There is a very real risk end up with solutions that "mostly work most of the time" - things like NAT traversal, and NAT keepalives - over more robust solutions that rely on strong guarantees from the network layer. The risk is that the IPv6 Internet will be constrained by IPv4 address scarcity even after IPv4 is gone. It's up to us to avoid that risk. I continue to be amazed by the people on this thread who are advocating that we run it. On Tue, Mar 7, 2017 at 3:06 AM, David Farmer wrote: > A few more tweaks, corrections and other changes some based on feed back; > > 1. IPv6 unicast routing is 128 bits in length [BCP198]/[RFC7608], AKA not > classful! > 2. SLAAC is commonly used to generate unicast addresses, therefore subnet > prefixes and IIDs are 64 bits for most address. > 3. Explicitly allow subnet prefix lengths other than 64 bits for manually > config and DHCPv6 while still recommending 64 bits (most code does this now > and has since the beginning) > 4. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by an > IPv6-over-foo doc (we really can't change 64 bit IIDs for SLAAC, it would > break running code, at least not right now, maybe in the future) > 5. Sites should get more than a single /64 [BCP157]/[RFC6177], and sites > include mobile > 6. Avoid other explicit exceptions or recommendations for longer prefixes, > like RFC6164 > 7. include references to [BCP204]/[RFC7934] and [RFC6052] in the right > places > > In the current draft, remove the 2nd paragraph of 2.4, then add the > following sentence to the end of the first paragraph of 2.4; > > Furthermore, IPv6 unicast routing is based on prefixes of any length up > to 128 bits > [BCP198]. > > Then add the following two paragraphs at the end of section 2.4; > > Stateless Address Autoconfiguration(SLAAC)[RFC4862] is commonly used > to automatically create unicast addresses, therefore most unicast > addresses have 64-bit subnet prefixes and 64-bit interface IDs. The > rationale for the 64-bit boundary in IPv6 addresses can be found in > [RFC7421]. > > Nevertheless, unicast addresses may also be provided from a node's > internal configuration (AKA manual or static configuration) or via > Dynamic Host Configuration Protocol version 6(DHCPv6)[RFC3315]. Such > addresses are assumed to be opaque 128-bit strings without any > internal structure. These addresses may be associated with subnet > prefixes of any length, while 64-bit subnet prefixes are recommended. > > Then replace the 4th paragraph of 2.4.1 with; > > When unicast addresses are automatically created from a subnet prefix > and a interface ID (e.g. Stateless Address Autoconfiguration(SLAAC) > [RFC4862]), a 64-bit interface ID length is required. An "IPv6 over > " specification may modify this requirement for a specific link > type. The rationale for the 64-bit boundary in IPv6 addresses can be > found in [RFC7421]. > > And replace 2.4.4 with; > > The general format for IPv6 Global Unicast addresses is as follows: > > | n bits | m bits | 128-n-m bits | > +------------------------+-----------+----------------------------+ > | global routing prefix | subnet ID | interface ID | > +------------------------+-----------+----------------------------+ > > where the global routing prefix is a (typically hierarchically- > structured) value assigned to a site (a cluster of subnets/links in > a location or mobile), the subnet ID is an identifier of a link > within the site, and the interface ID is as defined in Section 2.4.1. > > As noted in Section 2.4, most unicast addresses, including Global > Unicast addresses, have 64-bit interface IDs (i.e., n + m = 64). > > As discussed in [BCP 157], "it should be easy for an end site to > obtain address space to number multiple subnets (i.e., a block larger > than a single /64)" or in other words the subnet ID length should be > greater than or equal to 1 (i.e., m >= 1). Subnet ID lengths of 4, 8, > 12, and 16 bits, and therefore global routing prefix lengths of 60, > 56, 52, and 48 bits respectively, are in common use and recommended. > > Dynamic Host Configuration Protocol version 6 - Prefix Delegation > (DHCPv6-PD)[RFC3633] is commonly used to automate the distribution of > global routing prefixes to sites. > > Global Unicast addresses, and their format, are discussed further in > [RFC3587]. > > A couple other quickies; > > Insert new paragraph at the end of 2.1 > > [BCP 204] recommends that networks provide general-purpose nodes with > multiple global IPv6 addresses per interface when they attach to a > link, it also describes the benefits of and the options for doing so. > > Insert new sentence at the end of 2.4.5 > > Additional IPv6 address that carry an IPv4 address are defined in IPv6 > Addressing of IPv4/IPv6 Translators [RFC6052]. > > Thanks > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --001a113d058ccb7fa5054a144f97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Wow.= That's a lot of for what started off as a reclassification. I don'= t think it's a good idea to attempt to wordsmith RFC4291 hoping that on= e of the formulations we end up with will somehow reach consensus. Instead,= I would suggest another approach: see what the problems with 4291 are, *wr= ite them down*, and only then write a document explaining what should be ch= anged and why.

    In other words: start with a problem statement.

    As for the suggestions t= hemselves: I think allowing non-/64 prefix lengths on any network that prov= ides service to general purpose hosts is a bad idea, regardless of whether = it uses SLAAC, DHCPv6, or any other address assignment protocol (no objecti= on to manual configuration). I think it will lead to some networks will sho= oting themselves in the foot, or, worse, impairing their users' connect= ivity by creating subnets that are too small.

    Before everyone rushes to tell me &= quot;nobody will do something that silly", "it's not the IETF= 's place to prevent people from doing something stupid", or even &= quot;I will recommend that to my competitors" - please think a little = bit bigger. The reality is that there are lots of networks out there, and l= ots of administrators that have never read an RFC and will just copy over w= hatever configuration they have from IPv4. =C2=A0(I have a /24 today? Ok, s= o I need to use a /120. I have DHCPv4, so I should use DHCPv6 and everythin= g will work. Easy!) There are also lots of host developers who are similarl= y uninformed, and will just try stuff until it works, or just port whatever= code they have in IPv4 to IPv6. If we allow the boundary to change, there = is a near certainty that too-small subnets *will* be configured in some pla= ces, and over time, host software will adapt to the lowest common denominat= or. There is a very real risk end up with solutions that "mostly work = most of the time" - things like NAT traversal, and NAT keepalives - ov= er more robust solutions that rely on strong guarantees from the network la= yer. The risk is that the IPv6 Internet will be constrained by IPv4 address= scarcity even after IPv4 is gone.

    It's up to us to avoid that risk. I contin= ue to be amazed by the people on this thread who are advocating that we run= it.

    O= n Tue, Mar 7, 2017 at 3:06 AM, David Farmer <farmer@umn.edu> = wrote:
    A few m= ore tweaks, corrections and other changes some based on feed back;
    1. IPv6 unicast routing is 128 bits in length [BCP198]/[R= FC7608], AKA not classful!
    2. SLAAC is commonly used to generate unicast address= es,=C2=A0therefore subnet prefixes = and IIDs are 64 bits for most address.
    3. Explicitly allow subnet prefix lengths other than 64 bits for ma= nually config and DHCPv6 while still recommending 64 bits (most code does t= his now and has since the beginning)
    4. IIDs of 64 bit are REQUIRED for SLAAC, except when overridde= n by an IPv6-over-foo doc =C2=A0(we really can't change 64 bit IIDs for= SLAAC, it would break running code,=C2=A0at least not right now, maybe in the future)
    5. Sites should get more than a single /64 [BCP157]/[= RFC6177], and sites include mobile
    6. Avoid other explicit exceptions or recommendations for longer prefixe= s, like RFC6164=C2=A0
    7. includ= e references to [BCP204]/[RFC7934] and [RFC6052] in the right places=

    In the current draft= , remove the 2nd paragraph of 2.4, then add the following sentence to the e= nd of the first paragraph of 2.4;

    =C2=A0 =C2=A0Furthermore, IPv6 uni= cast routing is based on prefixes of any length up to 128 bits
    =C2=A0 = =C2=A0[BCP198].

    Then add the following two paragraphs at the = end of section 2.4;

    =C2=A0 =C2=A0Stateless Address Autoconfigurati= on(SLAAC)[RFC4862] is commonly used
    =C2=A0 =C2=A0to automatically = create unicast addresses, therefore most unicast
    =C2=A0 =C2=A0addresses = have 64-bit subnet prefixes and 64-bit interface IDs. The
    =C2=A0 =C2=A0r= ationale for the 64-bit boundary in IPv6 addresses can be found in
    =C2= =A0 =C2=A0[RFC7421].

    =C2=A0 =C2=A0Nevertheless, unicast = addresses may also be provided from a node's
    =C2=A0 =C2=A0internal c= onfiguration (AKA manual or static configuration) or via
    =C2=A0 =C2=A0Dy= namic Host Configuration Protocol version 6(DHCPv6)[RFC3315]. Such
    =C2= =A0 =C2=A0addresses are assumed to be opaque 128-bit strings without any =C2=A0 =C2=A0internal structure. These addresses may be associated with s= ubnet
    =C2=A0 =C2=A0prefixes of any length, while 64-bit subnet prefixes= are recommended.

    Then replace the 4th paragraph of 2.4.1 wit= h;

    =C2=A0 =C2=A0When unicast addresses are automatically created fro= m a subnet prefix
    =C2=A0 =C2=A0and a interface ID (e.g. Stateless Addres= s Autoconfiguration(SLAAC)
    =C2=A0 =C2=A0[RFC4862]), a 64-bit interface I= D length is required. An "IPv6 over
    =C2=A0 =C2=A0<link>"= ; specification may modify this requirement for a specific link
    =C2=A0 = =C2=A0type. The rationale for the 64-bit boundary in IPv6 addresses can be =
    =C2=A0 =C2=A0found in [RFC7421].

    And replace 2.4.4 with;
    =C2=A0 =C2=A0The general format for IPv6 Global Unicast addresses is as f= ollows:

    =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 n bits =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 m bits =C2=A0| =C2=A0 =C2=A0 =C2=A0 128-n-m bits= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 =C2=A0+------------------------+--= ---------+----------------------------+
    =C2=A0 =C2=A0| global = routing prefix =C2=A0| subnet ID | =C2=A0 =C2=A0 =C2=A0 interface ID =C2=A0= =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 =C2=A0+------------------------+----= -------+----------------------------+

    =C2=A0 =C2=A0where= the global routing prefix is a (typically hierarchically-
    =C2=A0 =C2=A0= structured) value assigned to a site (a cluster of subnets/links in
    =C2= =A0 =C2=A0a location or mobile), the subnet ID is an identifier of a link=C2=A0 =C2=A0within the site, and the interface ID is as defined in Secti= on 2.4.1.

    =C2=A0 =C2=A0As noted in Section 2.4, most unicast address= es, including Global
    =C2=A0 =C2=A0Unicast addresses, have 64-bit interfa= ce IDs (i.e., n + m =3D 64).

    =C2=A0 =C2=A0As discussed in [BCP 157],= "it should be easy for an end site to
    =C2=A0 =C2=A0obtain address = space to number multiple subnets (i.e., a block larger
    =C2=A0 =C2=A0than= a single /64)" or in other words the subnet ID length should be
    = =C2=A0 =C2=A0greater than or equal to 1 (i.e., m >=3D 1). Subnet ID leng= ths of 4, 8,
    =C2=A0 =C2=A012, and 16 bits, and therefore global routing = prefix lengths of 60,
    =C2=A0 =C2=A056, 52, and 48 bits respectively, are= in common use and recommended.

    =C2=A0 =C2=A0Dynamic Host Configurat= ion Protocol version 6 - Prefix Delegation
    =C2=A0 =C2=A0(DHCPv6-PD)[RFC3= 633] is commonly used to automate the distribution of
    =C2=A0 =C2=A0glob= al routing prefixes to sites.

    =C2=A0 =C2=A0Global Unicast addresses,= and their format, are discussed further in
    =C2=A0 =C2=A0[RFC3587].

    A couple other quickies;

    Insert new paragraph at the = end of 2.1

    =C2=A0 =C2=A0[BCP 204] recommends that networks provide g= eneral-purpose nodes with
    =C2=A0 =C2=A0multiple global IPv6 addresses pe= r interface when they attach to a
    =C2=A0 =C2=A0link, it also describes = the benefits of and the options for doing so.

    Insert new sentence at= the end of 2.4.5

    =C2=A0 =C2=A0Additional IPv6 address that carry a= n IPv4 address are defined in IPv6
    =C2=A0 =C2=A0Addressing of IPv4/IPv6 = Translators [RFC6052].

    Thanks

    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking & Telecommunication Ser= vices
    Office of Information Technology
    University of Minnesota=C2=A0= =C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-= 0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =

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


    --001a113d058ccb7fa5054a144f97-- From nobody Mon Mar 6 10:49:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F00129967 for ; Mon, 6 Mar 2017 10:49:37 -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 autolearn_force=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 HaaQltQhc_ud for ; Mon, 6 Mar 2017 10:49:36 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id A51681294CC for ; Mon, 6 Mar 2017 10:49:35 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1ckxhO-0000DiC; Mon, 6 Mar 2017 19:49:34 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> Date: Mon, 06 Mar 2017 19:49:34 +0100 Archived-At: Cc: james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:49:37 -0000 > I found it confusing at first too, but the RFC 2119 keyword > language in RFC 4862 is pretty unambiguous, and it makes sense > too if you think about PIO updates that only change the lifetimes > and the value of the A flag. The requirement to drop all PIO > with invalid prefix length for the link type, regardless of the > A flag, ensures with a simple-to-implement rule that you never > take a misconfigured prefix as on-link if you cannot ever > auto-configure an address in the prefix when the update to A=1 > arrives. > > This may not be the behavior youd prefer that RFC 4862 require, > but the requirement is clearly there and certification tests > are within their ambit to check for it. Moreover, this proposed > successor to RFC 4291 doesnt even have an informative reference > to RFC 4862 in it, much less an explicitly declared update. And > I dont believe it should. If your stack only does this when the A bit is set, then I don't care that much. I'm perfectly happy if SLAAC remains at 64 bits and anything else requires DHCP or manual config. Technically, if you only drop the PIO if the A bit is set, then it is still future proof, because any future change to the prefix length can just require two options, one with the A bit set and one with the L bit set. Certainly if the A bit is clear, to reach the MUST in step d), you must have ignored step a). In addition, step d) spells out that prefixes that don't match the IID have a meaning in onlink processing, making it completely clear that 'in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration' means just that. If RFC 4861 meant to ignore the PIO option for the purpose of onlink then RFC 4861 would have said so directly. In any case, I think the 'MUST drop' interpretation of RFC 4862 is completely wrong. There is no way that a MUST in RFC 4862 can change the behavior of RFC 4861 without RFC 4862 explicitly updating RFC 4861. If that is intended, we should at least add an errata to RFC 4862. I'm not sure why you would think RFC 4291 should say something about the PIO option and the L bit processing? So it is not so much what I prefer. It is already spelled out. Note that your argument 'ensures with a simple-to-implement rule that you never take a misconfigured prefix as on-link' is not reflected in RFC 4862. RFC 4862 talks about misconfiguration with respect to autoconfiguration and is explict that this length check does not hold for onlink processing. Again 'in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration' Finally, the 'MUST drop' interpetation is not consistent with the behavior of FreeBSD, MacOS, and Linux. So I now start to wonder where the 'MUST drop' interpretation comes from and if anyone ever bothered to check out the behavior of existing stacks. From nobody Mon Mar 6 10:58:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA8C129404 for ; Mon, 6 Mar 2017 10:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com 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 SNKO2mE3yad3 for ; Mon, 6 Mar 2017 10:58:06 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C876A12995F for ; Mon, 6 Mar 2017 10:51:19 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id t193so72654858wmt.1 for ; Mon, 06 Mar 2017 10:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Arco9YdENWuQizg9Uo74b/uvY64gj2K/BU7zET6UJrk=; b=f2RZkqiDlkJOeG2pRAgNSDaxOsKDU1lKQqcFWyHyQaaBb7BlcFdxSUDm/0aVWIlX0H 9VuvAM+Fzyiuo7oV7OwUjFkIWrd/j/8NafyCVUMVDawWi3wICfRYvf+G/oS4/DCX+Cm/ aLXHsx6zYGLk6OQMPHDavDgfoAtfQlzgAL62vf+oiAGrfsU0s92+HzFbpc+pSCkBX5Ec xdSMVO5kmtv94mck5t0bi1v1cKaWK3YJzyr0MeVddUNHpuI1UPP1QNqr7OqkAI5h0LIl 0k3IlputFqXm4p6QjF+5shaAzPbxwu/iFbP/L1nqj/SE18RMqBShq9tkQ6X1+CfFmyAS Is3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Arco9YdENWuQizg9Uo74b/uvY64gj2K/BU7zET6UJrk=; b=KeABKwb+mWOBZvNQiNmOpBYqKy5RdnqE/LoBuVHlma5yjtNSuhFKbx3CKeXvWZhgyn IjXQdECxp93UpXH/NMwkkZmyhTlXL9EulRXeHq3zWMhw2qc9qNqEhyBzVCk5tnxMlPUL rvyO6d75PVWKgBRHLmvIQ/5gX9PQomsb31tOQw2CeNCe/2Dmd71QLvWngZYr1IZt3Ex0 fcPF1p4QvxvXp3HnGb5zfuQJNXS9Qus1NvVeUaPLYxvEsVKT7ToA0Zy8TswY9OLJGmg9 7bp3qeu+k2brBlgkOJ9Z6NnOkvIe9uHeD7PH9XLevUm556cnBav+Xr+GHuvTO7igZFSD NQ+w== X-Gm-Message-State: AMke39lfCehkPzKNblb6MGyPCCF6VsUZ7HtmYm/a3PKHl8GOLGWZHLK1IcLTQNujKsjaVv3KmDbf2G8Pcf0nmQ== X-Received: by 10.28.186.70 with SMTP id k67mr13931263wmf.65.1488826278232; Mon, 06 Mar 2017 10:51:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.182.162 with HTTP; Mon, 6 Mar 2017 10:51:17 -0800 (PST) X-Originating-IP: [2001:67c:208c:10:e914:6955:797a:af14] In-Reply-To: References: From: Job Snijders Date: Mon, 6 Mar 2017 19:51:17 +0100 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:58:07 -0000 Hi, On Mon, Mar 6, 2017 at 7:46 PM, Lorenzo Colitti wrote: > Wow. That's a lot of for what started off as a reclassification. I don't > think it's a good idea to attempt to wordsmith RFC4291 hoping that one of > the formulations we end up with will somehow reach consensus. Instead, I > would suggest another approach: see what the problems with 4291 are, *write > them down*, and only then write a document explaining what should be changed > and why. > > In other words: start with a problem statement. I suggest to first wait for feedback from the IESG and finish that process. The last call period ended 5 days ago. Regards, Job From nobody Mon Mar 6 11:05:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222D712996E for ; Mon, 6 Mar 2017 11:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 vodfS2I0-4mt for ; Mon, 6 Mar 2017 11:05:48 -0800 (PST) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195E3129886 for ; Mon, 6 Mar 2017 11:05:47 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 631449E2 for ; Mon, 6 Mar 2017 19:05:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJMhBURzqGFi for ; Mon, 6 Mar 2017 13:05:47 -0600 (CST) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 3400B9B0 for ; Mon, 6 Mar 2017 13:05:47 -0600 (CST) Received: by mail-ua0-f198.google.com with SMTP id q7so84815999uaf.0 for ; Mon, 06 Mar 2017 11:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wGhpYkR2aL3gqlTpcWeluY62M/d9r5obsml4hLdVGg4=; b=aWMLhYRA5RVsGHnBdaTjqbctbUA7gs+VeOgAGUxNjjnI6+fxXGULM6LQybK0bXvxX0 CCsyO/7q7j66EgXiI6TxZPNSvOvzsN9SM+BqhHVkt9d7KHc05gqd0ltor9/oKM6fQeaD CGS2npKoAJKcOGno/eMq8vIXwmw8KBzUDd3gwlIDiC+V64YqU/UFLPRdIZUhpodGPaE3 hqCNBUAh6qfNKP5821O7s0PVFui79XckalNxBG9RM43UyJB0sKzqwAX4msPqC0UDQ4qg NmgW7j4y08pXnVV6HYQSSDyP7HQBP/EzYVvRurklv6BZrlzyYphyRYbEaqwxZCag3Ali stgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wGhpYkR2aL3gqlTpcWeluY62M/d9r5obsml4hLdVGg4=; b=ZY5Vu0ZijL+PRm6JyRlNqhelkaExKVtmEwepid7swCOqavQHKnkpnMRN0HN2mYmR8q 7e9VvTxkwnWiiAKP6Jg0Se+PLYBO4/jVUT/L/2TJ8VdnYjhbjnrNWi++PDGH5I3QW5kf Jj4pRaLvH5kx3LNW2I7pC+C8uLRO83PCL4y7Fi7B60JDcVk2Sniwa8f7tgNvVjIVbnQG PtbVhpiMw6YwZxV2z/5k6xSOu3S2Qs66Wf/gLBIv+aGr7Sm1j+BFCL6DRnTUc5OJstP5 OuphlyX03QCEwBAR8A+Rq3aRCrmdhyo9qJir8uxMTFAYPcCqvYpzyZBdGiVlmA/sZGw0 Fo2A== X-Gm-Message-State: AMke39mZYomi1oZsjswchEcbG3UhPD/0/mZvsl7j+20N6adoMjeC7f0WddQ41zc8LvPWRA1YlOLXdPRNg/tMhzJCJR0ncuD3w2b6+zBt6eGDnSO4R3qq+PU3dpMbaV01QmyCRIHP67ZaftgAVGU= X-Received: by 10.176.80.66 with SMTP id z2mr2500924uaz.151.1488827146477; Mon, 06 Mar 2017 11:05:46 -0800 (PST) X-Received: by 10.176.80.66 with SMTP id z2mr2500917uaz.151.1488827146301; Mon, 06 Mar 2017 11:05:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.134.129 with HTTP; Mon, 6 Mar 2017 11:05:45 -0800 (PST) In-Reply-To: References: From: David Farmer Date: Mon, 6 Mar 2017 13:05:45 -0600 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=94eb2c192330300398054a14950a Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 19:05:49 -0000 --94eb2c192330300398054a14950a Content-Type: text/plain; charset=UTF-8 On Mon, Mar 6, 2017 at 12:46 PM, Lorenzo Colitti wrote: > Wow. That's a lot of for what started off as a reclassification. I don't > think it's a good idea to attempt to wordsmith RFC4291 hoping that one of > the formulations we end up with will somehow reach consensus. > There seems to be a fairly strong consensus that RFC4291bis shouldn't go forward without additional wordsmithing. But that is obviously the IESGs call. > Instead, I would suggest another approach: see what the problems with 4291 > are, *write them down*, and only then write a document explaining what > should be changed and why. > The list of 7 points are the problems that many see with 4291bis, maybe overly summarized, but they are there. --94eb2c192330300398054a14950a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Mon, Mar 6, 2017 at 12:46 PM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
    =
    Wow.= That's a lot of for what started off as a reclassification. I don'= t think it's a good idea to attempt to wordsmith RFC4291 hoping that on= e of the formulations we end up with will somehow reach consensus.

    There seems to be a fairly strong= consensus that RFC4291bis shouldn't go forward without additional word= smithing. But that is obviously the IESGs call.
    =C2=A0
    Instead, I would suggest another = approach: see what the problems with 4291 are, *write them down*, and only = then write a document explaining what should be changed and why.

    The list of 7 points are the proble= ms that many see with 4291bis, maybe overly summarized, but they are there.=

    =C2=A0
    --94eb2c192330300398054a14950a-- From nobody Mon Mar 6 11:38:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423A412945B for ; Mon, 6 Mar 2017 11:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PksSo1k_KNRP for ; Mon, 6 Mar 2017 11:38:17 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6667127735 for ; Mon, 6 Mar 2017 11:38:17 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id j5so64456296pfb.2 for ; Mon, 06 Mar 2017 11:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=iLvfhY6VmQ4RAA37UvDa7F7y/G1XLxftUCFi5Vi8ZUo=; b=f5bLBt5w5YAYq5JUAr98AzSfSklmSuSXJQNbALv0dVr+g5Z1V/CMUhpagj6Y/RAVlg Jbm3qFFWVv42j6YT2aUkyaDBvjbZCrAiIeThku1WVuhubQ0M0Wm5xsDLgHvr5zu5Eoj/ lVyVKep7ND3iRvjp5oPFfx239Ebav/DD9X+NmLLjYtsyBXaNFq54oZ4RE3S7fj5r9arE a6w5eeVtrQf7uHCk47YuFHjhMBEvxLiq0zqh35rrWW9hv+vKdyOveuaOZLxW4wyz0t36 jbT58g5FqoYk/wq8qpusxuXrB+XY/PMaO73sS6qBCwphS63PqqpS/MIUg2FNV8AIKPfW 5LNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=iLvfhY6VmQ4RAA37UvDa7F7y/G1XLxftUCFi5Vi8ZUo=; b=UYW5p+cqrW1xZT9FLy6eIpnbbXSXKJRWIAZOO+kM4TaUus5Is0KGmspALFp054uGEa K/uPDRCelvVE8O7Jw2CUFKFKG9ZJKUjD2WPlP+Jnq3BFWYG+5Wx4alwq5cnN2xlv0UzA BrdG4OeTo07JeXCQABDJLk8+MtDL1E2kW2T8KbTX49cgtzpnRjJs8oFUdS0Gl7ZwTE76 O3CxZp5/g7/qXXQZP6dgB/hQ6v0cJ7AjlY/uBLew3D+nXBRGy3qsIFL7UUeQTB0caGEs 9QnV/ciWz6Gj49tepCw/4Jnij4xlObr/7zOXYcgkJqqE2oAjcPsZ7MMft9C5hO8dAVR4 eciQ== X-Gm-Message-State: AMke39kNziikkNRmT+zKeEYwCopoEM0TDNtKfB41ZTRux3NSQ+KLs+t8stNRFIee041TIw== X-Received: by 10.99.94.195 with SMTP id s186mr22892556pgb.197.1488829097074; Mon, 06 Mar 2017 11:38:17 -0800 (PST) Received: from [192.168.178.23] ([118.148.79.158]) by smtp.gmail.com with ESMTPSA id f205sm9229797pfa.35.2017.03.06.11.38.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 11:38:16 -0800 (PST) Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 7 Mar 2017 08:38:14 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 19:38:19 -0000 On 07/03/2017 07:51, Job Snijders wrote: > Hi, > > On Mon, Mar 6, 2017 at 7:46 PM, Lorenzo Colitti wrote: >> Wow. That's a lot of for what started off as a reclassification. I don't >> think it's a good idea to attempt to wordsmith RFC4291 hoping that one of >> the formulations we end up with will somehow reach consensus. Instead, I >> would suggest another approach: see what the problems with 4291 are, *write >> them down*, and only then write a document explaining what should be changed >> and why. >> >> In other words: start with a problem statement. > > I suggest to first wait for feedback from the IESG and finish that > process. The last call period ended 5 days ago. +many For a promotion to IS we should be minimising changes to the text. If we want to change the world, that comes afterwards. Brian From nobody Mon Mar 6 12:47:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024C8129A0D for ; Mon, 6 Mar 2017 12:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 m9cJs0027pMp for ; Mon, 6 Mar 2017 12:47:02 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37924129A07 for ; Mon, 6 Mar 2017 12:47:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v26KkxPg023065 for ; Mon, 6 Mar 2017 21:46:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E4E5A20A337 for ; Mon, 6 Mar 2017 21:46:59 +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 DB3EA20A221 for ; Mon, 6 Mar 2017 21:46:59 +0100 (CET) Received: from [132.166.84.158] ([132.166.84.158]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v26Kkw9t030262 for ; Mon, 6 Mar 2017 21:46:59 +0100 Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Mon, 6 Mar 2017 21:47:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:47:05 -0000 agreed with some of the things that I cut but I have one question. Le 06/03/2017 à 19:46, Lorenzo Colitti a écrit : > If we allow the boundary to change, there is a near certainty that > too-small subnets *will* be configured in some places, and is IETF a place to make recommendations of making big or small subnets? Isnt it for the RIRs to make such recommendations? I mean RIRs decide what to allocate, when there is shortage or not. But with 64 you seem to be wanting to keep a limit there in order to be able to unlimit later, or something like that, right? Alex > and over time, host software will adapt to the lowest common > denominator. There is a very real risk end up with solutions that > "mostly work most of the time" - things like NAT traversal, and NAT > keepalives - over more robust solutions that rely on strong > guarantees from the network layer. The risk is that the IPv6 Internet > will be constrained by IPv4 address scarcity even after IPv4 is > gone. > > It's up to us to avoid that risk. I continue to be amazed by the > people on this thread who are advocating that we run it. > > On Tue, Mar 7, 2017 at 3:06 AM, David Farmer > wrote: > > A few more tweaks, corrections and other changes some based on feed > back; > > 1. IPv6 unicast routing is 128 bits in length [BCP198]/[RFC7608], > AKA not classful! 2. SLAAC is commonly used to generate unicast > addresses, therefore subnet prefixes and IIDs are 64 bits for most > address. 3. Explicitly allow subnet prefix lengths other than 64 > bits for manually config and DHCPv6 while still recommending 64 bits > (most code does this now and has since the beginning) 4. IIDs of 64 > bit are REQUIRED for SLAAC, except when overridden by an > IPv6-over-foo doc (we really can't change 64 bit IIDs for SLAAC, it > would break running code, at least not right now, maybe in the > future) 5. Sites should get more than a single /64 > [BCP157]/[RFC6177], and sites include mobile 6. Avoid other explicit > exceptions or recommendations for longer prefixes, like RFC6164 7. > include references to [BCP204]/[RFC7934] and [RFC6052] in the right > places > > In the current draft, remove the 2nd paragraph of 2.4, then add the > following sentence to the end of the first paragraph of 2.4; > > Furthermore, IPv6 unicast routing is based on prefixes of any length > up to 128 bits [BCP198]. > > Then add the following two paragraphs at the end of section 2.4; > > Stateless Address Autoconfiguration(SLAAC)[RFC4862] is commonly used > to automatically create unicast addresses, therefore most unicast > addresses have 64-bit subnet prefixes and 64-bit interface IDs. The > rationale for the 64-bit boundary in IPv6 addresses can be found in > [RFC7421]. > > Nevertheless, unicast addresses may also be provided from a node's > internal configuration (AKA manual or static configuration) or via > Dynamic Host Configuration Protocol version 6(DHCPv6)[RFC3315]. Such > addresses are assumed to be opaque 128-bit strings without any > internal structure. These addresses may be associated with subnet > prefixes of any length, while 64-bit subnet prefixes are > recommended. > > Then replace the 4th paragraph of 2.4.1 with; > > When unicast addresses are automatically created from a subnet prefix > and a interface ID (e.g. Stateless Address Autoconfiguration(SLAAC) > [RFC4862]), a 64-bit interface ID length is required. An "IPv6 over > " specification may modify this requirement for a specific link > type. The rationale for the 64-bit boundary in IPv6 addresses can be > found in [RFC7421]. > > And replace 2.4.4 with; > > The general format for IPv6 Global Unicast addresses is as follows: > > | n bits | m bits | 128-n-m bits | > +------------------------+-----------+----------------------------+ > | global routing prefix | subnet ID | interface ID | > +------------------------+-----------+----------------------------+ > > where the global routing prefix is a (typically hierarchically- > structured) value assigned to a site (a cluster of subnets/links in > a location or mobile), the subnet ID is an identifier of a link > within the site, and the interface ID is as defined in Section > 2.4.1. > > As noted in Section 2.4, most unicast addresses, including Global > Unicast addresses, have 64-bit interface IDs (i.e., n + m = 64). > > As discussed in [BCP 157], "it should be easy for an end site to > obtain address space to number multiple subnets (i.e., a block larger > than a single /64)" or in other words the subnet ID length should be > greater than or equal to 1 (i.e., m >= 1). Subnet ID lengths of 4, 8, > 12, and 16 bits, and therefore global routing prefix lengths of 60, > 56, 52, and 48 bits respectively, are in common use and recommended. > > Dynamic Host Configuration Protocol version 6 - Prefix Delegation > (DHCPv6-PD)[RFC3633] is commonly used to automate the distribution of > global routing prefixes to sites. > > Global Unicast addresses, and their format, are discussed further in > [RFC3587]. > > A couple other quickies; > > Insert new paragraph at the end of 2.1 > > [BCP 204] recommends that networks provide general-purpose nodes with > multiple global IPv6 addresses per interface when they attach to a > link, it also describes the benefits of and the options for doing > so. > > Insert new sentence at the end of 2.4.5 > > Additional IPv6 address that carry an IPv4 address are defined in > IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]. > > Thanks > > -- =============================================== David Farmer > Email:farmer@umn.edu Networking & > Telecommunication Services Office of Information Technology > University of Minnesota 2218 University Ave SE Phone: > 612-626-0815 Minneapolis, MN 55414-3029 Cell: > 612-812-9952 > =============================================== > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Mar 6 13:03:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC93129A0F for ; Mon, 6 Mar 2017 13:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 gzT-JhMlT9I7 for ; Mon, 6 Mar 2017 13:03:39 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F301294E8 for ; Mon, 6 Mar 2017 12:53:23 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id j5so65146583pfb.2 for ; Mon, 06 Mar 2017 12:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LAkhfCvkpbFmOergtvsWuwYs8vptKADwE2JZWEvYyY0=; b=RTlltylGCmPyRPpbPQ529+S2u0e3k7eot+cg/qFh4egcBGc+5Kha7H5i7ra3do2Gr7 yVgdf5D4mb+xPwh1StZT/iSziEWWspN0VEriJIRW+OR0RAP8AOOVAK0I14sQp+U/gMYs ycZMuG8dWmPkuOtgCVWxfxvrQNgEA4+MI2q3ayeY8ByLb+YGLOUAqDNuFmDBGttmL4o0 omm93PAUYHADwTYf8aY3m1tAZYOl4H5T5SBjFI2LEhQ9Z2Vt/MA7Ex7FdM3m78gAdYBS oX7ClSYgvbI7Luhq8vWVq8+7unIgZQuApgdVEcMerOtmgYsoLBtKVhcm6kY4N882JS2h WQ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LAkhfCvkpbFmOergtvsWuwYs8vptKADwE2JZWEvYyY0=; b=rYdcA3xtujAEl59tXJKwIqzzBnOh3EfCjJeZNGnfX485LyZr8Nbm+Bzysdy52e8W1Z +35KPkGWm2JHsM/rYOm1weXUS5RMH3VBHcExrIT58+C08l/mfssjEvIs2qzQlsR1CCdt AosxDwHB407JiyFzVQS+D3CKdFulbGe40izsFVUb/eQyZ2HBmYC2BLpXM7Y/It+ChGFU 7p1l1NSIwvVv3qZL1il5lTMAQhXsQ+AjWo+oBp/aBjysh7/77G10kj3zxPrOAUHENpiL fj4BQKNhTOnadlMMeyqAyHRIeCNa0RNoks+JClv2zbTqVSz25Vkfe6JAfHQCBjt+XEE9 6I0w== X-Gm-Message-State: AMke39kHTl1Nj9XnNSRhK3qVfrvfxPd7IrG45SYFIF/JTnW62yzZdejln+nA9sBbfgR0FVrj X-Received: by 10.99.146.7 with SMTP id o7mr22923301pgd.6.1488833602979; Mon, 06 Mar 2017 12:53:22 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id m67sm41299055pfj.32.2017.03.06.12.53.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 12:53:22 -0800 (PST) From: james woodyatt Message-Id: <225F639E-27C1-4408-BC2B-26500929049B@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C982BA9C-85A3-4FEB-B399-62170047BFF0" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07 Date: Mon, 6 Mar 2017 12:53:19 -0800 In-Reply-To: To: Philip Homburg References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Operations , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 21:03:40 -0000 --Apple-Mail=_C982BA9C-85A3-4FEB-B399-62170047BFF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 6, 2017, at 10:47, Philip Homburg = wrote: >=20 > Finally, the 'MUST drop' interpetation is not consistent with the > behavior of FreeBSD, MacOS, and Linux. So I now start to wonder where > the 'MUST drop' interpretation comes from and if anyone ever bothered > to check out the behavior of existing stacks. Looking at the relevant source code for a couple of the latest = BSD-variant kernels, I believe you=E2=80=99re right about the current = behavior on those platforms. My memory of them must be outdated. I think = they used to drop PIO according to a strict interpretation of RFC 4862. = I distinctly remember having to implement it that way in order to pass a = certification test. I believe these implementations will not any longer = pass that test. (One imagines either their owners don=E2=80=99t care, or = the test has been revised to be more lenient.) I am however looking at a commonly used lightweight IP stack that simply = ignores all PIO options unless Prefix Length =3D 128 - IID Length (and = it safely assumes all interface identifiers are length 64 because it = doesn=E2=80=99t support link types with other IID lengths, and it=E2=80=99= s also unsuitable for use in the environments where IETF standards make = exceptions for other IID lengths). This stack was developed entirely = apart from the Linux and KAME efforts, by people who read the fine RFCs = and implemented the simplest lightest-weight thing possible that is = still compliant with the requirements language. That=E2=80=99s important = for people on platforms where every byte of code and stack space is = precious. p1. I get that RFC 4862 has requirements language that annoys some = participants. We are not here revising RFC 4862 however, so that=E2=80=99s= not relevant. p2. The stack I=E2=80=99m using implements SLAAC and-- for completely = defensible reasons=E2=80=94 follows the letter of RFC 4862 requirements. = Its current behavior is compliant with RFC 4291, RFC 4861 and RFC 4862. = It=E2=80=99s not exactly uncommon in the field today, and it=E2=80=99s = not currently broken by the proposed successor to RFC 4291 with its = current language about IID length. p3. I get that people want to hold up promotion of IPv6 to Full Standard = until the successor of RFC 4291 is changed to declare explicitly that = the stack I=E2=80=99m using is in error. My opinion is this is a = procedural matter, not a technical matter. I object to the procedural step being proposed, not the technical = argument. If we MUST declare the stack I=E2=80=99m using to be in error, = then please let=E2=80=99s NOT do it in this draft. Can you not wait = until RFC 4861 and RFC 4862 are next revised? --james woodyatt > --Apple-Mail=_C982BA9C-85A3-4FEB-B399-62170047BFF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 6, 2017, at 10:47, Philip Homburg <pch-v6ops-6@u-1.phicoh.com> wrote:

    Finally, the 'MUST drop' interpetation is not = consistent with the
    behavior of FreeBSD, MacOS, and Linux. So = I now start to wonder where
    the 'MUST drop' interpretation = comes from and if anyone ever bothered
    to check out the behavior of = existing stacks.

    Looking at the relevant source code for = a couple of the latest BSD-variant kernels, I believe you=E2=80=99re = right about the current behavior on those platforms. My memory of them = must be outdated. I think they used to drop PIO according to a strict = interpretation of RFC 4862. I distinctly remember having to implement it = that way in order to pass a certification test. I believe these = implementations will not any longer pass that test. (One imagines either = their owners don=E2=80=99t care, or the test has been revised to be more = lenient.)

    I am = however looking at a commonly used lightweight IP stack that simply = ignores all PIO options unless Prefix Length =3D 128 - IID Length (and = it safely assumes all interface identifiers are length 64 because it = doesn=E2=80=99t support link types with other IID lengths, and it=E2=80=99= s also unsuitable for use in the environments where IETF standards make = exceptions for other IID lengths). This stack was developed entirely = apart from the Linux and KAME efforts, by people who read the fine RFCs = and implemented the simplest lightest-weight thing possible that is = still compliant with the requirements language. That=E2=80=99s important = for people on platforms where every byte of code and stack space is = precious.

    p1. = I get that RFC 4862 has requirements language that annoys some = participants. We are not here revising RFC 4862 however, so that=E2=80=99s= not relevant.

    p2. The stack I=E2=80=99m using implements SLAAC and-- for = completely defensible reasons=E2=80=94 follows the letter of RFC 4862 = requirements. Its current behavior is compliant with RFC 4291, RFC 4861 = and RFC 4862. It=E2=80=99s not exactly uncommon in the field today, and = it=E2=80=99s not currently broken by the proposed successor to RFC 4291 = with its current language about IID length.

    p3. I get that people want to hold up = promotion of IPv6 to Full Standard until the successor of RFC 4291 is = changed to declare explicitly that the stack I=E2=80=99m using is in = error. My opinion is this is a procedural matter, not a technical = matter.

    I = object to the procedural step being proposed, not the technical = argument. If we MUST declare the stack I=E2=80=99m using to be in error, = then please let=E2=80=99s NOT do it in this draft. Can you not wait = until RFC 4861 and RFC 4862 are next revised?


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_C982BA9C-85A3-4FEB-B399-62170047BFF0-- From nobody Mon Mar 6 14:15:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAEC1294F3; Mon, 6 Mar 2017 14:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0zOoQp_OtJdx; Mon, 6 Mar 2017 14:15:38 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22BF129A4A; Mon, 6 Mar 2017 14:15:37 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id p64so60174281qke.1; Mon, 06 Mar 2017 14:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=b5fddJlD+/t+qzAZ23iPQxx9wZ0wzni2BIcskk6OAaI=; b=CRvzA6EcNUjweNQoYwN5ty7S25BBjjbQRdDHz3j9XVSc3DbOhC0bxDEujZdH/MwHFB flXztdy0aBx9dW/b7V5eY0w3Ptpwvc4ylgQ6cn3ceBuSaQCLHsGFl2xACEJfKIcdH3mj 3s8JjczWgMBguyCQcXqDr78+Uva6cHlaX+b702uHvNsvFvIKW4IMskfBDhcpHgqlUh16 izN9fm63DzCblgPI9jqCiMKEPxOTGZIC1l7pLN6IPXkOK/XLXTL5EW4PeZkIFFAE2OrK APh2YnCOwqGXfZSM0ODDVnPDXc+t/uM737kbyEyp7IH7n8K8gT7O11klU/eGOFcC81xx PmZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-transfer-encoding; bh=b5fddJlD+/t+qzAZ23iPQxx9wZ0wzni2BIcskk6OAaI=; b=a3HZ94d0tCR8XfswzRMlAjmIbuWyc41t94PUHQMXa0htByfTXgfsMLgetS1d/sMzx5 ZP504tlhPtXTuYe/BOTKWEacdlWuz639Oc8P1TEKCqwQDFE95gtIJ4wsfpXnj9zB7YTp zpPpZDXRB4qdy6pZfwYo1Jwmdm9oa6x1YQxz2vVRND633xrbQ0EwfZkv8usyJ0CvkNKT oU3BoVKGf7wwlrwd1ZX97LOADNmmUJlGycMdOPYKi3ZLBk5evTWnBl3GqWqbJLWQpMNx EAAYbh3UOECD+Sb5/ds60v+ugMC8gOy8S73gSsBrPP5YS/j9yfv7NugyYsb09AoR4oar SicA== X-Gm-Message-State: AMke39l2ZbCDH6sWchGwuIBFUGCxMyr16kCjN0IWquWfzZSiH6hppMoMl+ghjR0gG1D6xYQU6Es5jKbd1I6DqQ== X-Received: by 10.55.104.134 with SMTP id d128mr16178894qkc.86.1488838536636; Mon, 06 Mar 2017 14:15:36 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Mon, 6 Mar 2017 14:15:36 -0800 (PST) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 6 Mar 2017 14:15:36 -0800 X-Google-Sender-Auth: -VimxPj8HUHg-uACsYXRZ0FbGpA Message-ID: Subject: prefix length ban for RFC4861 (Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07) To: james woodyatt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Philip Homburg , IPv6 Operations , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 22:15:40 -0000 At Mon, 6 Mar 2017 12:53:19 -0800, james woodyatt wrote: > > Finally, the 'MUST drop' interpetation is not consistent with the > > behavior of FreeBSD, MacOS, and Linux. So I now start to wonder where > > the 'MUST drop' interpretation comes from and if anyone ever bothered > > to check out the behavior of existing stacks. > Looking at the relevant source code for a couple of the latest > BSD-variant kernels, I believe you=E2=80=99re right about the current > behavior on those platforms. My memory of them must be outdated. I > think they used to drop PIO according to a strict interpretation of > RFC 4862. I distinctly remember having to implement it that way in BSD variants did NOT ignore PIO for on-link determination simply due to its prefix length value at least at the time of the publication of RFC4862 (actually since way before that RFC). For example, this is FreeBSD's implementation as of Oct 21, 2005, about two years before RFC4862 was published: https://github.com/freebsd/freebsd/blob/c2b19f24a4ba01108e047a35a4a060cbfdf= 28a17/sys/netinet6/nd6_rtr.c see nd6_prelist_add() starting at line 993, and find that it only checks the prefix length for SLAAC (lines from 1258). At this point the on-link determination has been completed without any check on the prefix length (lines 1043-1056). > order to pass a certification test. I believe these implementations > will not any longer pass that test. (One imagines either their > owners don=E2=80=99t care, or the test has been revised to be more lenien= t.) This is quite surprising to me. Do you have any reference to such a certification test that requires the host to ignore PIO with a non-64 prefix length for the purpose of on-link determination (i.e., for RFC4861)? -- JINMEI, Tatuya From nobody Mon Mar 6 14:26:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08589129A5C for ; Mon, 6 Mar 2017 14:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 pe-x1tbzgbZx for ; Mon, 6 Mar 2017 14:26:17 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEBF129A5B for ; Mon, 6 Mar 2017 14:26:17 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id j5so65988595pfb.2 for ; Mon, 06 Mar 2017 14:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7BtEy91/9LEM5lrmPSCBTsQHvIGQWxW0+P8j0TVbjDM=; b=EzKwtW5CvoLm4Jkpc+4iy56BNezpbsgLnilRtUoWEChbzr0eMdRQEsdBs+rAf5uFMh ytwuVeMFHpzvCn4OnyfFkAzH4QlFetB7fT+SYG2DLTPJsQLaKbw8ioBD4ZHBckwF3Oj8 bWmTQoZoKkhH3DzTYcohHzITG7pzyKtalq+xcj5UnIy/97KaPePw7IBMkKydQmJoD/Is iT408417KsAJR2/cKRg81UaXjZ/1FYd4YNkrFEElVstVbVd7d7y//iZoQyvDNg8ukxvT umkafvSUfa/JO7MFcKVq9apDimMHFEZrjlChx2uHNuAua8jdfybPAym0usJ5CgAXy/LE ZGsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7BtEy91/9LEM5lrmPSCBTsQHvIGQWxW0+P8j0TVbjDM=; b=Mj7phA9ig8mOh2wyMU+Wrp4tsqf5wbEjsXHVcxoPavyhFFgUmXp7m4Zy9m+DqJnfws LwgshnsGWAxX7rK95lzqXecll0vHVeLdwOu1yADdM/ucApktwp1UMFghHFRxRThVeu4O fim1iywKbsrAbdHejM7beQa8hefozRxGswKsqGTnY3kBL6UzXwMh0ICOZhi7syeZO4bY 2Gi4di9I25a314BMVCH5fabhgVoxxFtKwU6HsRY+VLRHB/rJYnFxQocXe0wrJVTjs0d/ r6T4JsjdyyZhXnEuRalB1UvKiWXlQx/xvQnsnVAofmYz1Nm5ZLW/5Bxs/lJqLBMmywNz M/ww== X-Gm-Message-State: AMke39mJAnUdLUcvU77MJBwGjch9S7dC5siVaRzLprWdL1Zup9MQhWJkwKwEHK/Ux+eZHRHZ X-Received: by 10.84.177.36 with SMTP id w33mr30003992plb.105.1488839176674; Mon, 06 Mar 2017 14:26:16 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id n189sm41415559pfn.108.2017.03.06.14.26.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 14:26:16 -0800 (PST) From: james woodyatt Message-Id: <7F00A187-28E5-4D6E-8F24-771EC80AC078@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E0D7DD33-9A65-46A3-89CC-953C2F50C6D2" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] prefix length ban for RFC4861 (Re: A proposal for draft-ietf-6man-rfc4291bis-07) Date: Mon, 6 Mar 2017 14:26:15 -0800 In-Reply-To: To: =?utf-8?B?56We5piO6YGU5ZOJ?= References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 Operations , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 22:26:19 -0000 --Apple-Mail=_E0D7DD33-9A65-46A3-89CC-953C2F50C6D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 6, 2017, at 14:15, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > BSD variants did NOT ignore PIO for on-link determination simply due > to its prefix length value at least at the time of the publication of > RFC4862 (actually since way before that RFC). For example, this is > FreeBSD's implementation as of Oct 21, 2005, about two years before > RFC4862 was published: > = https://github.com/freebsd/freebsd/blob/c2b19f24a4ba01108e047a35a4a060cbfd= f28a17/sys/netinet6/nd6_rtr.c > see nd6_prelist_add() starting at line 993, and find that it only > checks the prefix length for SLAAC (lines from 1258). At this point > the on-link determination has been completed without any check on the > prefix length (lines 1043-1056). Indeed, I am unable to find source code history in FreeBSD, NetBSD or = Darwin consistent with my memory. Perhaps I am mistaken that it was ever = there. >> order to pass a certification test. I believe these implementations >> will not any longer pass that test. (One imagines either their >> owners don=E2=80=99t care, or the test has been revised to be more = lenient.) >=20 > This is quite surprising to me. Do you have any reference to such a > certification test that requires the host to ignore PIO with a non-64 > prefix length for the purpose of on-link determination (i.e., for > RFC4861)? My admittedly questionable memory is that it was a USGv6 Test Program = for SLAAC [Host] Conformance that checked for this behavior in a host = implementation I maintained at the time. As I said, I wouldn=E2=80=99t = be surprised if that test has been revised to be more lenient, but I = remember having to modify the KAME source code to pass the test. Nevertheless, the LwIP stack does what I=E2=80=99m talking about, and = it=E2=80=99s used in a plethora of constrained resource host operating = systems these days. --james woodyatt > --Apple-Mail=_E0D7DD33-9A65-46A3-89CC-953C2F50C6D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 6, 2017, at 14:15, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = <jinmei@wide.ad.jp> wrote:

    BSD variants = did NOT ignore PIO for on-link determination simply due
    to = its prefix length value at least at the time of the publication of
    RFC4862 (actually since way before that RFC).  For = example, this is
    FreeBSD's implementation as of Oct 21, = 2005, about two years before
    RFC4862 was published:
    https://github.com/freebsd/freebsd/blob/c2b19f24a4ba01108e047a3= 5a4a060cbfdf28a17/sys/netinet6/nd6_rtr.c
    see = nd6_prelist_add() starting at line 993, and find that it only
    checks the prefix length for SLAAC (lines from 1258). =  At this point
    the on-link determination has been = completed without any check on the
    prefix length (lines = 1043-1056).

    Indeed, I am unable to find source code history in = FreeBSD, NetBSD or Darwin consistent with my memory. Perhaps I am = mistaken that it was ever there.

    order to pass a certification test. I believe = these implementations
    will not any longer pass that test. = (One imagines either their
    owners don=E2=80=99t care, or = the test has been revised to be more lenient.)

    This is quite surprising to me. =  Do you have any reference to such a
    certification = test that requires the host to ignore PIO with a non-64
    prefix length for the purpose of on-link determination (i.e., = for
    RFC4861)?

    My admittedly questionable memory is that it was a = USGv6 Test Program for SLAAC [Host] Conformance that checked for this = behavior in a host implementation I maintained at the time. As I said, I = wouldn=E2=80=99t be surprised if that test has been revised to be more = lenient, but I remember having to modify the KAME source code to pass = the test.

    Nevertheless, the LwIP stack does what I=E2=80=99m talking = about, and it=E2=80=99s used in a plethora of constrained resource host = operating systems these days.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_E0D7DD33-9A65-46A3-89CC-953C2F50C6D2-- From nobody Mon Mar 6 15:45:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FB51294AE for ; Mon, 6 Mar 2017 15:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 OrSRI05m7c2s for ; Mon, 6 Mar 2017 15:45:10 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D673129876 for ; Mon, 6 Mar 2017 15:45:10 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id 1so181774302qkl.3 for ; Mon, 06 Mar 2017 15:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NPEBCO0vyUvZ2jXl+Tt1JJUNUf5TFBIOodWjXYikxmM=; b=dRmFawg9VAUpbBefV5itdjanF6RVj4POcuVlV2tXunZeljErp3Do03JhWv9i7IKJSn 3HUlddZ9T/pb6R5mCFmG4PI5hyWOcqqYd8lFCMiyTM84BpWCw1KYtgKkFc6uZCcOP9I7 /juB20BaOCVwFvdj/fgdWRRBcwqVSttOFsdlA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NPEBCO0vyUvZ2jXl+Tt1JJUNUf5TFBIOodWjXYikxmM=; b=J9XIneKmSdyJmIViRAFdx8bcvsroMCA5+uPAW+RzUiThr6T4mXswf/IuwOTBu/jvke Ad7kMzK7YiB6vkDEt6pR6u7vtx5SbVCYFNarwlu7P3a2RfxWuOtt8NYmo8RTioFCZhBW JsbnQl/miS7VjB4unWS4v46dinXf7bl0IohPbWvn2rGvEKliCTDTS9gwOgNPEBS8+rUe XUBb4dDTaTX/sedV4s6+WHulvLfEm+uUtRwE85l6fM5d1qzofmLxWluSpnnwEnIJF1PP fC8auFNRwUnra9cvBhSr+PK/UaqxYgHlf2tAazysTBLh0ZH8uriZoUZApH9NxtJ3pB4D OC6w== X-Gm-Message-State: AMke39newxGQy0SBuLu1wYw1RH3kVHRKcWHJylk4hVJFl5lGAQixoy56l4FLJkSYEbc6aFlt3bC8hEkMTSgu3m17 X-Received: by 10.237.36.172 with SMTP id t41mr17647032qtc.142.1488843909134; Mon, 06 Mar 2017 15:45:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Mon, 6 Mar 2017 15:45:08 -0800 (PST) In-Reply-To: <7F00A187-28E5-4D6E-8F24-771EC80AC078@google.com> References: <7F00A187-28E5-4D6E-8F24-771EC80AC078@google.com> From: Timothy Winters Date: Mon, 6 Mar 2017 18:45:08 -0500 Message-ID: Subject: Re: [v6ops] prefix length ban for RFC4861 (Re: A proposal for draft-ietf-6man-rfc4291bis-07) To: james woodyatt Content-Type: multipart/alternative; boundary=001a113f386454b63e054a187c57 Archived-At: Cc: IPv6 Operations , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 23:45:13 -0000 --001a113f386454b63e054a187c57 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The USGv6 and IPv6 Ready Logo have the same test for the PIO option with a prefix length larger then 64. It's test 2.2.19 in the IPv6 Core Test Specification . It checks that a device is capable of determining the on-link prefix with a length set to 96. All IPv6 Ready Logo/USGv6 Basic devices support this properly. ~Tim On Mon, Mar 6, 2017 at 5:26 PM, james woodyatt wrote: > On Mar 6, 2017, at 14:15, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > > BSD variants did NOT ignore PIO for on-link determination simply due > to its prefix length value at least at the time of the publication of > RFC4862 (actually since way before that RFC). For example, this is > FreeBSD's implementation as of Oct 21, 2005, about two years before > RFC4862 was published: > https://github.com/freebsd/freebsd/blob/c2b19f24a4ba01108e047a35a4a060 > cbfdf28a17/sys/netinet6/nd6_rtr.c > see nd6_prelist_add() starting at line 993, and find that it only > checks the prefix length for SLAAC (lines from 1258). At this point > the on-link determination has been completed without any check on the > prefix length (lines 1043-1056). > > > Indeed, I am unable to find source code history in FreeBSD, NetBSD or > Darwin consistent with my memory. Perhaps I am mistaken that it was ever > there. > > order to pass a certification test. I believe these implementations > will not any longer pass that test. (One imagines either their > owners don=E2=80=99t care, or the test has been revised to be more lenien= t.) > > > This is quite surprising to me. Do you have any reference to such a > certification test that requires the host to ignore PIO with a non-64 > prefix length for the purpose of on-link determination (i.e., for > RFC4861)? > > > My admittedly questionable memory is that it was a USGv6 Test Program for > SLAAC [Host] Conformance that checked for this behavior in a host > implementation I maintained at the time. As I said, I wouldn=E2=80=99t be= surprised > if that test has been revised to be more lenient, but I remember having t= o > modify the KAME source code to pass the test. > > Nevertheless, the LwIP stack does what I=E2=80=99m talking about, and it= =E2=80=99s used in > a plethora of constrained resource host operating systems these days. > > > --james woodyatt > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a113f386454b63e054a187c57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    The USGv6 and IPv6 Ready Logo have the same test for the P= IO option with a prefix length larger then 64.

    It's = test 2.2.19 in the IPv6 Core Test Specification.=C2=A0

    =
    It checks that a device is capable of determining the on-link prefix w= ith a length set to 96. =C2=A0 All IPv6 Ready Logo/USGv6 Basic devices supp= ort this properly. =C2=A0=C2=A0

    ~Tim

    On Mon, Mar 6, 2017= at 5:26 PM, james woodyatt <jhw@google.com> wrote:
    On Mar 6, 2017, at 14:15, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp> w= rote:

    B= SD variants did NOT ignore PIO for on-link determination simply due
    to i= ts prefix length value at least at the time of the publication of
    RFC486= 2 (actually since way before that RFC).=C2=A0 For example, this is
    FreeB= SD's implementation as of Oct 21, 2005, about two years before
    RFC48= 62 was published:
    https://github.com/freebsd/freebsd/blob/c2b19f24a4ba01108e04= 7a35a4a060cbfdf28a17/sys/netinet6/nd6_rtr.c
    see nd6_prelis= t_add() starting at line 993, and find that it only
    checks the prefix le= ngth for SLAAC (lines from 1258).=C2=A0 At this point
    the on-link determ= ination has been completed without any check on the
    prefix length (lines= 1043-1056).

    Indeed,= I am unable to find source code history in FreeBSD, NetBSD or Darwin consi= stent with my memory. Perhaps I am mistaken that it was ever there.

    order to pass a certification test. I believe these implementationswill not any longer pass that test. (One imagines either their
    owners = don=E2=80=99t care, or the test has been revised to be more lenient.)

    This is quite surprising to me.=C2=A0 Do you have any refere= nce to such a
    certification test that requires the host to ignore PIO wi= th a non-64
    prefix length for the purpose of on-link determination (i.e.= , for
    RFC4861)?

    My adm= ittedly questionable memory is that it was a USGv6 Test Program for SLAAC [= Host] Conformance that checked for this behavior in a host implementation I= maintained at the time. As I said, I wouldn=E2=80=99t be surprised if that= test has been revised to be more lenient, but I remember having to modify = the KAME source code to pass the test.

    Nevertheles= s, the LwIP stack does what I=E2=80=99m talking about, and it=E2=80=99s use= d in a plethora of constrained resource host operating systems these days.<= /div>


    --james woodyatt <jhw@google.com>




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




    --
    =

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --001a113f386454b63e054a187c57-- From nobody Mon Mar 6 16:01:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE981294C0 for ; Mon, 6 Mar 2017 16:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 8Z5EokLcuzPg for ; Mon, 6 Mar 2017 16:01:54 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16701294AE for ; Mon, 6 Mar 2017 16:01:53 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id p64so63793552qke.1 for ; Mon, 06 Mar 2017 16:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E2nzXuG2v8XFM6giOd6pf0cNBDTvFNbAk8Ohxa3jAC8=; b=jFlnQeMRjGfldtMOzRPG8TECa1Dn5RTUqSCCf3yLsX/EGbSR7b/LFPZZ6fdtAvpfO/ XEJb9VXmcO+xaoEZx9hlcWxui6oJ65TMOKouAVnZNMlnTWdL80tTB9iV0I/pVqog94ac sGFcohH2SET5FhS9LJjfl+Tt+/TfB8fsLvC18= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E2nzXuG2v8XFM6giOd6pf0cNBDTvFNbAk8Ohxa3jAC8=; b=mgUHMQN1WmKTM7d7dNPReyMR3sdfaCwMCdIarL1xC/jeHV4mDLDKw/XF2Ubd7ZevfI 81TgzkYTel0GUT59Lb2SXMJY5GrMd+mggjcxQq2hoyK5eRowXScu2NrW73+ZhTU6ZKwB MtJXi73wVIk6LGJnX7S9DnTlZw0BHp7RhQlarIToWoh00+jSQ2pN4XB92P7av7WwBlaE 96jX6SaGl2AIcnlkzZVuuxCwSVbfubn5Rv6MpJsQF5BpD5E9FX6XNX3+/wRmiqut0MpN etqx88yTDYoXBcwNh2Ha/jSjoDClHEvPuRFUmM+T7xV+W5+86tX2pQBfArqMcYFjnkm1 iZjQ== X-Gm-Message-State: AMke39l0f9X+EzGJooZeu2iPsC08Si8U6Y/GSB2Rc01SFgeuED0KiLUq65ViMTFi43YSMNjGWZ7lpRr2LPwxK2YK X-Received: by 10.237.54.194 with SMTP id f60mr20143360qtb.123.1488844912746; Mon, 06 Mar 2017 16:01:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Mon, 6 Mar 2017 16:01:51 -0800 (PST) In-Reply-To: <225F639E-27C1-4408-BC2B-26500929049B@google.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> From: Timothy Winters Date: Mon, 6 Mar 2017 19:01:51 -0500 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: james woodyatt Content-Type: multipart/alternative; boundary=001a1145c194267417054a18b8f4 Archived-At: Cc: Philip Homburg , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 00:01:56 -0000 --001a1145c194267417054a18b8f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James and Philip, I wanted to quickly comment on this line. On Mon, Mar 6, 2017 at 3:53 PM, james woodyatt wrote: > On Mar 6, 2017, at 10:47, Philip Homburg > wrote: > > > Finally, the 'MUST drop' interpetation is not consistent with the > behavior of FreeBSD, MacOS, and Linux. So I now start to wonder where > the 'MUST drop' interpretation comes from and if anyone ever bothered > to check out the behavior of existing stacks. > > Yes, IPv6 Ready Logo and USGv6 Test Programs confirm that stacks process PIO with a length larger then 64 bits for on-link determination. This works with most IPv6 stacks today. > > Looking at the relevant source code for a couple of the latest BSD-varian= t > kernels, I believe you=E2=80=99re right about the current behavior on tho= se > platforms. My memory of them must be outdated. I think they used to drop > PIO according to a strict interpretation of RFC 4862. I distinctly rememb= er > having to implement it that way in order to pass a certification test. I > believe these implementations will not any longer pass that test. (One > imagines either their owners don=E2=80=99t care, or the test has been rev= ised to be > more lenient.) > > I am however looking at a commonly used lightweight IP stack that simply > ignores all PIO options unless Prefix Length =3D 128 - IID Length (and it > safely assumes all interface identifiers are length 64 because it doesn= =E2=80=99t > support link types with other IID lengths, and it=E2=80=99s also unsuitab= le for use > in the environments where IETF standards make exceptions for other IID > lengths). This stack was developed entirely apart from the Linux and KAME > efforts, by people who read the fine RFCs and implemented the simplest > lightest-weight thing possible that is still compliant with the > requirements language. That=E2=80=99s important for people on platforms w= here every > byte of code and stack space is precious. > > p1. I get that RFC 4862 has requirements language that annoys some > participants. We are not here revising RFC 4862 however, so that=E2=80=99= s not > relevant. > > p2. The stack I=E2=80=99m using implements SLAAC and-- for completely def= ensible > reasons=E2=80=94 follows the letter of RFC 4862 requirements. Its current= behavior > is compliant with RFC 4291, RFC 4861 and RFC 4862. It=E2=80=99s not exact= ly > uncommon in the field today, and it=E2=80=99s not currently broken by the= proposed > successor to RFC 4291 with its current language about IID length. > > p3. I get that people want to hold up promotion of IPv6 to Full Standard > until the successor of RFC 4291 is changed to declare explicitly that the > stack I=E2=80=99m using is in error. My opinion is this is a procedural m= atter, not > a technical matter. > > I object to the procedural step being proposed, not the technical > argument. If we MUST declare the stack I=E2=80=99m using to be in error, = then > please let=E2=80=99s NOT do it in this draft. Can you not wait until RFC = 4861 and > RFC 4862 are next revised? > > > --james woodyatt > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a1145c194267417054a18b8f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi James and Philip,

    I wanted to quickl= y comment on this line.

    On Mon, Mar 6, 2017 at 3:53 PM, james woodyatt <jhw@google.com> wrote:
    On Mar 6, 2017, at 10:47, Philip Homburg &l= t;pch-v6ops= -6@u-1.phicoh.com> wrote:

    Finally, the 'MUST drop' interpetation is = not consistent with the
    b= ehavior of FreeBSD, MacOS, and Linux. So I now start to wonder where=
    the 'MUST drop' interpr= etation comes from and if anyone ever bothered
    to check out the behavior of existing stacks.<= /div>
    Yes, =C2=A0IPv6 Read= y Logo and USGv6 Test Programs confirm that stacks process PIO with a lengt= h larger then 64 bits for on-link determination. =C2=A0 This works with mos= t IPv6 stacks today.

    Looking at th= e relevant source code for a couple of the latest BSD-variant kernels, I be= lieve you=E2=80=99re right about the current behavior on those platforms. M= y memory of them must be outdated. I think they used to drop PIO according = to a strict interpretation of RFC 4862. I distinctly remember having to imp= lement it that way in order to pass a certification test. I believe these i= mplementations will not any longer pass that test. (One imagines either the= ir owners don=E2=80=99t care, or the test has been revised to be more lenie= nt.)

    I am however looking at a commonly used light= weight IP stack that simply ignores all PIO options unless Prefix Length = =3D 128 - IID Length (and it safely assumes all interface identifiers are l= ength 64 because it doesn=E2=80=99t support link types with other IID lengt= hs, and it=E2=80=99s also unsuitable for use in the environments where IETF= standards make exceptions for other IID lengths). This stack was developed= entirely apart from the Linux and KAME efforts, by people who read the fin= e RFCs and implemented the simplest lightest-weight thing possible that is = still compliant with the requirements language. That=E2=80=99s important fo= r people on platforms where every byte of code and stack space is precious.=

    p1. I get that RFC 4862 has requirements language= that annoys some participants. We are not here revising RFC 4862 however, = so that=E2=80=99s not relevant.

    p2. The stack I=E2= =80=99m using implements SLAAC and-- for completely defensible reasons=E2= =80=94 follows the letter of RFC 4862 requirements. Its current behavior is= compliant with RFC 4291, RFC 4861 and RFC 4862. It=E2=80=99s not exactly u= ncommon in the field today, and it=E2=80=99s not currently broken by the pr= oposed successor to RFC 4291 with its current language about IID length.

    p3. I get that people want to hold up promotion of I= Pv6 to Full Standard until the successor of RFC 4291 is changed to declare = explicitly that the stack I=E2=80=99m using is in error. My opinion is this= is a procedural matter, not a technical matter.

    I= object to the procedural step being proposed, not the technical argument. = If we MUST declare the stack I=E2=80=99m using to be in error, then please = let=E2=80=99s NOT do it in this draft. Can you not wait until RFC 4861 and = RFC 4862 are next revised?


    --james woodyatt <jhw@google.com>




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




    --
    =

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --001a1145c194267417054a18b8f4-- From nobody Mon Mar 6 16:25:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A195F12941C for ; Mon, 6 Mar 2017 16:25:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 R_dEg3jaiq-R for ; Mon, 6 Mar 2017 16:25:35 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E105612946D for ; Mon, 6 Mar 2017 16:25:34 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id 25so72040685pgy.0 for ; Mon, 06 Mar 2017 16:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aP4hC9J6REDGC0Zto7SOj0X8mEf4txIDYsZeYVHSESg=; b=ARLiMy3ge3afRyFoTO4M6DozPV6wx493+KpvdLpOcG9MfyyD79GmzcvvrcTxLLbMN+ ebkkQ5wc5lBZN5+87uptB+EEiuN4NZxsWHQTHmvgqqNPSeAIQNQ2V5LpUYxjuMEdwBTy Yd9IQM/O+agXZthsLZqDxLOgLa9W6rPpBJZO8mmTQxzEsTGeBRBMKc44mgLKJMb4joiX UsZZa2JckKjK2dQ0kOVJIz5DHlks3oOnn8SULmu8W1M25aiqYvUlidSL2n2MIb12m/kE Yw0CT8M/Kl6OudCoCSTs9NmGlKl+AF3PGeVfGVvmNSz9meD+MPJxXpF6B8H63Iwf4KI1 EHEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aP4hC9J6REDGC0Zto7SOj0X8mEf4txIDYsZeYVHSESg=; b=RFmx+fPNrmPwy/T/pz8f4wCNR8eYuJQWc2a7v/vSGwF3q22V09IPJYoIXfDFU7ul54 76jTASxE9dtMsr0jhEzvs1S58bHbneX8885zp1h9SU/9XcX8/y1pg5HTFzkGXrr6hKiP 35lmpsn/RaBumMqZz6GjM1DOutjGYK1RTL4Vh7OYxfd7HU2+CQuJFfgf80+LTnYgarSy YI35mqxR+X8eKuL0NPavxk4/feO5mLqAgF+qlt4y5361GHo5W5uYXZv4xxdBgrRBpJvP M/fUSJd7QjV3a4j/MWHJ2NNASlJzKI5LhfIY4cd2YIWc14PtreqQqhkNpIvgdNoUR5ew 5wPw== X-Gm-Message-State: AMke39mEN88sP2bLSgfHhhu4CU5+jy8gBLIND/NMqWIFuRb6XTK+FVtLZBpX+J5UGfoYKr6J X-Received: by 10.84.140.131 with SMTP id 3mr30578310plt.151.1488846334205; Mon, 06 Mar 2017 16:25:34 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id c11sm41705699pfe.68.2017.03.06.16.25.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 16:25:33 -0800 (PST) From: james woodyatt Message-Id: <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8E499961-403A-41A4-8FB1-4D28B16405FF" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 Date: Mon, 6 Mar 2017 16:25:31 -0800 In-Reply-To: To: Timothy Winters References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 00:25:36 -0000 --Apple-Mail=_8E499961-403A-41A4-8FB1-4D28B16405FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 6, 2017, at 16:01, Timothy Winters wrote: > On Mon, Mar 6, 2017 at 3:53 PM, james woodyatt > wrote: > On Mar 6, 2017, at 10:47, Philip Homburg > wrote: >>=20 >> Finally, the 'MUST drop' interpetation is not consistent with the >> behavior of FreeBSD, MacOS, and Linux. So I now start to wonder where >> the 'MUST drop' interpretation comes from and if anyone ever bothered >> to check out the behavior of existing stacks. >=20 > Yes, IPv6 Ready Logo and USGv6 Test Programs confirm that stacks = process PIO with a length larger then 64 bits for on-link determination. = This works with most IPv6 stacks today. Hmm. I seriously remember failing that test in the other direction: = accepting the prefix when it was supposed to be ignored. Maybe I=E2=80=99m= mistaken. In any case, my opinion is that the IPv6 Ready Logo test and the USGv6 = test would be imposing a stricter test than called for by the = requirement language in RFC 4862 if it requires on-link determination to = succeed on PIO with an invalid Prefix Length for the link type, and = it=E2=80=99s a test for a feature that some constrained host = implementations don=E2=80=99t currently implement. Those stacks (like the one I=E2=80=99m using now) that would fail the = IPv6 Ready Logo and USGv6 tests are still compliant with RFC 4862, and I = think the successor to RFC 4291 shouldn=E2=80=99t declare them broken. --james woodyatt > --Apple-Mail=_8E499961-403A-41A4-8FB1-4D28B16405FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 6, 2017, at 16:01, Timothy Winters <twinters@iol.unh.edu> wrote:
    On Mon, Mar 6, 2017 at = 3:53 PM, james woodyatt <jhw@google.com> wrote:
    On Mar 6, = 2017, at 10:47, Philip Homburg <pch-v6ops-6@u-1.phicoh.com> wrote:

    Finally, the 'MUST drop' = interpetation is not consistent with the
    behavior of FreeBSD, MacOS, and Linux. So I now start to = wonder where
    the 'MUST drop' = interpretation comes from and if anyone ever bothered
    to check out the behavior of existing = stacks.
    Yes,  IPv6 Ready Logo and USGv6 Test Programs confirm = that stacks process PIO with a length larger then 64 bits for on-link = determination.   This works with most IPv6 stacks = today.

    Hmm. I seriously remember failing that test in the = other direction: accepting the prefix when it was supposed to be = ignored. Maybe I=E2=80=99m mistaken.

    In any case, my opinion is that the IPv6 Ready = Logo test and the USGv6 test would be imposing a stricter test than = called for by the requirement language in RFC 4862 if it requires = on-link determination to succeed on PIO with an invalid Prefix Length = for the link type, and it=E2=80=99s a test for a feature that some = constrained host implementations don=E2=80=99t currently = implement.

    Those stacks (like the = one I=E2=80=99m using now) that would fail the IPv6 Ready Logo and USGv6 = tests are still compliant with RFC 4862, and I think the successor to = RFC 4291 shouldn=E2=80=99t declare them broken.

    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_8E499961-403A-41A4-8FB1-4D28B16405FF-- From nobody Mon Mar 6 16:34:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988E8129532 for ; Mon, 6 Mar 2017 16:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 szIUgxXInVsn for ; Mon, 6 Mar 2017 16:34:45 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC7912941C for ; Mon, 6 Mar 2017 16:34:45 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id 1so183250173qkl.3 for ; Mon, 06 Mar 2017 16:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=808AdRTJFOtR3F59w8PdhHw86ijDiwjCXQPEa+i2veM=; b=AH4RwMToV/Ay+7jI7TgfUVuZSTKMJmPAMrygie/+JcYbK9Cvx8buyQz1XcPJNziGA1 zsp8cBSk9jkxhP4d327ju9lVINbupGXR+r+9utwySWZAATqSh+VwAfWv31LhcSqA4SkK Ug7ttIz0B37eZxE6eD3uNIjlQMayGqqT82xTA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=808AdRTJFOtR3F59w8PdhHw86ijDiwjCXQPEa+i2veM=; b=PP0tI8XuK4WEBdCOeLKmq40qhP4DQTwfaIChlCypngxP8RK6b23Y1cNk4szhTaIZTd 1nnwajeP7P6bRB4NLe/mlCh19Dq9GopzueSA8c9N3eXThIGIWFazaq3TxjId9qujPN8H MYPxAQTQcMohPyWm3boAKx+IxlFHOpv73EIX3plRAtNrZH/EuUfChTkLBkwCVL36hJIC 01UjS30vj5FadqSChLjQnXEgRGWwRPwZbI++6B8gkD1AEzSuhfat95Nk8ez+Dv9AmSsH tSao54GsQRYdOGWSXIL9aXuGF08dzd/L10zJEx7Ka9gsRQtZUci6fzBVnXKG9B5gbSU9 MpgQ== X-Gm-Message-State: AMke39ls7FnfOS3CO7DDehCagg1X4HsQE7mus0VT0aMBFo/5ob0qEgDCXTj9KQd87KCZWFzLcoBAvEjw6StiA32q X-Received: by 10.200.45.57 with SMTP id n54mr19552902qta.212.1488846884230; Mon, 06 Mar 2017 16:34:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Mon, 6 Mar 2017 16:34:43 -0800 (PST) In-Reply-To: <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> From: Timothy Winters Date: Mon, 6 Mar 2017 19:34:43 -0500 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: james woodyatt Content-Type: multipart/alternative; boundary=001a1142aca4a8fa89054a192d82 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 00:34:47 -0000 --001a1142aca4a8fa89054a192d82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, I don't believe this test is too strict based on 4862 Section 6.3.4 " Similarly, [ADDRCONF ] may impose certain restrictions on the prefix length for address configuration purposes. Therefore, the prefix might be rejected by [ADDRCONF ] implementation in the host. However, the prefix length is still valid for on-link determination when combined with other flags in the prefix option." Basically ND still works even if SLAAC thinks the prefix length is invalid. It's really a ND test for on-link deteremination. ~Tim On Mon, Mar 6, 2017 at 7:25 PM, james woodyatt wrote: > On Mar 6, 2017, at 16:01, Timothy Winters wrote: > > On Mon, Mar 6, 2017 at 3:53 PM, james woodyatt wrote: > >> On Mar 6, 2017, at 10:47, Philip Homburg >> wrote: >> >> >> Finally, the 'MUST drop' interpetation is not consistent with the >> behavior of FreeBSD, MacOS, and Linux. So I now start to wonder where >> the 'MUST drop' interpretation comes from and if anyone ever bothered >> to check out the behavior of existing stacks. >> >> Yes, IPv6 Ready Logo and USGv6 Test Programs confirm that stacks proces= s > PIO with a length larger then 64 bits for on-link determination. This > works with most IPv6 stacks today. > > > Hmm. I seriously remember failing that test in the other direction: > accepting the prefix when it was supposed to be ignored. Maybe I=E2=80=99= m mistaken. > > In any case, my opinion is that the IPv6 Ready Logo test and the USGv6 > test would be imposing a stricter test than called for by the requirement > language in RFC 4862 if it requires on-link determination to succeed on P= IO > with an invalid Prefix Length for the link type, and it=E2=80=99s a test = for a > feature that some constrained host implementations don=E2=80=99t currentl= y > implement. > > Those stacks (like the one I=E2=80=99m using now) that would fail the IPv= 6 Ready > Logo and USGv6 tests are still compliant with RFC 4862, and I think the > successor to RFC 4291 shouldn=E2=80=99t declare them broken. > > --james woodyatt > > > > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a1142aca4a8fa89054a192d82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi James,

    I don't believe this test= =C2=A0is too strict based on 4862 Section 6.3.4 "Similarly,
       [ADDRCONF=
] may impose certain restrictions on the prefix length for
   address configuration purposes.  Therefore, the prefix might be
   rejected by [ADDRCONF] implementation in the host.  However, the
       prefix length is still valid for on-link determination when co=
mbined
       with other flags in the pr=
efix option."

    Basically ND still works even if SLAAC thinks th=
e prefix length is invalid.   It's really a ND test for on-link deterem=
ination.

    ~Tim

    On Mon, Mar 6, 2017 at 7:25 PM, james woodyatt <jhw@google= .com> wrote:
    On Mar 6, 2017, at 16:01, Timothy Wi= nters <twinter= s@iol.unh.edu> wrote:
    On Mon, Mar 6, 2017 = at 3:53 PM, james woodyatt=C2=A0<jhw@google.com>=C2=A0wrote:
    On Mar 6, 2017, at 10:47, Ph= ilip Homburg <pch-v6ops-6@u-1.phicoh.com> wrote:

    Finally, the &= #39;MUST drop' interpetation is not consistent with the
    behavior of FreeBSD, MacOS, and Linux. S= o I now start to wonder where
    the 'MUST drop' interpretation comes from and if anyone ever b= othered
    to check out the = behavior of existing stacks.
    Yes, =C2=A0IPv6 Ready Logo and USGv6 Test Programs confirm = that stacks process PIO with a length larger then 64 bits for on-link deter= mination. =C2=A0 This works with most IPv6 stacks today.
    <= /div>

    Hmm. I seriously remember fai= ling that test in the other direction: accepting the prefix when it was sup= posed to be ignored. Maybe I=E2=80=99m mistaken.

    I= n any case, my opinion is that the IPv6 Ready Logo test and the USGv6 test = would be imposing a stricter test than called for by the requirement langua= ge in RFC 4862 if it requires on-link determination to succeed on PIO with = an invalid Prefix Length for the link type, and it=E2=80=99s a test for a f= eature that some constrained host implementations don=E2=80=99t currently i= mplement.

    Those stacks (like the one I=E2=80=99m u= sing now) that would fail the IPv6 Ready Logo and USGv6 tests are still com= pliant with RFC 4862, and I think the successor to RFC 4291 shouldn=E2=80= =99t declare them broken.

    --james woodyatt <jhw@google.com>






    --

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --001a1142aca4a8fa89054a192d82-- From nobody Mon Mar 6 17:11:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CAD129A78 for ; Mon, 6 Mar 2017 17:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0WwvY36tRUEP for ; Mon, 6 Mar 2017 17:11:09 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F9E1298A0 for ; Mon, 6 Mar 2017 17:11:08 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id 1so184296007qkl.3 for ; Mon, 06 Mar 2017 17:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nAgrmHEgUTaR7kqdsFArU6G/NGmKp/nTsNhO9FGo3bM=; b=d+Brf4s2+qMPUzynBSVEqjFY7Xf6lqxijqdeS/IEBejH0+2M8n7amEAAUff/hrYRU+ sx8EPajkeP+LyOvSaVU9jTaQu4y+3zVr63dWNr9cMSywgnJG92uLhS15W5Mt9F2j4sog n3+CrUCVYoBBf64Z8ZcyM+HzPtilgfjjbGA3w2JLSU/1sKxsyKeYu/sbHrU2Tf8RvOpA v1wHKeUU7ldB9f20BmIoI7QGiPksmbzAlH3YuwGUjqThD1VIlaPjMg+d/bkxfuHJlWX+ 540CzAeqsatQuBnrYEWZ0iBMsRyAjCs7G8q9E5SjkiyXmGQ0t56JS4++jSBPl2o2yrTX MWUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nAgrmHEgUTaR7kqdsFArU6G/NGmKp/nTsNhO9FGo3bM=; b=L5V6YU5ujSR1dzJOpZGAzp/PfqzEnedNbbKvKJ4fsDrgp75L0xDG/RmJS1c7lzZTIz J3Yv06xOfR6gWN/W9c33sIv00wYeDCCMYINyTVBK3B1M68U4qFxKdcN4JyKdUjZS2t2H Ckd8Jk+QHhc3RXrzRDbTUDq1z+o5aP4cOfhmHDiZ4hYUXgkskR+q6cBvyOfjyTCtSlRx bYWHU4bKTsCMfhlckZ+91OFe3l3R+KORJn7wIuW1QiPfbyCSiI2Gre7G8wDy6mdLFTB5 CfoH3EN9IL6wRiXmyI7EQK0nMT5JOSmjNL42w5QShvksWJHrcnq6INgZomX0DYSJbIOC aMIg== X-Gm-Message-State: AMke39lHFSJDPtNurJk+jeBjpKIALJrYGQ2/L4LfroIjQDZTn2oiff6TyW2kgWJ97/OVf9uWCv03p+Sd5joqvQ== X-Received: by 10.55.112.66 with SMTP id l63mr18074178qkc.149.1488849067891; Mon, 06 Mar 2017 17:11:07 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Mon, 6 Mar 2017 17:11:07 -0800 (PST) In-Reply-To: References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 6 Mar 2017 17:11:07 -0800 X-Google-Sender-Auth: b_dg3CNvmVy4Tq1bfgy6FZgKymc Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: Timothy Winters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: james woodyatt , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 01:11:10 -0000 At Mon, 6 Mar 2017 19:34:43 -0500, Timothy Winters wrote: > I don't believe this test is too strict based on 4862 Section 6.3.4 " > Similarly, > > [ADDRCONF ] may > impose certain restrictions on the prefix length for > address configuration purposes. Therefore, the prefix might be > rejected by [ADDRCONF > ] implementation in > the host. However, the > > prefix length is still valid for on-link determination when combined > with other flags in the prefix option." > > Basically ND still works even if SLAAC thinks the prefix length is > invalid. It's really a ND test for on-link deteremination. I'd also note that the above text didn't exist in RFC2461; it was newly introduced in RFC4861. If I remember it correctly the added text was an attempt of clarifying validation for on-link determination and validation for SLAAC are independent, as it had often been misunderstood. RFC4862 also tried to clarify that point, e.g., in this text: [...] It should be noted, however, that this does not mean the advertised prefix length is meaningless. In fact, the advertised length has non-trivial meaning for on-link determination in [RFC4861] where the sum of the prefix length and the interface identifier length may not be equal to 128. But this thread and another similar discussion seem to suggest that it's still not clear enough for some people. At least two different readers interpret this text: If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. as the PIO MUST be ignored for all purposes including on-link determination. In a sense, it's not necessarily surprising - no matter how we try to clarify a point there's always a reader that still interprets it differently. But if there is really a protocol conformance test that doesn't interpret the text differently it's really surprising to me. The bottom line is, if there is an implementation that ignores a PIO - with both L and A flag on, and - with prefix length being something other than 64 - received on a link whose IID is specified to be 64 (like Ethernet) even for on-link determination, then that implementation violates RFC4861. I can also assure that the document editor of RFC4862 didn't intend such "strictness" - on the contrary, he actually tried to clarify that's not the intent, but it looks like it's still not super clear. -- JINMEI, Tatuya From nobody Mon Mar 6 17:38:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AB6129A80; Mon, 6 Mar 2017 17:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7A8wqTqxGT6I; Mon, 6 Mar 2017 17:38:43 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACD5129860; Mon, 6 Mar 2017 17:38:42 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id n11so78064479wma.1; Mon, 06 Mar 2017 17:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oB/79nhduDwV115IhdiiKWmzAQ9yKp4XgoyRrPkHMKc=; b=iBW6rik3k6kEnWd5lzYvPZ2MkAR/SFKAdB1TVask6nMLGofCdtsZ97iRz3i8LV4r2y 3MN5+fes4M142dtg4EvVBTsionqXRaAQOou1ZfbxmZQRBMVNRRkZeoWQVcFwjA0oRK0D RQDumnAW4QbsjOwxyLz3+zTThzxjMUhPwSrEiepJq0djcxkbP7zqoq2Rlg6JdOuZNrOr NAufZ8c0Scc+6Vyc1d+GNSf3BdaXXSnCJ1x4gIGGhGHeeylsxYtt+EBleHNjHA4RdUma 6AX0CkKKbRld+miXw4tUyvj2eNNhh+77XQnMCZPnVkuENSpGYfWrbckpfeQWNG2Owh7W Clsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oB/79nhduDwV115IhdiiKWmzAQ9yKp4XgoyRrPkHMKc=; b=cK8WAylRgvjwFrZ8XUlCODTPQ7y89KK+hzFzioW/goRe/uuCEWgPgqLIdpjUu4kmmT dPqi1NugQMvo+0k8t2QgQtJmZ0Yc7QP4RffTG6C8T87K1MTlPh1A3Uf01ge4B/de412D 5dJvpWS1twHNnaz+ozUWAk/Fw5jjyxVmbE7A7mlTdWEdJyDKtGgwN3/4kTleQZfBILHQ og/Z8jrmMdhlTdrF1hyBC0gL8DjV7MaoIPltxZhPb1XCHVE46f9mfxAYHIpjkqjbhypf ohcF+RZ2Pc0e6XulmhCshdtd8e1dBvmJqmctN9C1ntmHFJbFfu6f+FQd2jGRHhCuMwMm Y54Q== X-Gm-Message-State: AMke39mTCktvfhYYBQ+hCRPpl33m7m+zG9chng6vaFkmIJ07RbQl/bFNxY+0Kud5oXqUUg== X-Received: by 10.28.129.212 with SMTP id c203mr15194567wmd.19.1488850721378; Mon, 06 Mar 2017 17:38:41 -0800 (PST) Received: from ?IPv6:2601:647:4d01:db10:f96e:fb7:ae30:96cb? ([2601:647:4d01:db10:f96e:fb7:ae30:96cb]) by smtp.gmail.com with ESMTPSA id 40sm29025664wry.22.2017.03.06.17.38.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 17:38:40 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6B728FC0-4A7A-4D8D-BCC1-5F5BCA1AE842"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Review of draft-ietf-6man-rfc1981bis-04 Date: Mon, 6 Mar 2017 17:38:33 -0800 In-Reply-To: <148864769030.23464.9110014115039938058.idtracker@ietfa.amsl.com> To: Susan Hares References: <148864769030.23464.9110014115039938058.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , ops-dir@ietf.org, Bob Hinden , IETF , draft-ietf-6man-rfc1981bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 01:38:46 -0000 --Apple-Mail=_6B728FC0-4A7A-4D8D-BCC1-5F5BCA1AE842 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sue, Thanks for the review, comments below. Bob > Reviewer: Susan Hares > Review result: Has Issues >=20 > ack, Steve,Jeffrey, and Bob: >=20 > Thank you for taking on this important revision to the document. I > hope my comments help to improve the document so this important change > can ge deployed. Thanks >=20 > I have reviewed this as part of the routing directorate review. This > review should be treated as any IETF LC comments. >=20 > Sue Hares >=20 > RTG-DIR Review >=20 > Status: I have three concern plus editorial nits. >=20 > #1 - Concern 1 is technical regarding the interaction with the MTU > option in ND/SEND plus > ditorial nits. See the comments below. I am not an ND/SEND Expert, > please have an imoplementer look at the requirements. >=20 > Concern: I cannot tell how this interacts with the ND/SEND protocol in > the following areas below. > 1) Neighbor Unreachability Detection is used for all paths between > hosts > and neighboring nodes, including host-to-host, host-to-router, and > router-to-host communication. >=20 > If the source node is on the link and the destination node > available > through the router, and the router is in the process of sending a > MTU option to increase the size? How does your algorithm work? I believe what will happen is that the host will use the new MTU in any = new connections it establishes. Existing connections will continue = with preview MTU. I also note, that this would be a very rare event as most LANs do not = dynamically change their MTU. >=20 > Are the packetization layer notified? > Is the original value a stale notification over time? > You indicate it MUST NOT be done in less than 5 minutes, and that > 10 minutes is the norm. >=20 > Is 10 minutes really the best response time for this particular > case? > Or did I miss something in your draft? See above. >=20 >=20 > 2) Assume the same situation as #1, but the > router sends an MTU option to decrease the size. >=20 > In this case, the router is sending information that > the MTU has changed, but the first indication for the > end system is based on a Packet-too-Big Message after sending. I think receiving PTB messages would be the likely result for existing = connections. The host would respond by reducing it=E2=80=99s packet = size. New connections would use the new MTU. As above, this should be a very rare occurrence. >=20 >=20 > 3) For a multicast packet (3000 bytes), assume that > the multicast path reaches two different routers (router-a > and router-b). Assume the on-link MTU is 3500 bytes, but the > previous router-A and router-B MTU is 2500 bytes. >=20 > Router-a responds to the packet with 10ms sending a > MTU option that changes the MTU to support this packet. Router-B sends > a redirect > for multicast address to Router-A after 30 ms. >=20 > What happens to your path calculation? > Is this again, the 5 minutes (minimum) and 10 minute normal to > reset this value. The host would use the lowest MTU it received and act accordingly. This = is described in the fifth paragraph of Section 3. >=20 > 4) What happens if the ND process is instantiated by > SEND protocol, and the host does not contain the appropriate > certification information to timely updates? >=20 > Again, the host guessing at the appropriate value? I don=E2=80=99t follow this? Please explain. This seems more about a = question about SEND, and not rfc1981bis. >=20 >=20 > #2 - Concern 2 - How does SEND's implementation of MTU option. > mitigate or have no effect on this MTU. Is there a recommendation > that should be made in section 6. Again, please ask a SEND expert > for review. It works the same. SEND secures ND, it still uses ND. The SEND RFC = doesn=E2=80=99t even reference RFC1981. >=20 > #3 - Concern 3 - content of document >=20 > This document has two parts: protocol requirements and implementation > requirements. > 8 paragraphs (1 page) indicates the IPv6 specification and 6 pages > gives the implementation? >=20 > Why did this get split in to 2 documents? Even if this was a bis, > document would it not > be better to provide minimal specification for the protocol change and > a larger document > with implementation information. >=20 > I'm fine with the WG/ADs deciding, this is the way the document has to > go forward -- but the question should be asked. The working groups intent in doing this bis document was to make a few = changes to fix a problem related to a change in RFC2460bis, remove = mention of RH0 because it was deprecated earlier, and a few other small = changes. It was not to do a major rewrite of the document (or as you = suggest, split it into two documents). The alternative was just to file = an errata on RFC1981. This document is very widely implemented. I don=E2=80=99t think = splitting the document into two would improve anything, and very likely = create confusion for the current implementations. >=20 > Editorial nits: > #1 nit - section 5.2 page 8, paragraph beginning >=20 > Old /Note: if the / > New/Note: If the/ >=20 > #2 nit - section 5.2 page 9 paragraph begin >=20 > Old /Note: even if/ > New /Note: Even if/ >=20 > #3 nit - section 5.3 page 10 paragraph beginning >=20 > Old /Note: an implementation/ > New/Note: An implementation/ >=20 >=20 Noted. Thanks. --Apple-Mail=_6B728FC0-4A7A-4D8D-BCC1-5F5BCA1AE842 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYvg8aAAoJEK7rdBF357uoB4gIAIoJRdewJbpUW76Pt4jlgE2e 8y9YcTzuqenSjj8gr+f5EM3Rvux1xpiqb9/zdwUTCaQ/YxXdrKNWZcxdqp7G0MjU SwwKUHc0D1iCaZYASiClqnuV1SudiWI37xsuVFWd3gM3usL/h0CIx9/ZCzsiunvQ F/gjSvmuBGRQoAFczAm6JdNZv8qk2sUGL8Hp6+YEm0DI0NSlyjISXQmJW36UZrFI MPbE40LQqDnth2OG90WVMckWQcRFHl+oCXBbncTESgMCIl4Y2IyLMidbBW5I3VxC r35TfYZiFSRWe+1gIn/l5Wx/WdR+qBuif5iWfG6lEuQOmdIgaQJynVf74K9aV0g= =GkvY -----END PGP SIGNATURE----- --Apple-Mail=_6B728FC0-4A7A-4D8D-BCC1-5F5BCA1AE842-- From nobody Mon Mar 6 19:19:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BCE1293E1 for ; Mon, 6 Mar 2017 19:19:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Hx8OE1csJWV4 for ; Mon, 6 Mar 2017 19:19:03 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2051293D8 for ; Mon, 6 Mar 2017 19:19:03 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id u30so60966907uau.0 for ; Mon, 06 Mar 2017 19:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=42rqpB2vAqG7c6XpiQpAHigzT3TqjcvxUF7kQWZh1ak=; b=TAO/GwS9t/XVqcvFNQAQratBPNlNGQTCy5I1/y/xh3kbYbTZvAxc7LxNbLIPS7TbUZ Jv6R7jjymZseMueQQNPnQxOH1fYitT545m4OndIZbMQcoRAZjrlTb9obdr/3bc5TkWsD FRgBZQ185VNRjSAp/jo/Wpw90xEZD2yxV7sehowLbUNVc1CxrgB01r+7NejPRJVD9TfB IbDfu2pgJX4Npw10yOs7dBfIt+Ix8bLni05FxKhd7Z4gENDFmhwnBDRHMHKKCOsVFMn4 lvH50X8dJ7cXMzVS3QzcyHjvJtUoi8499zSHhi54VUQc80uSr6DiTt6ILarHnpI73xgy MTfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=42rqpB2vAqG7c6XpiQpAHigzT3TqjcvxUF7kQWZh1ak=; b=Cny3+3jrPpwsla66iChJIrRa4E/ZPd8QoTFMZmJMkQXnlFMAfzYims9RygeJiF76k4 OQSoWC4nbjRQGDA5YFr0lwJn7mvIsahcV4wOt/LfPrxRdDPuv4DHCkQxSyTR6wWbYPS4 gp4ewWY4DCYwv13/y1/jdncDF+eMHJFvG4SuZmSNexIjBgtxX6CY+k8fo51pQYgJd0t9 nngCkGyu6imsJm7c2RVFbd/7GP7/0aE/f91EoA6Ta4k3ENpUKOShP+Yg97NaiZ8BBMbW TgMBBNlT1f4lG5F69vlHy9itkd2pB2B03itPxobBKZMkL2P2uOgtd/P/BPdNBX9EKi+Z llbA== X-Gm-Message-State: AMke39nVdy+tamQyNL0Mjde621fwhEPy9bLYeZet7guTF4rjGRm4t5aFVownCkL2hoUEOy/kLRbmuBZwgq5NCGu1 X-Received: by 10.31.170.15 with SMTP id t15mr7065299vke.6.1488856742039; Mon, 06 Mar 2017 19:19:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 6 Mar 2017 19:18:41 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 7 Mar 2017 12:18:41 +0900 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: David Farmer Content-Type: multipart/alternative; boundary=001a114322503b9dc3054a1b79a8 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:19:04 -0000 --001a114322503b9dc3054a1b79a8 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 7, 2017 at 4:05 AM, David Farmer wrote: > > Instead, I would suggest another approach: see what the problems with 4291 >> are, *write them down*, and only then write a document explaining what >> should be changed and why. >> > > The list of 7 points are the problems that many see with 4291bis, maybe > overly summarized, but they are there. > Well, but what you provided is an alternative solution, not a problem statement. Example of a problem statement would be, "RFC 4291 does not allow non-64-bit IID lengths. However, assigning smaller prefix lengths is necessary because [...]". I can't help fill in the [...] because I personally don't see what you can do with a /113 that you can't do with a /64 (other than conserve addresses, which has always been a non-goal), but there seem to be several participants who do see a problem. What I'm saying is that if we want to change the standard, the people who see a problem with it should articulate that problem in a way that it's possible to find a solution using informed and documented engineering trade-offs rather than opinions. --001a114322503b9dc3054a1b79a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= ue, Mar 7, 2017 at 4:05 AM, David Farmer <farmer@umn.edu> wrote= :=C2=A0
    Instead, I would suggest another approach: see what = the problems with 4291 are, *write them down*, and only then write a docume= nt explaining what should be changed and why.

    The list of 7 points are the problems that many= see with 4291bis, maybe overly summarized, but they are there.
    =

    Well, but what you provided is= an alternative solution, not a problem statement. Example of a problem sta= tement would be, "RFC 4291 does not allow non-64-bit IID lengths. Howe= ver, assigning smaller prefix lengths is necessary because [...]".

    I can't help fill in the [...] because I personal= ly don't see what you can do with a /113 that you can't do with a /= 64 (other than conserve addresses, which has always been a non-goal), but t= here seem to be several participants who do see a problem. What I'm say= ing is that if we want to change the standard, the people who see a problem= with it should articulate that problem in a way that it's possible to = find a solution using informed and documented engineering trade-offs rather= than opinions.
    --001a114322503b9dc3054a1b79a8-- From nobody Mon Mar 6 19:35:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36A12956B for ; Mon, 6 Mar 2017 19:35:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3WLIZ4nf9Piv for ; Mon, 6 Mar 2017 19:35:41 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEB812706D for ; Mon, 6 Mar 2017 19:35:41 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 77so29345063pgc.1 for ; Mon, 06 Mar 2017 19:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j8oClpuzR31X/xomgAylVmoGLhSVAdQTGobIFlTqFYk=; b=eNxjILp7F4jkpPGfMwOTOhDnKSRJTzUzZphzzaP4Q6GkI3tNtdQ8xeFijeHQjntHpb B1r84jr2o3e+2kKm7uPMHrEqAtXE6s8q1vWSIpOBX2mo6y9kP7YYPZn3484LtpycE4YL WKHeIqleqJa37BOLCAVBBHMqofvchKP3jYkfoANxmsB/ciqrFCiETL/CeN41V3rIhkyl DgrPz6jVLEi4RLcw9Oa4j3i/rP/t+o5hk/e1LFEUN25wEOMimJqdt01cjdzi5AapWmuY h4RV6hxYOBKqBCce6h62YuggeSx48oFrpu0QL4Wes8m0vENnUnUv4hLdWgcKx/mZlxRb qjCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j8oClpuzR31X/xomgAylVmoGLhSVAdQTGobIFlTqFYk=; b=E7OmRh6nkBhOvP2czsLBIEOWncLr67YwfNmmzE8i2DTGcEjNqV4QK0ma5ZGlTjmfH7 BVBwGHreUUjbZYzjAo3CRyqrpl3GTJEL2+OZZD4IGbsnQi2MurlvcmhtQuh5YxA7pM0A qItH6Qt6vY2OLw92o6zJKqfIlFbbMsKMB094tHmHwMgtv1cb//ridQlwgpyhEyP9aocz QvQm0Kx8Aw48IiAioCRQPqBigusWnA4+EGergXs0ixsrbM4kidfbCQD2ZTI76jePWyzJ FzpsTFTvkwwVWIUsaeP0qa8X1mxQngdAtJkmqF0R8qA9uHAGJ97TLENuwTSqIJZdorV+ FW8w== X-Gm-Message-State: AMke39lWuVbl1v4eXVSWiI/HU9EL0CNeCiVaxCSGPuqPSu4v4kquO0obbJBGv9MsVoJdPw== X-Received: by 10.99.149.66 with SMTP id t2mr24957633pgn.152.1488857740538; Mon, 06 Mar 2017 19:35:40 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id c195sm42119971pfb.60.2017.03.06.19.35.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 19:35:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 From: Fred Baker In-Reply-To: Date: Mon, 6 Mar 2017 19:35:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:35:42 -0000 On Mar 6, 2017, at 7:18 PM, Lorenzo Colitti wrote: > I can't help fill in the [...] because I personally don't see what you = can do with a /113 that you can't do with a /64 (other than conserve = addresses, which has always been a non-goal), but there seem to be = several participants who do see a problem. What I'm saying is that if we = want to change the standard, the people who see a problem with it should = articulate that problem in a way that it's possible to find a solution = using informed and documented engineering trade-offs rather than = opinions. As you know, I'm not in favor of a standard IID or prefix length. If a = given algorithm, SLAAC, requires it, so be it where it is in use (not = that this this is a statement of probability, it's a statement of = network addressing policy). Of a network chooses to do something = different in the absence of that limitation, I understand the Internet = Architecture to give it that latitude and the authority to impose an = address allocation mechanism and policy. That said, ... The argument I have heard for serial lines is that, with high = probability, if there are more than 2^1 addresses on a link, selecting a = random address for one's peer has a high confidence of selecting an = address the peer isn't using, resulting in an ICMP error instead of a = response. That, assuming I understand it, is the fundamental argument = behind /127. Reduced to simpler terms - if the environment makes = assumptions, the addressing should make the same assumptions.=20 RFCs in context: https://tools.ietf.org/html/rfc3627 3627 Use of /127 Prefix Length Between Routers Considered Harmful. P. Savola. September 2003. (Format: TXT=3D12436 bytes) (Obsoleted by RFC6547) (Status: HISTORIC) (DOI: 10.17487/RFC3627) https://tools.ietf.org/html/rfc6164 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links. M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. April 2011. (Format: TXT=3D16057 bytes) (Updated by RFC6547) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6164) https://tools.ietf.org/html/rfc6547 6547 RFC 3627 to Historic Status. W. George. February 2012. (Format: TXT=3D4917 bytes) (Obsoletes RFC3627) (Updates RFC6164) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6547) From nobody Mon Mar 6 19:47:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E74128BA2 for ; Mon, 6 Mar 2017 19:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 30xY5TTNvyWX for ; Mon, 6 Mar 2017 19:47:36 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4A612706D for ; Mon, 6 Mar 2017 19:47:36 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 72so194343826uaf.3 for ; Mon, 06 Mar 2017 19:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LbS680mxhuqueT56KPrzaGLzHUTg/mOCyEOssRH/jbE=; b=N9E6wq4x0myBSV52ZV6LWU1g57UR7k4KTIHkSPcEVNx9Zu/2kWPKucRoe4+GcTxRzD Qv5iuKT9KFw/vd+itgIonS3p7C7zEmHVAspFrm6cKW+P9hOkMrEERGRz5s1NleTREQOD SpEdkdTS5Oy71dDU6QKwgSKVod08ZMjy1DoRLJzL854ULSToPCTle1zBLf8S+lxk8nUK Z0Mz2MiGTM6yhaykY/Y/0hbjhLOh+HkANIX9arIyNbU+o7oFnjKMATfG0Z393knj6h4w hYzzUqE//j9E7aMmwZLiZENTVu2pLXAKOr9wWVX4vtgo9VviIwohnKQwR+KmdF09R0on IXNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LbS680mxhuqueT56KPrzaGLzHUTg/mOCyEOssRH/jbE=; b=bDZ+YyjS00tFXbNNAH20ZUOvGDH0iP2kCCHF9ji1GDEZvZdMYbLMylJumyOHeODejh oi78l1IoUdHsAxoliVQljdTRZoVD5dHbJz65dUk1IjJCGHHZ8DX9TNy994CaSaQV/OR9 fGJ4b2hQ0tO4UGaqQEke9AbA+3ANmNBCCg1yNv7fGR6vo7/6st0hWkil/ZlK6w7qR/HK 0jrm9+1sVy4gSWI3oISHi1Lrc+NVe6XuncrLPzlwwlU7jo3Awkz1pzInb0XDJ2KUT26S z0+iKe2IHarn5rgIhT2myLWVHKG9nlWpKNk1j/KDV3Vq8//gMkYQv/fPq48EeVD4p6ll S6GA== X-Gm-Message-State: AMke39nYa+xIn/5SEfHaBzntAcdhzdWDWBWaTHEGPo8wmmPxVFbvUXvon4N4fbVp6/sEH3Ya/GIOJj4OohkcU79o X-Received: by 10.159.40.202 with SMTP id d68mr9298362uad.122.1488858455244; Mon, 06 Mar 2017 19:47:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 6 Mar 2017 19:47:14 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 7 Mar 2017 12:47:14 +0900 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: Fred Baker Content-Type: multipart/alternative; boundary=94eb2c12382e58f2ab054a1bdf95 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:47:37 -0000 --94eb2c12382e58f2ab054a1bdf95 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 7, 2017 at 12:35 PM, Fred Baker wrote: > Of a network chooses to do something different in the absence of that > limitation, I understand the Internet Architecture to give it that latitude > and the authority to impose an address allocation mechanism and policy. > The architecture currently does not give it that latitude, because RFC4291 makes a blanket statement that ("most") IIDs are 64 bits long. > The argument I have heard for serial lines is that, with high probability, > if there are more than 2^1 addresses on a link, selecting a random address > for one's peer has a high confidence of selecting an address the peer isn't > using, resulting in an ICMP error instead of a response. I'm not sure I understand this problem statement. Are you saying that for a link that only has two peers on it, it is convenient to use a subnet that is /127, because you don't have to know the peer address? That's true, but it only applies to /127 and not any other prefix size, right? > That, assuming I understand it, is the fundamental argument behind /127. > Reduced to simpler terms - if the environment makes assumptions, the > addressing should make the same assumptions. > Isn't that still a philosophical argument that applies to the current solution, though? --94eb2c12382e58f2ab054a1bdf95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= ue, Mar 7, 2017 at 12:35 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
    Of a network chooses= to do something different in the absence of that limitation, I understand = the Internet Architecture to give it that latitude and the authority to imp= ose an address allocation mechanism and policy.

    The architecture currently does not give it that latitude, because= RFC4291 makes a blanket statement that ("most") IIDs are 64 bits= long.
    =C2=A0
    The argument I = have heard for serial lines is that, with high probability, if there are mo= re than 2^1 addresses on a link, selecting a random address for one's p= eer has a high confidence of selecting an address the peer isn't using,= resulting in an ICMP error instead of a response.

    I'm not sure I understand this problem statement. Are you sayin= g that for a link that only has two peers on it, it is convenient to use a = subnet that is /127, because you don't have to know the peer address? T= hat's true, but it only applies to /127 and not any other prefix size, = right?
    =C2=A0
    That, assuming= I understand it, is the fundamental argument behind /127. Reduced to simpl= er terms - if the environment makes assumptions, the addressing should make= the same assumptions.

    Isn't that s= till a philosophical argument that applies to the current solution, though?=
    --94eb2c12382e58f2ab054a1bdf95-- From nobody Mon Mar 6 19:52:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BD0129ADD; Mon, 6 Mar 2017 19:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 w-vLfF71xDNU; Mon, 6 Mar 2017 19:52:18 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F43129ADB; Mon, 6 Mar 2017 19:52:18 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.16.251; From: "Susan Hares" To: "'Bob Hinden'" References: <148864769030.23464.9110014115039938058.idtracker@ietfa.amsl.com> In-Reply-To: Subject: RE: Review of draft-ietf-6man-rfc1981bis-04 Date: Mon, 6 Mar 2017 22:47:19 -0500 Message-ID: <00fb01d296f5$85c57570$91506050$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEbJyWFeA8M+EN5czpk+ggCsNrULQJJzOZWouVKWPA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ops-dir@ietf.org, 'IPv6 List' , 'IETF' , draft-ietf-6man-rfc1981bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:52:19 -0000 Bob:=20 Thank you for your response. I'm pulling up the remaining questions = to the top here. All my questions were about corner cases and "what = ifs" - which is just the result of being a reviewer of a = long-implemented specification.=20 1) I thought the IPv6 LAN was targeted for new mobile networks or sensor = networks. If so, it may be in the future that the wireless connections = would want to change the MTU on a network to increase the ability to = change the MTU. If you're answer is, we'll make the timer adjustment = when these technology use it in this way, this is a fine answer.=20 2) On, your comment:=20 > I believe what will happen is that the host will use the new MTU in = any new connections it establishes. Existing connections will continue = with preview MTU.=20 Did I miss this in the draft? Just to sharpen my knowledge of this = draft. =20 3) The question #4 - I was trying to determine what the interaction = between the SEND with an MTU size option, and this update to RFC1918. = It appears in the specification these two functions are interacting. = Is this my imagination? If not, just for my own information - where do = I find this in the specification. =20 Thanks,=20 Sue=20 -----Original Message----- From: Bob Hinden [mailto:bob.hinden@gmail.com]=20 Sent: Monday, March 6, 2017 8:39 PM To: Susan Hares Cc: Bob Hinden; ops-dir@ietf.org; IPv6 List; IETF; = draft-ietf-6man-rfc1981bis.all@ietf.org Subject: Re: Review of draft-ietf-6man-rfc1981bis-04 Hi Sue, Thanks for the review, comments below. Bob > Reviewer: Susan Hares > Review result: Has Issues >=20 > ack, Steve,Jeffrey, and Bob: >=20 > Thank you for taking on this important revision to the document. I=20 > hope my comments help to improve the document so this important change = > can ge deployed. Thanks >=20 > I have reviewed this as part of the routing directorate review. This=20 > review should be treated as any IETF LC comments. >=20 > Sue Hares >=20 > RTG-DIR Review >=20 > Status: I have three concern plus editorial nits. >=20 > #1 - Concern 1 is technical regarding the interaction with the MTU=20 > option in ND/SEND plus ditorial nits. See the comments below. I am=20 > not an ND/SEND Expert, please have an imoplementer look at the=20 > requirements. >=20 > Concern: I cannot tell how this interacts with the ND/SEND protocol in = > the following areas below. > 1) Neighbor Unreachability Detection is used for all paths between=20 > hosts > and neighboring nodes, including host-to-host, host-to-router, and > router-to-host communication. >=20 > If the source node is on the link and the destination node available > through the router, and the router is in the process of sending a > MTU option to increase the size? How does your algorithm work? I believe what will happen is that the host will use the new MTU in any = new connections it establishes. Existing connections will continue = with preview MTU. I also note, that this would be a very rare event as most LANs do not = dynamically change their MTU. >=20 > Are the packetization layer notified? > Is the original value a stale notification over time? > You indicate it MUST NOT be done in less than 5 minutes, and that > 10 minutes is the norm. >=20 > Is 10 minutes really the best response time for this particular=20 > case? > Or did I miss something in your draft? See above. >=20 >=20 > 2) Assume the same situation as #1, but the > router sends an MTU option to decrease the size. >=20 > In this case, the router is sending information that > the MTU has changed, but the first indication for the > end system is based on a Packet-too-Big Message after sending. I think receiving PTB messages would be the likely result for existing = connections. The host would respond by reducing it=E2=80=99s packet = size. New connections would use the new MTU. As above, this should be a very rare occurrence. >=20 >=20 > 3) For a multicast packet (3000 bytes), assume that the multicast path = > reaches two different routers (router-a and router-b). Assume the=20 > on-link MTU is 3500 bytes, but the previous router-A and router-B MTU=20 > is 2500 bytes. >=20 > Router-a responds to the packet with 10ms sending a MTU option that=20 > changes the MTU to support this packet. Router-B sends a redirect for=20 > multicast address to Router-A after 30 ms. >=20 > What happens to your path calculation? > Is this again, the 5 minutes (minimum) and 10 minute normal to reset=20 > this value. The host would use the lowest MTU it received and act accordingly. This = is described in the fifth paragraph of Section 3. >=20 > 4) What happens if the ND process is instantiated by SEND protocol,=20 > and the host does not contain the appropriate certification=20 > information to timely updates? >=20 > Again, the host guessing at the appropriate value? I don=E2=80=99t follow this? Please explain. This seems more about a = question about SEND, and not rfc1981bis. >=20 >=20 > #2 - Concern 2 - How does SEND's implementation of MTU option. > mitigate or have no effect on this MTU. Is there a recommendation=20 > that should be made in section 6. Again, please ask a SEND expert for = > review. It works the same. SEND secures ND, it still uses ND. The SEND RFC = doesn=E2=80=99t even reference RFC1981. >=20 > #3 - Concern 3 - content of document >=20 > This document has two parts: protocol requirements and implementation=20 > requirements. > 8 paragraphs (1 page) indicates the IPv6 specification and 6 pages=20 > gives the implementation? >=20 > Why did this get split in to 2 documents? Even if this was a bis,=20 > document would it not be better to provide minimal specification for=20 > the protocol change and a larger document with implementation=20 > information. >=20 > I'm fine with the WG/ADs deciding, this is the way the document has to = > go forward -- but the question should be asked. The working groups intent in doing this bis document was to make a few = changes to fix a problem related to a change in RFC2460bis, remove = mention of RH0 because it was deprecated earlier, and a few other small = changes. It was not to do a major rewrite of the document (or as you = suggest, split it into two documents). The alternative was just to file = an errata on RFC1981. This document is very widely implemented. I don=E2=80=99t think = splitting the document into two would improve anything, and very likely = create confusion for the current implementations. >=20 > Editorial nits: > #1 nit - section 5.2 page 8, paragraph beginning >=20 > Old /Note: if the / > New/Note: If the/ >=20 > #2 nit - section 5.2 page 9 paragraph begin >=20 > Old /Note: even if/ > New /Note: Even if/ >=20 > #3 nit - section 5.3 page 10 paragraph beginning >=20 > Old /Note: an implementation/ > New/Note: An implementation/ >=20 >=20 Noted. Thanks. From nobody Mon Mar 6 20:56:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1352129AFB for ; Mon, 6 Mar 2017 20:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 rN35DMAfxfZd for ; Mon, 6 Mar 2017 20:56:22 -0800 (PST) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03DA12941D for ; Mon, 6 Mar 2017 20:56:22 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 13F8E646 for ; Tue, 7 Mar 2017 04:56:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGkG8jQ5w4-3 for ; Mon, 6 Mar 2017 22:56:21 -0600 (CST) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id CCF46283 for ; Mon, 6 Mar 2017 22:56:21 -0600 (CST) Received: by mail-ua0-f198.google.com with SMTP id f54so119574821uaa.5 for ; Mon, 06 Mar 2017 20:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=egZ6oH2APU9EwN8b9h3pgLy8BpZJIsQL3DS+RUqNZ7M=; b=ASUaa5NwIHJW5JXjIUZLyfzCRFMtPid/12lIHPOUJPEc4VdNEKSl6vDyR6VDREKRLF ZHgABKUeQf2UgtKjvq1HW+fTRiAphp6aAVWUSqoYc5yg1b8lIW48EaLqNU6JTF20gtMn AI8UXzOPp99Krel82JzNhk+eT3zg8IyB7PLWT8vEDn0xRHGfNYoG2fNdXhZa9gYkZ/nZ RzvrA0oDfj8EOpNX8IjQHAO67FQscPJcnBHcc2d9BDRgp5oLXQqCBRji9qnkVFGeqSIi EmRIVnj0xcQov6m+nlwVz38y5KfwqA5786qcKpVUroIjNnZH1oK2qBhg07IptkOtzNMQ heOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=egZ6oH2APU9EwN8b9h3pgLy8BpZJIsQL3DS+RUqNZ7M=; b=eQZTvF59AQwojKohUYrQzfqcwFrSAV93UOKhHbUFl46+nH/XfX3F/kBsBUm9nc/+XM PSOPf+PQKNBW5DLt2+6ioUv3FGVuOKp2AjZZM+AHlxezcQM/zEhR8uknsQLcuYlIyQf1 aV9rYtzilxceR6UHGou+vPUFp559HzNvAP95+1EhZfOrXCGqtakFHLTMumoMNIgISXch cNqhBvZ2DJjb+wAqEP3O6AOXfzyUuQayYCQh7HiByE4PuYoarSM5jAYIXrOIPNU3Zlbc zBskzkwqG8s5wd6ISuziIOqt3bZ8dTSSMSn3mqvUkAirQ932GPuK6XczqbxK605ltsj9 Yl+g== X-Gm-Message-State: AMke39kiEmXqYb6WInnsM8c0Vo3wVO1yXAjlCGMQWik2UpEJOiLmXYkwoUH0rOjNt/arVP8bmCLfqwWc/Jtq3Do0R0awItQIWRrTeOxFuisXyhXD2KT2cFGSldy9jbYNuLOUQHH6Er04dxcG4zo= X-Received: by 10.31.252.77 with SMTP id a74mr8513343vki.46.1488862581258; Mon, 06 Mar 2017 20:56:21 -0800 (PST) X-Received: by 10.31.252.77 with SMTP id a74mr8513336vki.46.1488862581015; Mon, 06 Mar 2017 20:56:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.134.129 with HTTP; Mon, 6 Mar 2017 20:56:20 -0800 (PST) In-Reply-To: References: From: David Farmer Date: Mon, 6 Mar 2017 22:56:20 -0600 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=94eb2c149b2842db95054a1cd502 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 04:56:24 -0000 --94eb2c149b2842db95054a1cd502 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 6, 2017 at 9:18 PM, Lorenzo Colitti wrote: > On Tue, Mar 7, 2017 at 4:05 AM, David Farmer wrote: >> >> Instead, I would suggest another approach: see what the problems with >>> 4291 are, *write them down*, and only then write a document explaining what >>> should be changed and why. >>> >> >> The list of 7 points are the problems that many see with 4291bis, maybe >> overly summarized, but they are there. >> > > Well, but what you provided is an alternative solution, not a problem > statement. Example of a problem statement would be, "RFC 4291 does not > allow non-64-bit IID lengths. However, assigning smaller prefix lengths is > necessary because [...]". > To be clear no where in the text I provided does it say that an IID other than 64 is allow. It say 128 bit quantities from manual configuration and DHCPv6 can be associated with with subnet prefixes of any length. That is a fine distinction, but no finer that you claiming that requiring that 64-bit IIDs, and you implying 64-bit subnet prefixes too, doesn't make IPv6 classful. Are you saying that every implementation of IPv6 that allows manual config of subnet prefixes other that /64 have it wrong? Furthermore, if subnet prefixes other than /64 aren't allowed then how do we have RFC6164 I contend that the whole concept of an IID is optional, please note that RFC4291 and it's predecessor say: "At a minimum, a node may consider that unicast addresses (including its own) have no internal structure", So I contend that RFC4291 merely says that if you use an IID it must be 64 bits. It doesn't directly say that 128bit IPv6 addresses can't be associated with subnet prefixes other than /64. In fact it also says, "IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing." Which to me implies that subnets other than /64 have to be valid. Furthermore, RAs are allowed to be any length, especially if they don't set the "A" flag, why is this if not to allow subnet prefixes of any length? > I can't help fill in the [...] because I personally don't see what you can > do with a /113 that you can't do with a /64 (other than conserve addresses, > which has always been a non-goal), but there seem to be several > participants who do see a problem. What I'm saying is that if we want to > change the standard, the people who see a problem with it should articulate > that problem in a way that it's possible to find a solution using informed > and documented engineering trade-offs rather than opinions. > Just because you can't see it doesn't mean that other can't and don't have valid uses. I'm not convince it's actually making any change, SLAAC still has 64-bit IIDs. It is only making explicit that, manual config and DHCPv6 address can be associated with subnets of any length, and it's clear that at least some implementors think it says that already, and I think your in the minority of people that think's it doesn't. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --94eb2c149b2842db95054a1cd502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Mon, Mar 6, 2017 at 9:18 PM, Lorenzo Colitti <<= a href=3D"mailto:lorenzo@google.com" target=3D"_blank">lorenzo@google.com> wrote:
    <= div dir=3D"ltr">
    On Tu= e, Mar 7, 2017 at 4:05 AM, David Farmer <farmer@umn.edu> wrote:= =C2=A0
    Instead, I would suggest another approach: se= e what the problems with 4291 are, *write them down*, and only then write a= document explaining what should be changed and why.

    The list of 7 points are the problems th= at many see with 4291bis, maybe overly summarized, but they are there.

    Well, but what you prov= ided is an alternative solution, not a problem statement. Example of a prob= lem statement would be, "RFC 4291 does not allow non-64-bit IID length= s. However, assigning smaller prefix lengths is necessary because [...]&quo= t;.

    To be clear no = where in the text I provided does it say that an IID other than 64 is allow= .=C2=A0 It say 128 bit quantities from manual configuration and DHCPv6 can = be associated with with subnet prefixes of any length.=C2=A0 That is a fine= distinction, but no finer that you claiming that requiring that 64-bit IID= s, and you implying 64-bit subnet prefixes too, doesn't make IPv6 class= ful. Are you saying that every implementation of IPv6 that allows manual co= nfig of subnet prefixes other that /64 have it wrong?=C2=A0 Furthermore, if= subnet prefixes other than /64 aren't allowed then how do we have RFC6= 164=C2=A0

    I contend that the whole concept of an I= ID is optional, please note that RFC4291 and it's predecessor say: &quo= t;At a minimum, a node may consider that unicast addresses (including its o= wn) have no internal structure", So I contend that RFC4291 merely says= that if you use an IID it must be 64 bits. It doesn't directly say tha= t 128bit IPv6 addresses can't be associated with subnet prefixes other = than /64.=C2=A0=C2=A0In fact it also says, "IPv6 unicast addresses are= aggregatable with prefixes of arbitrary=C2=A0bit-length, similar to IPv4 a= ddresses under Classless Inter-Domain Routing." =C2=A0Which to me impl= ies that subnets other than /64 have to be valid.=C2=A0 Furthermore, RAs ar= e allowed to be any length, especially if they don't set the "A&qu= ot; flag, why is this if not to allow subnet prefixes of any length? =C2=A0=
    =C2=A0
    I= can't help fill in the [...] because I personally don't see what y= ou can do with a /113 that you can't do with a /64 (other than conserve= addresses, which has always been a non-goal), but there seem to be several= participants who do see a problem. What I'm saying is that if we want = to change the standard, the people who see a problem with it should articul= ate that problem in a way that it's possible to find a solution using i= nformed and documented engineering trade-offs rather than opinions.

    Just because you ca= n't see it doesn't mean that other can't and don't have val= id uses.=C2=A0 I'm not convince it's actually making any change, SL= AAC still has 64-bit IIDs.=C2=A0 It is only making explicit that, manual co= nfig and DHCPv6 address can be associated with subnets of any length, and i= t's clear that at least some implementors think it says that already, a= nd I think your in the minority of people that think's it doesn't.<= /div>

    Thanks= .

    --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <= a href=3D"mailto:Email%3Afarmer@umn.edu" target=3D"_blank">Email:farmer@umn= .edu
    Networking & Telecommunication Services
    Office of Inform= ation Technology
    University of Minnesota=C2=A0=C2=A0
    2218 University= Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minneapolis, M= N 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --94eb2c149b2842db95054a1cd502-- From nobody Mon Mar 6 22:04:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355481293FF for ; Mon, 6 Mar 2017 22:04:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 mfT8U0rZa7UE for ; Mon, 6 Mar 2017 22:04:18 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5732A1293DA for ; Mon, 6 Mar 2017 22:04:18 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id u30so63714319uau.0 for ; Mon, 06 Mar 2017 22:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tm4crb701aYPfuYIDGOfBT6piobo23XGCymFfRYdDgw=; b=Ir14BVcNzLAuCsJxjVZlr9yE7OMDC23YZ6/qubV1RrsK8Yq4ZmTdJdiPXJc8nMlBQS 3crRpBOHm7rksskYamJeSGR/7hQClGrn3gBNE63ZTPV86kiW9g4mAJVmaQ3sy1F/eKZb RmlauPJp+VbnlhLKHzn06xjTpr+RMx6PCJI+u8WSAA/NQBb4P+mkW+A0T0zo7wznDMiR EzTaYt4DKZ4HH177p9NaXJ5QbTht8F2H7Q48ViBUEOc6x6oc7Oc+GwF01h2++yEbJyMO S3x5DEKolg0732bPnsNqdIPvNq8j/pLdLJWvpkdcOcvHH6TdNku2s8muYHceTwpxQFsF Am/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tm4crb701aYPfuYIDGOfBT6piobo23XGCymFfRYdDgw=; b=Nz95OcnswfpjRa/aQO6l9+XWCbvm5paMT5gi2RmY+tox6QyDlsRKQximtjS8G0uBea KXYktbhUviBHB24+UUbLYcYCX64Z8INpdcLlSZgLmUpnpSesKm0uG7mixs23cyEmQRak ItZVcPO09iOXC9LV86cL0Bq9ucs0A+xYQjA6c0dyAo1EcvKxlJjk9Sw5Pfix2A46oZZY Jc5F57w5RThbX5M32cmxMnlVJcUAT36lEWObDauywI52fyUX3cJu/2PkFJIHxLEkmfDY o+BgUZjck1P+27Ls+g5gS3BQILbBIrjuB+JtNoIc6+vZKQPdpfabZoaeKP4rBq+QBdYf XNpQ== X-Gm-Message-State: AMke39ku3GQ1k2RS2C3sZBrXymWQ4bRA6wxBnw3Cnu0IqTDhHSk4SHzAEs2M4xn9EQRFwsguU14GUeAfPos03fpW X-Received: by 10.31.192.204 with SMTP id q195mr8318828vkf.155.1488866657169; Mon, 06 Mar 2017 22:04:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 6 Mar 2017 22:03:56 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 7 Mar 2017 15:03:56 +0900 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: David Farmer Content-Type: multipart/alternative; boundary=001a114388cc385360054a1dc896 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 06:04:20 -0000 --001a114388cc385360054a1dc896 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 7, 2017 at 1:56 PM, David Farmer wrote: > To be clear no where in the text I provided does it say that an IID other > than 64 is allow. It say 128 bit quantities from manual configuration and > DHCPv6 can be associated with with subnet prefixes of any length. That is > a fine distinction, but no finer that you claiming that requiring that > 64-bit IIDs, and you implying 64-bit subnet prefixes too, doesn't make IPv6 > classful. Are you saying that every implementation of IPv6 that allows > manual config of subnet prefixes other that /64 have it wrong? > Furthermore, if subnet prefixes other than /64 aren't allowed then how do > we have RFC6164 > > I contend that the whole concept of an IID is optional, please note that > RFC4291 and it's predecessor say: "At a minimum, a node may consider that > unicast addresses (including its own) have no internal structure", So I > contend that RFC4291 merely says that if you use an IID it must be 64 bits. > It doesn't directly say that 128bit IPv6 addresses can't be associated with > subnet prefixes other than /64. In fact it also says, "IPv6 unicast > addresses are aggregatable with prefixes of arbitrary bit-length, similar > to IPv4 addresses under Classless Inter-Domain Routing." Which to me > implies that subnets other than /64 have to be valid. Furthermore, RAs are > allowed to be any length, especially if they don't set the "A" flag, why is > this if not to allow subnet prefixes of any length? > Sure. Now let's write all that down in a document so that these subtle (and likely controversial) issues can be fully explained and debated. Because: 1. If these issues are subtle even for us, how can we hope that non-IETF participants (or even just non-WG participants) will understand them? 2. If we don't write them down and just make a change to RFC 4291, how can we know that any decision we make is properly justified. 3. If we don't write them down and just make a change to RFC 4291, how will future IETF participants and network administrators and host implementers know how to interpret the text we write? I don't think asking them to make sense of the 6man archives is reasonable. I can't help fill in the [...] because I personally don't see what you can >> do with a /113 that you can't do with a /64 (other than conserve addresses, >> which has always been a non-goal), but there seem to be several >> participants who do see a problem. What I'm saying is that if we want to >> change the standard, the people who see a problem with it should articulate >> that problem in a way that it's possible to find a solution using informed >> and documented engineering trade-offs rather than opinions. >> > > Just because you can't see it doesn't mean that other can't and don't have > valid uses. > Absolutely agreed. Let's write those uses down, and use them to inform our decision as to how (and whether) we should change the standard. --001a114388cc385360054a1dc896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= ue, Mar 7, 2017 at 1:56 PM, David Farmer <farmer@umn.edu> wrote= :
    To be clear no wher= e in the text I provided does it say that an IID other than 64 is allow.=C2= =A0 It say 128 bit quantities from manual configuration and DHCPv6 can be a= ssociated with with subnet prefixes of any length.=C2=A0 That is a fine dis= tinction, but no finer that you claiming that requiring that 64-bit IIDs, a= nd you implying 64-bit subnet prefixes too, doesn't make IPv6 classful.= Are you saying that every implementation of IPv6 that allows manual config= of subnet prefixes other that /64 have it wrong?=C2=A0 Furthermore, if sub= net prefixes other than /64 aren't allowed then how do we have RFC6164= =C2=A0

    I contend that the whole concept of an IID = is optional, please note that RFC4291 and it's predecessor say: "A= t a minimum, a node may consider that unicast addresses (including its own)= have no internal structure", So I contend that RFC4291 merely says th= at if you use an IID it must be 64 bits. It doesn't directly say that 1= 28bit IPv6 addresses can't be associated with subnet prefixes other tha= n /64.=C2=A0=C2=A0In fact it also says, "IPv6 unicast addresses are ag= gregatable with prefixes of arbitrary=C2=A0bit-length, similar to IPv4 addr= esses under Classless Inter-Domain Routing." =C2=A0Which to me implies= that subnets other than /64 have to be valid.=C2=A0 Furthermore, RAs are a= llowed to be any length, especially if they don't set the "A"= flag, why is this if not to allow subnet prefixes of any length? =C2=A0

    Sure. Now let's w= rite all that down in a document so that these subtle (and likely controver= sial) issues can be fully explained and debated. Because:
      If these issues are subtle even for us, how can we hope that non-IETF part= icipants (or even just non-WG participants) will understand them?
    1. I= f we don't write them down and just make a change to RFC 4291, how can = we know that any decision we make is properly justified.
    2. If we don&= #39;t write them down and just make a change to RFC 4291, how will future I= ETF participants and network administrators and host implementers know how = to interpret the text we write? I don't think asking them to make sense= of the 6man archives is reasonable.

    I can't help fill in the [..= .] because I personally don't see what you can do with a /113 that you = can't do with a /64 (other than conserve addresses, which has always be= en a non-goal), but there seem to be several participants who do see a prob= lem. What I'm saying is that if we want to change the standard, the peo= ple who see a problem with it should articulate that problem in a way that = it's possible to find a solution using informed and documented engineer= ing trade-offs rather than opinions.

    Just because= you can't see it doesn't mean that other can't and don't h= ave valid uses.

    Absolutely agre= ed. Let's write those uses down, and use them to inform our decision as= to how (and whether) we should change the standard.
    --001a114388cc385360054a1dc896-- From nobody Mon Mar 6 22:15:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA497129408 for ; Mon, 6 Mar 2017 22:15: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 9YCYvpMhMzfm for ; Mon, 6 Mar 2017 22:15:31 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683D7127076 for ; Mon, 6 Mar 2017 22:15:31 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id f54so194963512uaa.1 for ; Mon, 06 Mar 2017 22:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hMt+zSgz3GxmBhNGCrq482Rv1TsKn645G1Ka+dciIFg=; b=kYKF4sJ1qY/KqtS0AXH2m7Ob8A78aqcGia39h5SEtPwuv7JuvpSM0isUIF1En9cwcV gsjcSvMpHjUpcc/o8QfRqoYLddPTTp5QPeysoWwHRhTV1kwskK2vWAvT10yCdYiOiZqF 30eBsAiBLENUtS3pcjVBtPJgM/AELYJHefGgg8AuvHm6Mp0bUK0PuLo8Y7F+cO2te5Yw IhDPYhbvU4PW1uZ0ZO8YhlkCy963MhpvbK6MNC0jQhaPpf8Zt5nJLoT1evavrF8h69UF HyDIsi81sGmrMGNFZeLyFqKMXpvalD+ShjrnjLwcgKemUG71R+eiEdI8I9maYmOiLUeN Eh6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hMt+zSgz3GxmBhNGCrq482Rv1TsKn645G1Ka+dciIFg=; b=jutkoJX3PkvY77bBPZsahnQDF/+qUK9vm8dvsLn+XBSKD0MMBrY1AH2wTy4mpsP/xU O+70e/slmBhU05LarccAMFIxnkXg32vgYM8v4bYbNabfLB7Jowu+rvP5DOTaNHPezaAb lNrQu3j6GaVtKDacmFFRJfpedrtSzlXwPwK9dMvJijwqGfFyNskW0NYSox5ZPICPAyy3 PIfTY35dr6wZhWLnoqJG7HnpPI+UtRY2LJVN1nlSqQnTOACH8JKEswpanCc+1YCvbgx8 YNYClL+Stsy60dFmcnN1XecdOf2ITeFBJ0FTnQgf4RxJP4yG6fwB9kF8ghy4KmSpFtF6 4oHA== X-Gm-Message-State: AMke39kg6rYl2ih2yrm86UMklyKe/KA3zrav0vVcoBZVB8AhSQzDFXVwFFOHzoq7NgJ4U4KFXXsnQb/mwqvO5+QO X-Received: by 10.31.11.73 with SMTP id 70mr6454568vkl.83.1488867330304; Mon, 06 Mar 2017 22:15:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 6 Mar 2017 22:15:09 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 7 Mar 2017 15:15:09 +0900 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: David Farmer Content-Type: multipart/alternative; boundary=001a11437e88578e37054a1df093 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 06:15:33 -0000 --001a11437e88578e37054a1df093 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 7, 2017 at 1:56 PM, David Farmer wrote: > It is only making explicit that, manual config and DHCPv6 address can be > associated with subnets of any length, and it's clear that at least some > implementors think it says that already, and I think your in the minority > of people that think's it doesn't. > If you're talking about the current state of the standards, It doesn't matter whether I am in the minority or not because the standard is pretty clear about how things work. The current state is that (for unicast addresses not starting with 0b000): - IIDs are 64 bits in length, because of RFC 4291 =C2=A72.5.1 - Subnet Prefixes are 64 bits in length, because of RFC 4291 =C2=A72.5.0 and 128-64 =3D 64 - IIDs are required to be unique in a subnet prefix, because of RFC 4291 =C2=A72.5.1 - On-link determination is separate from the Subnet Prefix, because of RFC 5942 (partly motivated by RFC 4903 =C2=A74.2, which the current disc= ussion seems to completely ignore) - On-link determination is determined by PIOs with L=3D1, because of RFC 5942. - When L=3D1 is not specified the on-link prefix length of any given address is undefined, and the IAB recommends that implementations treat = the prefix length as undefined, or treat it as /128. So, if by "subnet" you mean Subnet Prefix as defined in RFC 4291, then it's clear that the subnet is 64 bits long. If by "subnet" you mean "on-link prefix", then a DHCPv6-assigned address is not associated with *any* on-link prefix length, because on-link prefix lengths are configured completely separately. Manual configuration is not specified in the standards so it's not clearly defined anywhere what the /64 in "2001:db8::1/64" means. We may have opinions, and observe the behaviour of implementations, but those remain opinions and observations. --001a11437e88578e37054a1df093 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= ue, Mar 7, 2017 at 1:56 PM, David Farmer <farmer@umn.edu> wrote= :
    It is only making explicit that, manual config and = DHCPv6 address can be associated with subnets of any length, and it's c= lear that at least some implementors think it says that already, and I thin= k your in the minority of people that think's it doesn't.

    If you're talking about the current = state of the standards, It doesn't matter whether I am in the minority = or not because the standard is pretty clear about how things work. The curr= ent state is that (for unicast addresses not starting with 0b000):
    • IIDs are 64 bits in length, because of RFC 4291 =C2=A72.5.1
      • <= li>Subnet Prefixes=C2=A0are 64 bits in length, because of RFC 4291 =C2=A72.= 5.0 and=C2=A0128-64 =3D 64
    • IIDs are required to be unique in a subn= et prefix, because of RFC 4291=C2=A0=C2=A72.5.1
    • On-link determinati= on is separate from the Subnet Prefix, because of RFC 5942 (partly motivate= d by RFC 4903 =C2=A74.2, which the current discussion seems to completely i= gnore)
    • On-link determination is determined by PIOs with L=3D1, beca= use of RFC 5942.
    • When L=3D1 is not specified the on-link prefix len= gth of any given address is undefined, and the IAB recommends that implemen= tations treat the prefix length as undefined, or treat it as /128.
      • So, if by "subnet" you mean Subnet Prefix as defined in RFC= 4291, then it's clear that the subnet is 64 bits long. If by "sub= net" you mean "on-link prefix", then a DHCPv6-assigned addre= ss is not associated with *any* on-link prefix length, because on-link pref= ix lengths are configured completely separately.

    =
    Manual configuration is not specified in the standards so it's not= clearly defined anywhere what the /64 in "2001:db8::1/64" means.= We may have opinions, and observe the behaviour of implementations, but th= ose remain opinions and observations.=C2=A0
    --001a11437e88578e37054a1df093-- From nobody Tue Mar 7 02:44:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2539129595 for ; Tue, 7 Mar 2017 02:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 2bLFCbso5D_7 for ; Tue, 7 Mar 2017 02:44:05 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EB112946E for ; Tue, 7 Mar 2017 02:44:05 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v27Ai35f010555 for ; Tue, 7 Mar 2017 11:44:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E85A6206327 for ; Tue, 7 Mar 2017 11:44:02 +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 DF33920539F for ; Tue, 7 Mar 2017 11:44:02 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27Ai2U0013061 for ; Tue, 7 Mar 2017 11:44:02 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" To: ipv6@ietf.org References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> From: Alexandre Petrescu Message-ID: <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.com> Date: Tue, 7 Mar 2017 11:44:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 10:44:07 -0000 Le 07/03/2017 à 02:11, 神明é”哉 a écrit : [...] > But this thread and another similar discussion seem to suggest that > it's still not clear enough for some people. At least two different > readers interpret this text: > >> If the sum of the prefix length and interface identifier length >> does not equal 128 bits, the Prefix Information option MUST be >> ignored. Let me say that there are some interpretations of that sum from people struggling to make it work. These interpretations may be surprising to the specifier. The specifier is tempted to think that that "sum" equation is a good way to tell everything in just one phrase. But some people face the problem of making that sum be 128 even though the plen is less than 64 and the IID is 64. It is the case with the fe80:://10 needing to become a fe80::/64, and it is also the case when PIO in RA has a P1::/63. For this latter case, one wonders: am I allowed to form an address when all I have is a P1::/63, and an IIDlen 64? Can I make a P2::/64 by padding with 0s? The specs dont answer these questions. The specs think that the "sum" equation is enough. Further, because of that, some people think P1::/63 is forbidden from being advertised on Ethernet. Others think fe80:://10 is the same as fe80::/64. > as the PIO MUST be ignored for all purposes including on-link > determination. In a sense, it's not necessarily surprising - no > matter how we try to clarify a point there's always a reader that > still interprets it differently. I agree with you. And the more IPv6 gets deployed, the more readers there are. > But if there is really a protocol conformance test that doesn't > interpret the text differently it's really surprising to me. > > The bottom line is, if there is an implementation that ignores a PIO > - with both L and A flag on, and - with prefix length being > something other than 64 - received on a link whose IID is specified > to be 64 (like Ethernet) even for on-link determination, then that > implementation violates RFC4861. I can also assure that the > document editor of RFC4862 didn't intend such "strictness" - on the > contrary, he actually tried to clarify that's not the intent, but it > looks like it's still not super clear. Well... Alex > > -- JINMEI, Tatuya > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Mar 7 04:15:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53B4129461 for ; Tue, 7 Mar 2017 04:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 MfNepnZ1PTdx for ; Tue, 7 Mar 2017 04:15:47 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7552B1293E9 for ; Tue, 7 Mar 2017 04:15:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 93F4D4A; Tue, 7 Mar 2017 13:15:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1488888941; bh=KP871CTet/mVZAX7ohP3qJkk84wC PQmLO9S6dowLecw=; b=VGg4f6vsr8BEXSJcZOrOLBV0O3KijbdtOdsixG1sxlO0 B6CQwDNe7/HrLbyDE/PFfQTH6A6UO067ljX/eK5rrJPjImnMWt6DXp8bv2bNpUDl cDkx+mtVLGUScvSPB2+C/HJ2XCvOVJU2xxZfLyGAfLOlVCtkQ2urdZcAnw9/nBk= 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 10026) with ESMTP id INzpbub-4FrY; Tue, 7 Mar 2017 13:15:41 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6] (unknown [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 3167F49; Tue, 7 Mar 2017 13:15:41 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_D655C36C-22F8-447F-BF6F-BED5C801DA5E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.com> Date: Tue, 7 Mar 2017 13:15:40 +0100 Message-Id: <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.c om> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 12:15:49 -0000 --Apple-Mail=_D655C36C-22F8-447F-BF6F-BED5C801DA5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alex, > Op 7 mrt. 2017, om 11:44 heeft Alexandre Petrescu = het volgende geschreven: >=20 > Le 07/03/2017 =C3=A0 02:11, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a = =C3=A9crit : > [...] >> But this thread and another similar discussion seem to suggest that >> it's still not clear enough for some people. At least two different >> readers interpret this text: >>=20 >>> If the sum of the prefix length and interface identifier length >>> does not equal 128 bits, the Prefix Information option MUST be >>> ignored. >=20 > Let me say that there are some interpretations of that sum from people > struggling to make it work. These interpretations may be surprising = to > the specifier. >=20 > The specifier is tempted to think that that "sum" equation is a good = way > to tell everything in just one phrase. >=20 > But some people face the problem of making that sum be 128 even though > the plen is less than 64 and the IID is 64. >=20 > It is the case with the fe80:://10 needing to become a fe80::/64 Which is explicitly specified in RFC 4862 section 5.3. The /10 is used = as the basis and adapted to the IID length on the link. It explicitly = says that all bits between fe80::/10 and the IID are zero (point 2). It also says "The length of the interface identifier is defined in a = separate link-type-specific document". RFC 2464, which is that = link-type-specific document for ethernet, specifies in section 5 that on = ethernet the prefix for link-local addresses is a fe80::/64 with a = 64-bit IID. Everything is specified: the /10 to use as the basis, the = /64 being the length used on ethernet and the bits between the two = having to be zero. > , and it is also the case when PIO in RA has a P1::/63. >=20 > For this latter case, one wonders: am I allowed to form an address = when > all I have is a P1::/63, and an IIDlen 64? Can I make a P2::/64 by = padding with 0s? >=20 > The specs dont answer these questions. The specs think that the "sum" > equation is enough. It is. A "sum" is a quite clearly defined mathematical concept. As you = quoted above RFC 4862 section 5.5.3 says "If the sum of the prefix = length and interface identifier length does not equal 128 bits, the = Prefix Information option MUST be ignored." Let's test this. In your = example case: - P1::/63 has a prefix length of 63 - IIDlen (interface identifier length) is 64 - the sum of the prefix length and the interface identifier length is 63 = + 64 =3D 127 - 127 does not equal 128 - therefore the Prefix Information option MUST be ignored > Further, because of that, some people think P1::/63 is forbidden from > being advertised on Ethernet. According to RFC 4862 you can advertise it, but receivers must ignore = it. > Others think fe80:://10 is the same as fe80::/64. As you can see above the fe80::/10 prefix is used as the basis for the = link-local addresses, with the actual prefix length defined per = link-type. For ethernet that has been specified as 64-bits, so that = leads to fe80::/64 on ethernet. Please read the RFCs. All the examples you provide are quite explicitly = covered there... Cheers, Sander --Apple-Mail=_D655C36C-22F8-447F-BF6F-BED5C801DA5E 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----- iQEcBAEBCAAGBQJYvqRsAAoJEKAtA7D+JBO59nUH/1/qAvov1R+CX8nBm+kGp162 1tS3zumMYKcxoFR8kwAPnFBTvkrIWg8N6t5qLrzb/XNbHWwZpqv6gD6LCfqEfR29 ZbKsFpWI/PeO+VPt7+c3nENN8QlaC2VWU56Ooe+3eFxT5516xo1DbvtadELc5CzR RSt7J2JscnVsjwkC9L665y0kuNZYtPWqNo1hWNEslUDCbARs6oDDvlSJSv0s/reU 7tu+THVHDh9omLOlPnadZ+IgnhOcAYFun6WzIsSoDxFLzbpCNysaZ7VeqxIve2Wp m+kzAJteGKxYwKL4qdv20+8iP7ZHAf9AEiwWV2oqGZ/OFfoq3IxMlXL86T1PCCA= =u19F -----END PGP SIGNATURE----- --Apple-Mail=_D655C36C-22F8-447F-BF6F-BED5C801DA5E-- From nobody Tue Mar 7 07:38:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB7E1293E3 for ; Tue, 7 Mar 2017 05:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 mmoSdRHKiHQe for ; Tue, 7 Mar 2017 05:54:25 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72617128B38 for ; Tue, 7 Mar 2017 05:54:25 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v27DsN0d023156; Tue, 7 Mar 2017 14:54:23 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 744DA202BC1; Tue, 7 Mar 2017 14:54: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 6617A206652; Tue, 7 Mar 2017 14:54:23 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27DsNdJ010136; Tue, 7 Mar 2017 14:54:23 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" To: Sander Steffann References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl> From: Alexandre Petrescu Message-ID: Date: Tue, 7 Mar 2017 14:54:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 13:54:39 -0000 Le 07/03/2017 à 13:15, Sander Steffann a écrit : > Hi Alex, > >> Op 7 mrt. 2017, om 11:44 heeft Alexandre Petrescu >> het volgende geschreven: >> >> Le 07/03/2017 à 02:11, 神明é”哉 a écrit : [...] >>> But this thread and another similar discussion seem to suggest >>> that it's still not clear enough for some people. At least two >>> different readers interpret this text: >>> >>>> If the sum of the prefix length and interface identifier >>>> length does not equal 128 bits, the Prefix Information option >>>> MUST be ignored. >> >> Let me say that there are some interpretations of that sum from >> people struggling to make it work. These interpretations may be >> surprising to the specifier. >> >> The specifier is tempted to think that that "sum" equation is a >> good way to tell everything in just one phrase. >> >> But some people face the problem of making that sum be 128 even >> though the plen is less than 64 and the IID is 64. >> >> It is the case with the fe80:://10 needing to become a fe80::/64 > > Which is explicitly specified in RFC 4862 section 5.3. The /10 is > used as the basis and adapted to the IID length on the link. It > explicitly says that all bits between fe80::/10 and the IID are zero > (point 2). That is how you read it, and you read it so because you want to make it work. But this is what the text says: RFC4862: > A link-local address is formed by combining the well-known link-local > prefix FE80::0 Hold on? Isn't that denoting an address? Rather than a prefix? FE80::0 is an address, not a prefix. Were it a prefix it should have been named FE80::/plen. I suspect the author could not write FE80::/10 because s/he was not sure whether that should be FE80::/10 or FE80::/64. So she came up with FE80::0, ignoring that it can be understood as an address by some. And naturally so, because, notationally, it is not clear whether FE80::0 is even allowed, from the point of view of the "::". We know the "::" can not be preceded by 0s in the same sextet (notation FE80:0::/64 is forbidden). But we dont know whether "::" could be followed by hextets made of 0s (we dont know whether FE80::0:0 is allowed). Notationally, we do know that an address written like FE80::1 is a full address (there is no plen specified). It is possible to assign FE80::0 as an address on an interface. Given that, how can the RFC4862 say "the link-local prefix FE80::0"? If so, how much trust can we put in that? If this approximation is permitted, which other approximations are allowed? What does the point 2. actually meant? (As a side remark, it is obvious that these things may appear as too much detail for the person looking from high up, but the notational definition is of utmost importance for someone trying to write a lexical analysis and grammar for textual representation of IPv6 addresses. I.e. any of the numerous GUI or CLI interfaces.) > 2. The bits in the address to the right of the link-local prefix are > set to all zeroes. What is then a "link-local prefix"? Is it fe80::/10? Is it fe80::/64? Did the author actually mean "left" instead of "right", and mean "IID" instead of link-local prefix? We dont know. But we must make it work. So we come up with interpretations. > It also says "The length of the interface identifier is defined in a > separate link-type-specific document". RFC 2464, which is that > link-type-specific document for ethernet, specifies in section 5 that > on ethernet the prefix for link-local addresses is a fe80::/64 with a > 64-bit IID. Yes. > Everything is specified: the /10 to use as the basis, At this time, it seems that /10 is not used for anything else. It is reserved for nothing. You call it a 'basis' but nobody uses such a basis, and it creates confusion as noted above. So someone who insists on 64bit IID and 64bit plens can't continue with that /10 for any reason. > the /64 being the length used on ethernet and the bits between the > two having to be zero. > >> , and it is also the case when PIO in RA has a P1::/63. >> >> For this latter case, one wonders: am I allowed to form an address >> when all I have is a P1::/63, and an IIDlen 64? Can I make a >> P2::/64 by padding with 0s? >> >> The specs dont answer these questions. The specs think that the >> "sum" equation is enough. > > It is. A "sum" is a quite clearly defined mathematical concept. Well, it is as shady as when we say a=1. The mathematician reads it differently than the programmer. A useful equation for programmer is like this: m+n MUST equal 128. You are not allowed to pad if you receive a /63 in RA, or if you have a IID-shorter-than-64; you are not allowed to make addresses of length 129. just the equation is not enough. Moreover, that unclarity leads to deviations like this: 128 can only be made of 2 parts each being 64. > As you quoted above RFC 4862 section 5.5.3 says "If the sum of the > prefix length and interface identifier length does not equal 128 > bits, the Prefix Information option MUST be ignored." Let's test > this. In your example case: - P1::/63 has a prefix length of 63 - > IIDlen (interface identifier length) is 64 - the sum of the prefix > length and the interface identifier length is 63 + 64 = 127 - 127 > does not equal 128 - therefore the Prefix Information option MUST be > ignored And what if I add a 0 bit between the 63 and 64? That plen would become 64. At that point the sum would become 128 again. It's the same thing that people did when adding 0s between /10 and /64 of the FE80:://10 to make it become FE80::/64. Why the specifier can silently add 0bits to make plens 64 for the LL, but implementer couldnt do the same with a received /63? >> Further, because of that, some people think P1::/63 is forbidden >> from being advertised on Ethernet. > > According to RFC 4862 you can advertise it, but receivers must ignore > it. And if so then it is wrong. >> Others think fe80:://10 is the same as fe80::/64. > > As you can see above the fe80::/10 prefix is used as the basis for > the link-local addresses, with the actual prefix length defined per > link-type. For ethernet that has been specified as 64-bits, so that > leads to fe80::/64 on ethernet. > > Please read the RFCs. All the examples you provide are quite > explicitly covered there... I read many times these RFCs... I know what I talk about. You may be overwhelmed by too many emails from my part, but that's another aspect. Alex > > Cheers, Sander > From nobody Tue Mar 7 07:43:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DCF129658 for ; Tue, 7 Mar 2017 06:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 VthZqjp2Ejxa for ; Tue, 7 Mar 2017 06:42:29 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053C61294C8 for ; Tue, 7 Mar 2017 06:37:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 4E6614A; Tue, 7 Mar 2017 15:37:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1488897467; bh=qc6H/odS7BgYLy4ryWk03BqA9Mgl KU5TJ4TSWy/k6NQ=; b=CwnbKatkRflqtV/VGDDyuRy3hUwRLPZ15Ogxo1LZldSY kUapWmrnCihvT2/Qc+zyAVkBhr0E/69o6ofQ0PveUUI5vdyb/UzJIMssuwy/Dhzx TszbIYfs6qME/Mmr659T/bdxh/5DYQcb4e719xXlYCLJmEqHH8qMHaaw3tJpV94= 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 10026) with ESMTP id uR7xNEm-01py; Tue, 7 Mar 2017 15:37:47 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6] (unknown [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 958ED49; Tue, 7 Mar 2017 15:37:46 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_428694BC-5709-4853-A424-CCD51D7C9939"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Tue, 7 Mar 2017 15:37:45 +0100 Message-Id: <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 14:42:37 -0000 --Apple-Mail=_428694BC-5709-4853-A424-CCD51D7C9939 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > But this is what the text says: >=20 > RFC4862: >> A link-local address is formed by combining the well-known link-local >> prefix FE80::0 >=20 > Hold on? Isn't that denoting an address? Rather than a prefix? >=20 > FE80::0 is an address, not a prefix. Were it a prefix it should have > been named FE80::/plen. True, it's written as an address. However, in step 2 it says to set all = bits to the right of the prefix to zero. However you choose to read it, = you end up with fe80:0000:0000:0000:0000:0000:0000:0000. In step 3 the N = rightmost bits of that are overwritten with the N-bits-long IID. > I suspect the author could not write FE80::/10 > because s/he was not sure whether that should be FE80::/10 or = FE80::/64. The ipv6-on-ethernet explicitly states that on ethernet the link-local = prefix is fe80::/64. > So she came up with FE80::0, ignoring that it can be understood as an > address by some. Don't make assumptions. > And naturally so, because, notationally, it is not clear whether = FE80::0 > is even allowed, from the point of view of the "::". We know the "::" > can not be preceded by 0s in the same sextet (notation FE80:0::/64 is > forbidden). But we dont know whether "::" could be followed by = hextets > made of 0s (we dont know whether FE80::0:0 is allowed). Of course it is allowed. fe80:: is the same as fe80:0:0:0:0:0:0:0, is = the same as fe80:0:0::0:0 etc. Where did you get the idea that some of = those notations are forbidden? RFC 4291 only says that "The use of "::" = indicates one or more groups of 16 bits of zeros." nothing more nothing = less. It doesn't mandate using :: for all groups of 16-bits of zeroes, = just "one or more". > Notationally, we do know that an address written like FE80::1 is a = full > address (there is no plen specified). It is possible to assign = FE80::0 > as an address on an interface. >=20 > Given that, how can the RFC4862 say "the link-local prefix FE80::0"? = If > so, how much trust can we put in that? If this approximation is > permitted, which other approximations are allowed? What does the = point > 2. actually meant? If you take it literally and assume that fe80::0 is an address instead = of a prefix, then it is a /128 and point 2 doesn't need to do a thing = because all those bits are 0 already. If you read it as a prefix then = after point 2 you end up with the exact same 128 bits. However, RFC 4862 explicitly refers to "the well-known link-local prefix = FE80::0 [RFC4291]" and although it doesn't write it as a prefix, RFC = 4291 section 2.4 is very explicit that the prefix is fe80::/10. I agree that the wording is a bit unfortunate, but however you read it, = after point 2 the result is the same. > (As a side remark, it is obvious that these things may appear as too > much detail for the person looking from high up, but the notational > definition is of utmost importance for someone trying to write a = lexical > analysis and grammar for textual representation of IPv6 addresses. = I.e. > any of the numerous GUI or CLI interfaces.) >=20 >> 2. The bits in the address to the right of the link-local prefix are >> set to all zeroes. >=20 > What is then a "link-local prefix"? Is it fe80::/10? Is it = fe80::/64? The link local prefix on ethernet is fe80::/64. Other network types may = vary, but on all of them the link-local prefix is within fe80::/10. > Did the author actually mean "left" instead of "right", and mean "IID" > instead of link-local prefix? >=20 > We dont know. But we must make it work. So we come up with > interpretations. ?!?? Stop second-guessing the authors. The wording is quite explicit and = you "alternative interpretations" are not. >> It also says "The length of the interface identifier is defined in a >> separate link-type-specific document". RFC 2464, which is that >> link-type-specific document for ethernet, specifies in section 5 that >> on ethernet the prefix for link-local addresses is a fe80::/64 with a >> 64-bit IID. >=20 > Yes. >=20 >> Everything is specified: the /10 to use as the basis, >=20 > At this time, it seems that /10 is not used for anything else. It is > reserved for nothing. You call it a 'basis' but nobody uses such a > basis, On the most common network types it is indeed not uses. It is reserved = for whatever happens in the future. Maybe nobody will use it, maybe some = future RFC will. What's the problem? > and it creates confusion as noted above. No it doesn't. The /10 is reserved, ethernet uses a /64, other network = types may use something different. Pretty clear. > So someone who insists on 64bit IID and 64bit plens can't continue = with > that /10 for any reason. Why not? No harm in reserving a bit more than you use or need today. >> the /64 being the length used on ethernet and the bits between the >> two having to be zero. >>=20 >>> , and it is also the case when PIO in RA has a P1::/63. >>>=20 >>> For this latter case, one wonders: am I allowed to form an address >>> when all I have is a P1::/63, and an IIDlen 64? Can I make a >>> P2::/64 by padding with 0s? >>>=20 >>> The specs dont answer these questions. The specs think that the >>> "sum" equation is enough. >>=20 >> It is. A "sum" is a quite clearly defined mathematical concept. >=20 > Well, it is as shady as when we say a=3D1. The mathematician reads it > differently than the programmer. >=20 > A useful equation for programmer is like this: m+n MUST equal 128. = You are not allowed to pad if you receive a /63 in RA, or if you have a = IID-shorter-than-64; you are not allowed to make addresses of length = 129. >=20 > just the equation is not enough. The equation is perfectly fine. Do you really want to add "no, you can't = single-handedly modify the input to fit the output, stick to the = equation and the input provided to you"??? Please stop being silly. > Moreover, that unclarity leads to deviations like this: 128 can only = be made of 2 parts each being 64. On ethernet that is correct according to current RFCs. >> As you quoted above RFC 4862 section 5.5.3 says "If the sum of the >> prefix length and interface identifier length does not equal 128 >> bits, the Prefix Information option MUST be ignored." Let's test >> this. In your example case: - P1::/63 has a prefix length of 63 - >> IIDlen (interface identifier length) is 64 - the sum of the prefix >> length and the interface identifier length is 63 + 64 =3D 127 - 127 >> does not equal 128 - therefore the Prefix Information option MUST be >> ignored >=20 > And what if I add a 0 bit between the 63 and 64? That plen would = become > 64. At that point the sum would become 128 again. Again, stop making things up to fit your imagination. The RFC is quite = clear. > It's the same thing that people did when adding 0s between /10 and /64 > of the FE80:://10 to make it become FE80::/64. Nope, that is explicitly specified as such. > Why the specifier can silently add 0bits to make plens 64 for the LL, It's not silent, it's specified. > but implementer couldnt do the same with a received /63? Because the RFC explicitly says not to. >>> Further, because of that, some people think P1::/63 is forbidden >>> from being advertised on Ethernet. >>=20 >> According to RFC 4862 you can advertise it, but receivers must ignore >> it. >=20 > And if so then it is wrong. In none of this I'm saying that I agree with what is written in the = current RFCs. There are plenty of things I would have liked to be done = differently. But today we have the existing RFCs. If things should be = changed then the solution is to write new RFCs, not to play games with = the interpretation of the current ones. > You may be overwhelmed by too many emails from my part, but that's > another aspect. No, my head is quite clear today despite the attempted confusion by = alternative interpretations. Cheers, Sander --Apple-Mail=_428694BC-5709-4853-A424-CCD51D7C9939 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----- iQEcBAEBCAAGBQJYvsW5AAoJEKAtA7D+JBO5Se4H/j4qh+lJioywj/rJfL0X/xVX o5AASrByfuLTxBLU28k1eTSZOAtPND5bZ5Hf4eIY1KijoQ8mBUBXYIi1C6ggfiKO iEnb5EwnePiqB91MUWQbQZCLyZZWnMu8bUi9g6DwwST4qiGeMzL9WX6RIuF/SIlO xC2KNnUZ6rX0rPaPSe/ffTtEBVH7ksKOzLnViHW+g1M0uQhPdfgOAYWMO5hXbQ4Y 7S05ZnQVSpCrpVJu/6sxdZOcprOOhzjamOPnbj+4LY/Qi8bvEMIaGVU7jGulULX/ hKFjG9JB+XJwAx64JqTsm5yeAWRHbGbmfYlZuYnhbz5fk7RVrrF2NDwvQfWC08U= =GhSI -----END PGP SIGNATURE----- --Apple-Mail=_428694BC-5709-4853-A424-CCD51D7C9939-- From nobody Tue Mar 7 08:20:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7941295A9 for ; Tue, 7 Mar 2017 07:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 xfHzkvbotiUX for ; Tue, 7 Mar 2017 07:52:43 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BD712949B for ; Tue, 7 Mar 2017 07:52:40 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v27FqdI0026374; Tue, 7 Mar 2017 16:52:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1CB3120A6FC; Tue, 7 Mar 2017 16:52:39 +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 1086F20A7B0; Tue, 7 Mar 2017 16:52:39 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27Fqcg2003913; Tue, 7 Mar 2017 16:52:38 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" To: Sander Steffann References: <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> From: Alexandre Petrescu Message-ID: Date: Tue, 7 Mar 2017 16:52:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:52:44 -0000 Le 07/03/2017 à 15:37, Sander Steffann a écrit : > Hi, > >> But this is what the text says: >> >> RFC4862: >>> A link-local address is formed by combining the well-known >>> link-local prefix FE80::0 >> >> Hold on? Isn't that denoting an address? Rather than a prefix? >> >> FE80::0 is an address, not a prefix. Were it a prefix it should >> have been named FE80::/plen. > > True, it's written as an address. However, in step 2 it says to set > all bits to the right of the prefix to zero. And what is a prefix? If specifier does not know what is a prefix how could she expect the implementer to implement it? > However you choose to read it, you end up with > fe80:0000:0000:0000:0000:0000:0000:0000. And that is an address. Do you agree? > In step 3 the N rightmost bits of that are overwritten with the > N-bits-long IID. YEs, that covers the 64bit rightmost part. But that does not say what to put between /10 and /64. >> I suspect the author could not write FE80::/10 because s/he was not >> sure whether that should be FE80::/10 or FE80::/64. > > The ipv6-on-ethernet explicitly states that on ethernet the > link-local prefix is fe80::/64. YEs, but IPv6-over-Ethernet is less important than IPv6 Addressing Architecture. This latter says there is an FE80::/10 (and not /64). Do you agree IPv6 Addressing Architecture says "FE80::/10"? >> So she came up with FE80::0, ignoring that it can be understood as >> an address by some. > > Don't make assumptions. So why did she write "prefix FE80::0". Isnt that wrong? Or maybe I should not ask at all? > >> And naturally so, because, notationally, it is not clear whether >> FE80::0 is even allowed, from the point of view of the "::". We >> know the "::" can not be preceded by 0s in the same sextet >> (notation FE80:0::/64 is forbidden). But we dont know whether "::" >> could be followed by hextets made of 0s (we dont know whether >> FE80::0:0 is allowed). > > Of course it is allowed. ? > fe80:: is the same as fe80:0:0:0:0:0:0:0, is the same as > fe80:0:0::0:0 etc. I agree fe80:: is the same as fe80:0:0:0:0:0:0:0. However, both fe80:: and fe80:0:0:0:0:0:0:0 are addresses, not prefixes. A prefix should have a '/' in its notation, like fe80::/64. Moreover, in my interpretation, the fe80::0 is a forbidden notation, because RFC5952 titled "IPv6 text representation" says "2001:0db8::0001 is not acceptable and must be represented as 2001:db8::1". > Where did you get the idea that some of those notations are > forbidden? RFC 4291 only says that "The use of "::" indicates one or > more groups of 16 bits of zeros." nothing more nothing less. It > doesn't mandate using :: for all groups of 16-bits of zeroes, just > "one or more". By RFC5952 titled "IPv6 text representation" saying "2001:0db8::0001 is not acceptable and must be represented as 2001:db8::1". >> Notationally, we do know that an address written like FE80::1 is a >> full address (there is no plen specified). It is possible to >> assign FE80::0 as an address on an interface. >> >> Given that, how can the RFC4862 say "the link-local prefix >> FE80::0"? If so, how much trust can we put in that? If this >> approximation is permitted, which other approximations are allowed? >> What does the point 2. actually meant? > > If you take it literally and assume that fe80::0 is an address > instead of a prefix, No IPv6 literal denotes a prefix without involving a /. In IPv4: it's hard to say whether a notation like 192.168.0.0 is a /16 or a /24. I think the same difficulty stands here. Best is to say the plen by involving the "/". > then it is a /128 That is another question: is FE80::/128 denoting an address or a prefix? > those bits are 0 already. If you read it as a prefix then after point > 2 you end up with the exact same 128 bits. > > However, RFC 4862 explicitly refers to "the well-known link-local > prefix FE80::0 [RFC4291]" That is a wrong notation. There is no such thing as FE80::0 'prefix'. Add that to the confusion between the fe80::/10 prefix and the fe80::/64 prefix. You have a confusion with 3 ingredients here... > and although it doesn't write it as a prefix, RFC 4291 section 2.4 > is very explicit that the prefix is fe80::/10. Saying fe80::/10 is not same as saying fe80::0, sorry. [...] > The equation is perfectly fine. Do you really want to add "no, you > can't single-handedly modify the input to fit the output, stick to > the equation and the input provided to you"??? Please stop being > silly. ? [...] > No, my head is quite clear today despite the attempted confusion by > alternative interpretations. Please clarify this: is it correct to say "prefix FE80::0"? What is the plen of it? Just because it starts with "FE80" does not warrant a plen of value 10. Is it 9? Because after the 9th bit there are only 0s. Or is it 16? Because there are two bytes in FE80. If we dont know what the plen of "FE80::0" is, then it could be anything. As such, what to do when the text says "2. The left-most 'prefix length' bits of the address are those of the link-local prefix." Alex > > Cheers, Sander > From nobody Tue Mar 7 08:38:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338231294EA for ; Tue, 7 Mar 2017 08:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 IhFU2ShpwHOs for ; Tue, 7 Mar 2017 08:38:23 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C951294B8 for ; Tue, 7 Mar 2017 08:38:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 165D94A; Tue, 7 Mar 2017 17:38:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1488904697; bh=aqx7bd/I6+bNO7C2fiuKXoK86vYM QJpaqJbgFaMz2xQ=; b=hdcFp/zN4WnSIKIONjAeS2Dxn8h6GcOlvwb5n71p/ue6 tGjIaloYvKNKpcg876a+116EeZ0KsrlM2ab4XWaP+aG/h2H8gSaPUPxiXOYusY2W LSiiTeFdkXzqUxbZMglePZbr1Nu3x6hdd1aqgvx4o9y17purfDkjorjFUMSaTVU= 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 10026) with ESMTP id pZLsraidOlmB; Tue, 7 Mar 2017 17:38:17 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6] (unknown [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 9900B49; Tue, 7 Mar 2017 17:38:16 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_563F1C91-E1EF-48C9-B956-845494D2B6AE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Tue, 7 Mar 2017 17:38:15 +0100 Message-Id: <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> References: <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 16:38:26 -0000 --Apple-Mail=_563F1C91-E1EF-48C9-B956-845494D2B6AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, >> In step 3 the N rightmost bits of that are overwritten with the >> N-bits-long IID. >=20 > YEs, that covers the 64bit rightmost part. But that does not say what > to put between /10 and /64. Yes it does. In whatever way you read it those bits contain 0. I'm going to stop this thread, this discussion is going nowhere... You = seem to have made up your mind that you *want* to interpret the RFCs in = a way that doesn't make sense, and it's not my job to fix that... Cheers, Sander --Apple-Mail=_563F1C91-E1EF-48C9-B956-845494D2B6AE 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----- iQEcBAEBCAAGBQJYvuH3AAoJEKAtA7D+JBO5I+MH/i7hZcWNBEYLmW97mwmoHvBo ASrv/KOzaUSNuUjagon20cny3TQ6Rz3IWo62lvJGsKbN8TBDccoDdnRgtfRHnLSm zb7fabr9TmenZ4soTrJ1oFRn+KQpZaOpj/AqYqtm+h4d6wCtpwqUqld4oDQHzq/M ZDVrA9KGtBRGpBaD8HPzuvAoQc8sPUqB3cZ8oUjYRuWcWHPJTZ7aqgUE9S2upPJl RJ3dNbIyy8Aq2mWT4Rc+u7STKCBmaiLXzbbJPgXpmvfekO38mW0xEcGUwO7d2qpw SBjdoif6kTodJ/+tUy7JjQuH56Q8kgfP7AxhoC3MSaVrMb7eRkxogJRtAWLBbRg= =+HU2 -----END PGP SIGNATURE----- --Apple-Mail=_563F1C91-E1EF-48C9-B956-845494D2B6AE-- From nobody Tue Mar 7 09:11:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A191129533 for ; Tue, 7 Mar 2017 09:11:18 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bnIEh91PZzrE for ; Tue, 7 Mar 2017 09:11:16 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589BD1294EA for ; Tue, 7 Mar 2017 09:11:16 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1945E8033A; Tue, 7 Mar 2017 18:11:11 +0100 (CET) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" To: Sander Steffann , Alexandre Petrescu References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 7 Mar 2017 13:51:19 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:11:18 -0000 On 03/07/2017 01:38 PM, Sander Steffann wrote: > Hi, > >>> In step 3 the N rightmost bits of that are overwritten with the >>> N-bits-long IID. >> >> YEs, that covers the 64bit rightmost part. But that does not say what >> to put between /10 and /64. > > Yes it does. In whatever way you read it those bits contain 0. Fully agreed. That aside, when you learn link-locals via some APIs in BSDs, you'll find that some of such bits are non-zero -- that's because they leverage the requirement for them to be zero, and use such bits to store e.g. the interface index. (it was one of my WTH moments when coding tools :-) ). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Mar 7 09:12:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA50412953E for ; Tue, 7 Mar 2017 09:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 pwXLb7VHfb4G for ; Tue, 7 Mar 2017 09:12:22 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D741294EA for ; Tue, 7 Mar 2017 09:12:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 627D64A; Tue, 7 Mar 2017 18:12:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1488906738; bh=ncLzLx0HPAvngsPWwviSXngyag3t AF/VPr7DP2ZYVg8=; b=phrJ5e0OLB73yk0hKhcD6UEYHDl+rLLmMkU0yMPH6On+ hgUpWXaF5muZoB1Q8pLGw7KZeqYjnHTCRLCE71PvVX+LJRmg3ubQBeK7UGMxF3Md why391iv+RIlR2N2hOqVFbmfYr6PKK0FZfFX99vSfNQ9xf/yyIBsnsYalfvMduk= 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 10026) with ESMTP id vGsFS61qvD96; Tue, 7 Mar 2017 18:12:18 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6] (unknown [IPv6:2a02:a213:a300:9300:71ae:765:e775:ae6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 5C3AA49; Tue, 7 Mar 2017 18:12:18 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_4A527170-84FB-4F32-8E78-16555515CADA"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Tue, 7 Mar 2017 18:12:17 +0100 Message-Id: <2CDDC8FD-2337-4CA4-AB65-300C30690A00@steffann.nl> References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> To: Fernando Gont X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Alexandre Petrescu , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:12:23 -0000 --Apple-Mail=_4A527170-84FB-4F32-8E78-16555515CADA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 Hi, > That aside, when you learn link-locals via some APIs in BSDs, you'll > find that some of such bits are non-zero -- that's because they leverage > the requirement for them to be zero, and use such bits to store e.g. the > interface index. (it was one of my WTH moments when coding tools :-) ). Yeah, that was surprising for me too :) Cheers, Sander --Apple-Mail=_4A527170-84FB-4F32-8E78-16555515CADA 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----- iQEcBAEBCAAGBQJYvunxAAoJEKAtA7D+JBO5EygH/2sbkJia9Imzq+KX86oKKvNy SjmZfaSJmjbdzhiJTQ8b7K1+ZbagNZ8Wv4A0bx/gfkMpAmrtTv6MgP254wfPRiL/ KTbL/3IRzT/hgklH095a2fSML9yr39t7wVJ67SJGp8TiMtu5XTAudJb11d0UpZkv /FovmIgwLGvaSnwgRkIAMTmNkSq7eT+ZW5SB98QCHKSge4kJAmnxGx4xPjcgc9A4 tozgurxZyjLjY1GSGXKL7d+Dasp3HE11C3TI8zD9OIlc+jI8OKgO8zSVdY+xY+Vf 5mkrZc3gE8YVwGkzNHBGMD2VSc3ixwXj+bj3Vxkd55nXpqNh8usTSVSSCSFf7g4= =wdGh -----END PGP SIGNATURE----- --Apple-Mail=_4A527170-84FB-4F32-8E78-16555515CADA-- From nobody Tue Mar 7 10:36:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19621294C1 for ; Tue, 7 Mar 2017 10:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kWVbnJUDPMum for ; Tue, 7 Mar 2017 10:36:49 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7D012948C for ; Tue, 7 Mar 2017 10:36:49 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id y76so18737000qkb.0 for ; Tue, 07 Mar 2017 10:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nfQLOWDyQDln22iJ8paesCYCSOp/jMAhzWbz3PRP8j4=; b=OIYr1mcmjv6axN/d6zRmjsclPhCSUy5Ay/SKR/gBZ4o06zlr6dtExtDhL4vSQAXDLB +cix3nZsSnvxu9uX4t9tDdItFkdK9/zNEx+th2oWJDv+HO07QzpiYTD/ykaymQplb59B uHBvwP3968/7hDh2n/tbpAJ5clLjEoQvxDRIrXCNYtbO+tOOmryY2WuhqaT4ZOyHlGz9 txwYizm03tQa4M5LNlQ+ilUMlnr7/AsUHL2EJGQo7Omn3LtAtLQkGLckabTe4nEcPeMk 9qu8nYwpWw9diG86NA0KOmPx70yOwF7kAnWs//PNzDx5IqcjQNQ9i/3YeEp0jm4ONBil PQiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nfQLOWDyQDln22iJ8paesCYCSOp/jMAhzWbz3PRP8j4=; b=eLLRkLFgCqy6dGK4Qon+uxb25U+Z0ZL8W87af7Ph3uk7VKHLucS0ODMvMyP26aEOwi W4VG3tJF6malbcMcTzDCPJfe321I/tgJ/lZXQbsbLnQpvbrxvQTweJ/Ba44luMsOo6aM BX1d0Our/BxmncwQl0N+lq6j8DRYzFYYdf8yeENOyNotPIr4pIud03Btjy3dyZJ1tTAy RQhe1QQDiiG/FGyxVsnGbq9BprmKvhxJHV6lBFPGEvOh6ZwzUpKb5LmDMEaDuzm02iBS wrDXfNpQBgs4tgv5k8TTnNkdMLpm1R+z1sIb894aGsNSqizOelZMP2GRuqv2GmD7WeJW a8EA== X-Gm-Message-State: AMke39k/UUBtNht4SzbII+a1u8IoZuutfpESdgvORFaPRB8vgLIINo6/yX2iRCy/8Nx0oSLNt3X2r9zVsJEuBw== X-Received: by 10.200.42.151 with SMTP id b23mr2181674qta.163.1488911808341; Tue, 07 Mar 2017 10:36:48 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Tue, 7 Mar 2017 10:36:47 -0800 (PST) In-Reply-To: <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 7 Mar 2017 10:36:47 -0800 X-Google-Sender-Auth: ThIkwYXGCZfBMBqlHM9FLLQMjmQ Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:36:51 -0000 At Tue, 7 Mar 2017 11:44:04 +0100, Alexandre Petrescu wrote: > > But this thread and another similar discussion seem to suggest that > > it's still not clear enough for some people. At least two different > > readers interpret this text: > > > >> If the sum of the prefix length and interface identifier length > >> does not equal 128 bits, the Prefix Information option MUST be > >> ignored. > > Let me say that there are some interpretations of that sum from people > struggling to make it work. These interpretations may be surprising to > the specifier. > > The specifier is tempted to think that that "sum" equation is a good way > to tell everything in just one phrase. > > But some people face the problem of making that sum be 128 even though > the plen is less than 64 and the IID is 64. > It is the case with the fe80:://10 needing to become a fe80::/64, and it > is also the case when PIO in RA has a P1::/63. At least the above text from Section 5.5.3 of RFC4862 is irrelevant to link-local addresses. The entire Section 5.5 is about "Creation of Global Addresses" as the title shows. In the case of creating global addresses, I can't think of an interpretation of this text If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. as it allows the creation in the case of advertised plen=63 and IID len=64. RFC4862 requires not to do so with the MUST. BSDs implement it that way, and so does Linux (according to what I heard here). I'm also pretty sure that there's a conformance test tool like that for "IPv6 ready logo" or USGv6 that confirms the intent of the RFC. And so I'm also pretty sure that other major OSes interpret the RFC as it intends. So, overall, I don't think it's just what a document editor intends in his mind, but a widely accepted interpretation. That said, there's always someone who understands any seemingly clear text differently from the actual intent, not to mention the recent row about EH insertion. So I'm not surprised that there are such people. If you think this point is so unclear for so many people, I'd suggest you write a clarification draft or submit an errata. If you think we should actually allow the creation in such a case, that's a protocol change, and I'd suggest you write a draft to update RFC4862. With luck, that will become the new standard. I don't think continuing this topic in this thread brings us anywhere, so I'll stop here. -- JINMEI, Tatuya From nobody Tue Mar 7 10:44:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A341294FB for ; Tue, 7 Mar 2017 10:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 K_MpjupmC8On for ; Tue, 7 Mar 2017 10:44:09 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748CC129467 for ; Tue, 7 Mar 2017 10:44:09 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id o126so3817639pfb.3 for ; Tue, 07 Mar 2017 10:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=I0IYRqvL9QFC5WHCOS7nMg4QFXB1O68P3mt/o32EMHU=; b=ARrdx+K9gP1XK8dZhtPIseBAEXW+TBMq1t9GK8qRhI7GUUyEg9ixkkB5sSFVoTfooW x1L5IBrIIRMJCiBDc8RCpjuzzNrE47sQhEDy6uisjWofI3gFOtNSsjdoIbpfx3q03rkm twQeaabbJtsfbnvn/9uC0LO63WC1t+qyhJ+X32zM6dK4QAaSobnI6OeAD2Q0ZMMluAT6 YNErCL7cyw191fIJdnMiT9D8HrR2IgNA3cTGGQBEf7G7l9qmX0dfmjQ0Xgfo4PTBN85Q oAGtb3mhMlAmlxH9wl9mmI0i6lixX/l+BOwbI3yv4mhnBOb09ZphGgTJI1xPYb43M8gd cxow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=I0IYRqvL9QFC5WHCOS7nMg4QFXB1O68P3mt/o32EMHU=; b=MNwbwqLN1TcT/T8liTzsVGEZ9DICG2i3vnn5W639Ap3GzAuu/XZZW55s68XY3Lb/Jr Yu7hYZYz5RDwsQaBpwe4UZCu5DN5y+71E+EnAAoentcdhLb0/cIW8X6j/wvPd5cthuHu aL9fnmXRpjCsJ6pRYYa7tiFOiQCwBqPHG/JoJ9qFJqJ8Pd0ULsnboM7VWjnwv4P8OnB1 /iGzDcVEQDXjYlqBosBraUXfdCvQzEpprXvokwlzB2f4fuve747YH/9aRX7gin3kg+zt M3aK2hJZHOnlbmBTivRtMdiLItvCPWZc6K83G5e1GvhhJIM3kuoYV8pTUEypvbRVsDJa asZw== X-Gm-Message-State: AMke39mQ1NnId2D/66fTGaNX3gHbLcJ14ODK56ZVDUznInBT92EtI+rhAKLe+Q4U1IRoW2ml X-Received: by 10.84.178.195 with SMTP id z61mr2457923plb.139.1488912248815; Tue, 07 Mar 2017 10:44:08 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id x15sm1213750pgo.56.2017.03.07.10.44.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 10:44:08 -0800 (PST) From: james woodyatt Message-Id: <3EC22050-D159-488D-A354-E46F04764E25@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B6AF15B8-A814-4D97-A81B-445BAA61AA75" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 Date: Tue, 7 Mar 2017 10:44:07 -0800 In-Reply-To: To: Timothy Winters References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:44:11 -0000 --Apple-Mail=_B6AF15B8-A814-4D97-A81B-445BAA61AA75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 6, 2017, at 16:34, Timothy Winters wrote: >=20 > I don't believe this test is too strict based on 4862 Section 6.3.4 = "Similarly, > [ADDRCONF ] may = impose certain restrictions on the prefix length for > address configuration purposes. Therefore, the prefix might be > rejected by [ADDRCONF = ] implementation in = the host. However, the > prefix length is still valid for on-link determination when = combined > with other flags in the prefix option." >=20 > Basically ND still works even if SLAAC thinks the prefix length is = invalid. It's really a ND test for on-link deteremination. I=E2=80=99ll run away and think about this some more, but right now I = think it might still be a valid interpretation of the RFC 4862 = requirement language to ignore PIO entirely if Prefix Length is not = valid for the link type. If that means LwIP fails USGv6 and IPv6 Ready = Logo testing, then my opinion is that it's a tussle between those = certification tests and those parts of the IPv6 standards that are not = actually revised by the successor to RFC 4291. --james woodyatt > --Apple-Mail=_B6AF15B8-A814-4D97-A81B-445BAA61AA75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 6, 2017, at 16:34, Timothy Winters <twinters@iol.unh.edu> wrote:

    I don't believe this test is too strict based on 4862 = Section 6.3.4 "Similarly,
       =
[ADDRCONF] may impose certain restrictions on the prefix =
length for
   address configuration purposes.  Therefore, the prefix might be
   rejected by [ADDRCONF] implementation in the host.  However, =
the
       prefix length is still valid =
for on-link determination when combined
       =
with other flags in the prefix option."

    Basically ND still =
works even if SLAAC thinks the prefix length is invalid.   It's really a =
ND test for on-link deteremination.

    I=E2=80=99ll run away and think about this some = more, but right now I think it might still be a valid interpretation of = the RFC 4862 requirement language to ignore PIO entirely if Prefix = Length is not valid for the link type. If that means LwIP fails USGv6 = and IPv6 Ready Logo testing, then my opinion is that it's a tussle = between those certification tests and those parts of the IPv6 standards = that are not actually revised by the successor to RFC = 4291.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_B6AF15B8-A814-4D97-A81B-445BAA61AA75-- From nobody Tue Mar 7 10:50:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A106512957E for ; Tue, 7 Mar 2017 10:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 7pTZnl0RkgjM for ; Tue, 7 Mar 2017 10:50:12 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96E01294A4 for ; Tue, 7 Mar 2017 10:50:11 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id 1so19022017qkl.3 for ; Tue, 07 Mar 2017 10:50:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7tYTHuLHdxR1nmPkGZAPl0R+g0ePHENgzt9MQdhRaxw=; b=RMoSHv2LF8smuAB6Qf2P/o6rPKAgzJO7s4fTaeBOCIClmy6VJPEObwnD8hB+YfZllR y9WjBIhWHrsYvObqXA2ixV7BoT8KgoPzC5sXoSooayRqDooBEGye5JI/sTJ5ijQay9H/ jhLDmxF+E8WMawk8FOHekwz5bcggOTb6OGfaE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7tYTHuLHdxR1nmPkGZAPl0R+g0ePHENgzt9MQdhRaxw=; b=XDzVpO0uJ4xDHpGMNLQwRTVG2pL4cqUglSWSXS97Ffcq0tkhwJUaXrfibkZE3zlEXT +uUcgqallgrmTYHgMUzrzbF70TLBJkE3WTA/8sA+qKLdU8E2OW3glWN/101xlSlufIX0 dJcLTuF/BeF2/8i3lu6g3TW+DJCJBvGTiGMp0T9pw4Akdh4FTET+cAd15OPh1qP4aIMt AflVAvUOq+lcKfe5CNUu2FwCy+bjHE/P7TtkvwzWcr4+h6DPa/9JJM44WrLhPEu+ArD2 +tt9MtMWmVqohm9CVwS+w8f3e+SkAubbmwcNODku6Y56KIfH4F53qGL4pyq0ZiR1/6EO OkfQ== X-Gm-Message-State: AMke39np1hW5sZrkBUegu3go5AsLEUsvPWYC0C2SKl+M+WRHXKvg3vYim6woZRZb7lP99palljz+I6lCgWCcIXbC X-Received: by 10.55.122.194 with SMTP id v185mr2130130qkc.99.1488912610858; Tue, 07 Mar 2017 10:50:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Tue, 7 Mar 2017 10:50:10 -0800 (PST) In-Reply-To: <3EC22050-D159-488D-A354-E46F04764E25@google.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> From: Timothy Winters Date: Tue, 7 Mar 2017 13:50:10 -0500 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: james woodyatt Content-Type: multipart/alternative; boundary=94eb2c063bc445dcc3054a287b2e Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:50:13 -0000 --94eb2c063bc445dcc3054a287b2e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, It's valid to ignore it for SLAAC, but not ND. RFC 4861 is clear about processing the PIO for on-link determination, LwIP isn't following ND spec. Regards, Tim On Tue, Mar 7, 2017 at 1:44 PM, james woodyatt wrote: > On Mar 6, 2017, at 16:34, Timothy Winters wrote: > > > I don't believe this test is too strict based on 4862 Section 6.3.4 " > Similarly, > > [ADDRCONF ] may impo= se certain restrictions on the prefix length for > address configuration purposes. Therefore, the prefix might be > rejected by [ADDRCONF ] implementation in the host. However, the > > prefix length is still valid for on-link determination when combined > > with other flags in the prefix option." > > > Basically ND still works even if SLAAC thinks the prefix length is invali= d. It's really a ND test for on-link deteremination. > > > I=E2=80=99ll run away and think about this some more, but right now I thi= nk it > might still be a valid interpretation of the RFC 4862 requirement languag= e > to ignore PIO entirely if Prefix Length is not valid for the link type. I= f > that means LwIP fails USGv6 and IPv6 Ready Logo testing, then my opinion = is > that it's a tussle between those certification tests and those parts of t= he > IPv6 standards that are not actually revised by the successor to RFC 4291= . > > > --james woodyatt > > > > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --94eb2c063bc445dcc3054a287b2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi James,

    It's valid to ignore it f= or SLAAC, but not ND. =C2=A0 RFC 4861 is clear about processing the PIO for= on-link determination, LwIP isn't following ND spec.

    Regards,
    Tim

    On Tue, Mar 7, 2017 at 1:44 PM, james woodyatt <jhw@= google.com> wrote:
    On Mar 6, 2017, at 16:34, Timo= thy Winters <t= winters@iol.unh.edu> wrote:
    <= div dir=3D"ltr">

    I don't believe this test=C2=A0is t= oo strict based on 4862 Section 6.3.4 "Similarly,
       [ADDRCONF=
] may impose certain restrictions on the prefix length for
   address configuration purposes.  Therefore, the prefix might be
   rejected by [ADDRCONF] implementation in the host.  However, the
       prefix length is still valid for on-lin=
k determination when combined
     =
  with other flags in the prefix option."

    Basically =
ND still works even if SLAAC thinks the prefix length is invalid.   It'=
s really a ND test for on-link deteremination.

    I=E2=80=99ll run away and think about this some mor= e, but right now I think it might still be a valid interpretation of the RF= C 4862 requirement language to ignore PIO entirely if Prefix Length is not = valid for the link type. If that means LwIP fails USGv6 and IPv6 Ready Logo= testing, then my opinion is that it's a tussle between those certifica= tion tests and those parts of the IPv6 standards that are not actually revi= sed by the successor to RFC 4291.


    --james woodyatt <jhw@google.com>






    --

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --94eb2c063bc445dcc3054a287b2e-- From nobody Tue Mar 7 10:52:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F99F12954B for ; Tue, 7 Mar 2017 10:52:39 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 4A8frxydxIHS for ; Tue, 7 Mar 2017 10:52:38 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973491294A4 for ; Tue, 7 Mar 2017 10:52:38 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id b129so3558957pgc.2 for ; Tue, 07 Mar 2017 10:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Rd974OnOm/kZU0/TkKTLb55Vafe41UaV9lJScCG8Fz4=; b=VBBY7y6mZv9eN0K7rPu5l4gzsQ3sjpJtQt0ZMas+giiEsLT2CFyp3aSsOykIrhVlVe FLUrdPESGT+hp3GKspNWA7zgKLjd4UYrln2C7gCwRiaUggsmtevmYH6qH3qhh42Yjnqf oZGuTELh21a4VWrmBcXtRMiditvbxvEwp30aCqZLSjmKe0pK3fotiJmzGaQFr6zBSZ1K s5o6ne14rOQ8y4lXoeyHCsKr+dEmMGfkFpbEVZSJ5B2L/O2hkmcgBIgfGOgxqH4OViX1 aN0e+qQKBKWf7Rw8FqW8RIk4Ny6ZLrbEqZ9COh9Max6taSiVb4IfUnr9TbDris91j8f7 2WuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Rd974OnOm/kZU0/TkKTLb55Vafe41UaV9lJScCG8Fz4=; b=C2msjI/qtXsy+t5OB5vEpqs94j6UQYvtHpLqeOpb3FGvDScuFpJ4pFqNfb2eb4K6O4 mV/r+5WXjxwiBwUinDyTc2qXcRzVo+isTiUQnLXMVefWCIeygBarjIkjlNHAgOeO2okk N/nIIxLF+FrRsjhM6/la1t61YY7VQT1frvLigyk9sYNWicSYbG7tzgdJ3EHt9WaYjArK 5h4bDKFd6FWyxK4Coi1jAbNrgMTz5nS0F7KL5qbeSYursfBpOQ2QilVX+F/RfyPCUkyk 6q6aSkAuS0lBtjTjPxFk2aJmCk8KUaMrqIhiVDPOFdH7wj9x7vQqa1sBM4/DRCorTF/o qHVg== X-Gm-Message-State: AMke39m7AI1Zmf6+WSEhnVX3D5FhjCcCcT0Z6mA4d8y208J/3PVQ7qO+ora/CowR3b0sNELE X-Received: by 10.99.217.69 with SMTP id e5mr2125783pgj.56.1488912757894; Tue, 07 Mar 2017 10:52:37 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id z189sm1316702pgb.3.2017.03.07.10.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 10:52:37 -0800 (PST) From: james woodyatt Message-Id: <5DB1E200-4BCC-450C-8B5C-E8B14506EAD7@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_98692A50-0C82-44CE-B270-1203CE00C47B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 Date: Tue, 7 Mar 2017 10:52:35 -0800 In-Reply-To: To: =?utf-8?B?56We5piO6YGU5ZOJ?= References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:52:39 -0000 --Apple-Mail=_98692A50-0C82-44CE-B270-1203CE00C47B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 6, 2017, at 17:11, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > The bottom line is, if there is an implementation that ignores a PIO > - with both L and A flag on, and > - with prefix length being something other than 64 > - received on a link whose IID is specified to be 64 (like Ethernet) > even for on-link determination, then that implementation violates > RFC4861. LwIP ignores all PIO with Prefix Length not 64, which is the prefix = length on all the link types it supports, regardless of A and L flag = values. --james woodyatt > --Apple-Mail=_98692A50-0C82-44CE-B270-1203CE00C47B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 6, 2017, at 17:11, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = <jinmei@wide.ad.jp> wrote:

    The bottom line is, if there is an = implementation that ignores a PIO
    - with both L and A flag on, = and
    - with prefix length being something other than = 64
    - received on a link whose IID is specified to = be 64 (like Ethernet)
    even for on-link determination, then that = implementation violates
    RFC4861.

    LwIP ignores all PIO with Prefix Length not 64, = which is the prefix length on all the link types it supports, regardless = of A and L flag values.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_98692A50-0C82-44CE-B270-1203CE00C47B-- From nobody Tue Mar 7 10:55:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D293A1294A4 for ; Tue, 7 Mar 2017 10:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=unavailable autolearn_force=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 bLZKr4r1t_aw for ; Tue, 7 Mar 2017 10:55:00 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A8712957F for ; Tue, 7 Mar 2017 10:49:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v27InZBq004102; Tue, 7 Mar 2017 19:49:35 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 277E820509F; Tue, 7 Mar 2017 19:49:35 +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 1A178202D39; Tue, 7 Mar 2017 19:49:35 +0100 (CET) Received: from [132.166.84.102] ([132.166.84.102]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27InY51016619; Tue, 7 Mar 2017 19:49:34 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" To: Sander Steffann References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> From: Alexandre Petrescu Message-ID: <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> Date: Tue, 7 Mar 2017 19:49:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:55:01 -0000 Le 07/03/2017 à 17:38, Sander Steffann a écrit : > Hi, > >>> In step 3 the N rightmost bits of that are overwritten with the >>> N-bits-long IID. >> >> YEs, that covers the 64bit rightmost part. But that does not say >> what to put between /10 and /64. > > Yes it does. In whatever way you read it those bits contain 0. Here it goes: FE80:1::1 does not contain 0s. Nothing can stop me from putting a 1 there. The RFCs should get corrected. > I'm going to stop this thread, this discussion is going nowhere... > You seem to have made up your mind that you *want* to interpret the > RFCs in a way that doesn't make sense, and it's not my job to fix > that... "prefix FE80::0" is incorrect please remove that from that RFC. Say "prefix FE80::/10" instead. Alex > > Cheers, Sander > From nobody Tue Mar 7 10:59:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450A31295EF for ; Tue, 7 Mar 2017 10:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 7kUMfFNFx3zf for ; Tue, 7 Mar 2017 10:59:21 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981871295F3 for ; Tue, 7 Mar 2017 10:59:21 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id v190so4005075pfb.1 for ; Tue, 07 Mar 2017 10:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=alhOCWmDiQU4KH7ZZJV6cF17QXjBarE1ND6aKfLB9Wc=; b=idVlTNP2XSTWSsYMKpJsYACdQZUEwXjrrp1Imc1bSjT1cRcMxqn13nfnh8eE9fowbL mUTSnyk8Mq9jCTitXoCQQ4qOM8r7qkO+LCINWIWDkYSm0hIbARcV2AqLV0VgVI7GabXg dGpPxuBbgKuQAlfT1byqHJ3mblyDSj7Sk2zGdfs09vtBQF9AO9zW/lwVLrNfR5zvl0cl Cphj1DjkUKjtR77a6IRjYgIxIbr7iwQYNBSkvKpxTRO132hlNbn/NuGAwSi3pd4tpN4v qXYWI61I62sqRtgB/x9Jmq77oZO6BZ/7cOVHKpJk/NA4GHCULoQj5vvhdqPVJ1OU4Zke QgQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=alhOCWmDiQU4KH7ZZJV6cF17QXjBarE1ND6aKfLB9Wc=; b=Su2UPVp07kOzv1YnE4gs9eNHe1p/uHtIQQrQKtV7sQ2IxL/eM33uCicA/9s/QUdtMY BzG9mi3esbRYhgSPk8Uec9wLuksT5Xwy3jfYa4cm1tth+XurPKU29dZkTR814LssEP2A GH9GsJOR2hylHqcRCxgbamn3MpDbAGTVNIo4SSgOinPH14G4xLkp+m4LHqv1rzp+qrYV ivjnfwT0w05+GokWFsgxmBMA0TtzMFaF9kjVa8x/2MzDjZDWG7ppWDlQysDHG+5Un4mh 2pzOmYcBwvjWAstoATwIyqLEyOeP5lMHyM+8mfPM5g+DO1HqVMDp8rH9AYqXXNEgNPg8 b/TQ== X-Gm-Message-State: AMke39midZqAQ5N2NW4uQ54f3PrEAy+xeAWrxK4E6Hv8S2NsbmvX8lKDpmE9sHvNI3e4qXsH X-Received: by 10.98.66.155 with SMTP id h27mr2022280pfd.182.1488913161074; Tue, 07 Mar 2017 10:59:21 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id f3sm1286893pga.34.2017.03.07.10.59.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 10:59:20 -0800 (PST) From: james woodyatt Message-Id: <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_151E138E-AA36-44A5-A1DF-B3E3E56929CB" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 Date: Tue, 7 Mar 2017 10:59:19 -0800 In-Reply-To: To: Timothy Winters References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:59:23 -0000 --Apple-Mail=_151E138E-AA36-44A5-A1DF-B3E3E56929CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 7, 2017, at 10:50, Timothy Winters wrote: >=20 > It's valid to ignore it for SLAAC, but not ND. RFC 4861 is clear = about processing the PIO for on-link determination, LwIP isn't following = ND spec. >=20 I=E2=80=99m happy to defer to your considerable expertise in these = matters. Question: could you point me at the requirements language in RFC 4861 = that LwIP is specifically violating? I=E2=80=99m confused because when I = search on the phrase "Prefix Length=E2=80=9D in the text, the relevant = excerpt that seems to apply is this one: >> Note: Implementations can choose to process the on-link aspects = of >> the prefixes separately from the stateless address >> autoconfiguration aspects of the prefixes by, e.g., passing a = copy >> of each valid Router Advertisement message to both an "on-link" >> and an "addrconf" function. Each function can then operate >> independently on the prefixes that have the appropriate flag = set. The way I read this is that implementations MAY choose to process the = Prefix Length validation differently in on-link determination and SLAAC = functions, but that it doesn=E2=80=99t seem to be expressly REQUIRED. = Sadly, there don=E2=80=99t seem to be any other relevant texts about the = Prefix Length. I can believe that LwIP is violating RFC 4861, but before I file an = error report for this, I=E2=80=99d like to be able to cite the actual = requirements keywords, and I=E2=80=99m concerned about the possibility = this Note above may be used by the LwIP maintainers as a justification = to reject the problem report. --james woodyatt > --Apple-Mail=_151E138E-AA36-44A5-A1DF-B3E3E56929CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 7, 2017, at 10:50, Timothy Winters <twinters@iol.unh.edu> wrote:

    It's valid to ignore it for SLAAC, but not ND.   RFC = 4861 is clear about processing the PIO for on-link determination, LwIP = isn't following ND spec.

    I=E2=80=99m happy to defer to your considerable = expertise in these matters.

    Question: = could you point me at the requirements language in RFC 4861 that LwIP is = specifically violating? I=E2=80=99m confused because when I search on = the phrase "Prefix Length=E2=80=9D in the text, the relevant excerpt = that seems to apply is this one:

          Note: Implementations can choose to = process the on-link aspects of
          = the prefixes separately from the stateless address
          autoconfiguration aspects of the = prefixes by, e.g., passing a copy
        =   of each valid Router Advertisement message to both an = "on-link"
          and an "addrconf" = function.  Each function can then operate
     =     independently on the prefixes that have the appropriate = flag set.

    The way I read this is that = implementations MAY choose to process the Prefix Length validation = differently in on-link determination and SLAAC functions, but that it = doesn=E2=80=99t seem to be expressly REQUIRED. Sadly, there don=E2=80=99t = seem to be any other relevant texts about the Prefix Length.

    I can believe that LwIP = is violating RFC 4861, but before I file an error report for this, I=E2=80= =99d like to be able to cite the actual requirements keywords, and I=E2=80= =99m concerned about the possibility this Note above may be used by the = LwIP maintainers as a justification to reject the problem = report.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_151E138E-AA36-44A5-A1DF-B3E3E56929CB-- From nobody Tue Mar 7 11:05:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080AA1293F3 for ; Tue, 7 Mar 2017 11:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 yw3UxiIZDk-A for ; Tue, 7 Mar 2017 11:05:36 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7CC127A91 for ; Tue, 7 Mar 2017 11:05:36 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id y76so20174284qkb.0 for ; Tue, 07 Mar 2017 11:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kWegZ2O8v02Ox6HdcJYAbbokx4R9wxXoPwo/wGFo+dU=; b=dnEuPDBGflEhtKPcVKbStzUDq+iXAYlWVgtdYE+9JS9p19McXIU2XR9L7td0PFwoBu 99Zv4psst5Jqs8KKCQiIA/KhF8oBAWCq6l0pjjn7GZekjbKvE0eUmHpKiSE4G7Ua6UrU PpR3EHtd0ckQp3H+yi1C76ngOr7bgSz7ZaEp0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kWegZ2O8v02Ox6HdcJYAbbokx4R9wxXoPwo/wGFo+dU=; b=J0fHP1rmlxFzjmbBYDUlfW8FVdstyBq4MHH6g7gVHJ1cQ+xAZRYtq+KahjFob8nktk r7vJ7qOzWUmo27scvC9FzSLh+TsSKsBMbjXGJYytYmnBjLWEjKsZK7XKip+0+YpJLbqt dEEhGWDplTr3Ym678ofnQn2qQSUe6ptkY9j8lP62zj5lR/v1yh/U2FZDTYCLmA6wLBQp 9VMQNWaeippNHyeyOkTcL0S55/TTrNhPWBYiUNjCm02w+8rZ+BrHl/JuTkV2XmvSNe+9 RPW07JA6rtBYkKkLFU9t/FvO+dRujYm+4mVaGzfMbrVv1k9TIMdy78hAQ3tq9GgJJmel ut/w== X-Gm-Message-State: AMke39llgzMfBmy4djqn8+mrQptYX2TzaNLH84umYT76jz2oiG8amKScFtFsW82EEg0X0Qx+okcigOLHO8oRnPur X-Received: by 10.55.12.67 with SMTP id 64mr2294439qkm.291.1488913535427; Tue, 07 Mar 2017 11:05:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Tue, 7 Mar 2017 11:05:34 -0800 (PST) In-Reply-To: <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> From: Timothy Winters Date: Tue, 7 Mar 2017 14:05:34 -0500 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: james woodyatt Content-Type: multipart/alternative; boundary=001a114c89ec619343054a28b214 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:05:38 -0000 --001a114c89ec619343054a28b214 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, Last Paragraph of Section 6.3.4 " Similarly,[ADDRCONF] may impose certain restrictions on the prefix length for address configuration purposes. Therefore, the prefix might be rejected by [ADDRCONF] implementation in the host. However, the prefix length is still valid for on-link determination when combined with other flags in the prefix option." It allows for rejection in ADDRCONF as LwIP does, but requires on-link determination. ~Tim On Tue, Mar 7, 2017 at 1:59 PM, james woodyatt wrote: > On Mar 7, 2017, at 10:50, Timothy Winters wrote: > > > It's valid to ignore it for SLAAC, but not ND. RFC 4861 is clear about > processing the PIO for on-link determination, LwIP isn't following ND spe= c. > > I=E2=80=99m happy to defer to your considerable expertise in these matter= s. > > Question: could you point me at the requirements language in RFC 4861 tha= t > LwIP is specifically violating? I=E2=80=99m confused because when I searc= h on the > phrase "Prefix Length=E2=80=9D in the text, the relevant excerpt that see= ms to > apply is this one: > > Note: Implementations can choose to process the on-link aspects of > the prefixes separately from the stateless address > autoconfiguration aspects of the prefixes by, e.g., passing a copy > of each valid Router Advertisement message to both an "on-link" > and an "addrconf" function. Each function can then operate > independently on the prefixes that have the appropriate flag set. > > > The way I read this is that implementations MAY choose to process the > Prefix Length validation differently in on-link determination and SLAAC > functions, but that it doesn=E2=80=99t seem to be expressly REQUIRED. Sad= ly, there > don=E2=80=99t seem to be any other relevant texts about the Prefix Length= . > > I can believe that LwIP is violating RFC 4861, but before I file an error > report for this, I=E2=80=99d like to be able to cite the actual requireme= nts > keywords, and I=E2=80=99m concerned about the possibility this Note above= may be > used by the LwIP maintainers as a justification to reject the problem > report. > > > --james woodyatt > > > > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a114c89ec619343054a28b214 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi James,

    Last Paragraph of Section 6.3= .4=C2=A0

    " =C2=A0Similarly,[ADDRCONF] may imp= ose certain restrictions on the prefix length for
    =C2=A0 =C2=A0ad= dress configuration purposes.=C2=A0 Therefore, the prefix might be
    =C2=A0 =C2=A0rejected by [ADDRCONF] implementation in the host.=C2=A0 How= ever, the
    =C2=A0 =C2=A0prefix length is still valid for on-link d= etermination when combined
    =C2=A0 =C2=A0with other flags in the p= refix option."

    It allows for rejection in ADD= RCONF as LwIP does, but requires on-link determination.

    ~Tim


    On Tue, Mar 7, 2017 at 1:59 PM, james woodyatt <jhw@googl= e.com> wrote:
    On Mar 7, 2017, at 10:50, Timothy W= inters <twinte= rs@iol.unh.edu> wrote:

    It's valid to ig= nore it for SLAAC, but not ND. =C2=A0 RFC 4861 is clear about processing th= e PIO for on-link determination, LwIP isn't following ND spec.

    I=E2=80=99m happy to defer to your considerable e= xpertise in these matters.

    Question: could you poi= nt me at the requirements language in RFC 4861 that LwIP is specifically vi= olating? I=E2=80=99m confused because when I search on the phrase "Pre= fix Length=E2=80=9D in the text, the relevant excerpt that seems to apply i= s this one:

    <= div>
    =C2=A0 =C2=A0 =C2=A0 No= te: Implementations can choose to process the on-link aspects of
    = =C2=A0 =C2=A0 =C2=A0 the prefixes separately from the stateless address
    =C2=A0 =C2=A0 =C2=A0 autoconfiguration aspects of the prefixes by, e= .g., passing a copy
    =C2=A0 =C2=A0 =C2=A0 of each valid Router Adv= ertisement message to both an "on-link"
    =C2=A0 =C2=A0 = =C2=A0 and an "addrconf" function.=C2=A0 Each function can then o= perate
    =C2=A0 =C2=A0 =C2=A0 independently on the prefixes that ha= ve the appropriate flag set.

    =
    The way I read this is that implementations MAY choose to proces= s the Prefix Length validation differently in on-link determination and SLA= AC functions, but that it doesn=E2=80=99t seem to be expressly REQUIRED. Sa= dly, there don=E2=80=99t seem to be any other relevant texts about the Pref= ix Length.

    I can believe that LwIP is violating RF= C 4861, but before I file an error report for this, I=E2=80=99d like to be = able to cite the actual requirements keywords, and I=E2=80=99m concerned ab= out the possibility this Note above may be used by the LwIP maintainers as = a justification to reject the problem report.


    --james woodyatt <jhw@google.com>






    --

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --001a114c89ec619343054a28b214-- From nobody Tue Mar 7 11:07:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB931294A8 for ; Tue, 7 Mar 2017 11:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qp82lNXUff7G for ; Tue, 7 Mar 2017 11:06:56 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56437129490 for ; Tue, 7 Mar 2017 11:06:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v27J6snV008350 for ; Tue, 7 Mar 2017 20:06:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BD1CA20A973 for ; Tue, 7 Mar 2017 20:06:54 +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 B26FB20611F for ; Tue, 7 Mar 2017 20:06:54 +0100 (CET) Received: from [132.166.84.102] ([132.166.84.102]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27J6r5Q031995 for ; Tue, 7 Mar 2017 20:06:54 +0100 Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <6e82e562-e64f-9cc7-47f1-ac439b1bd6f6@gmail.com> Date: Tue, 7 Mar 2017 20:06:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:07:04 -0000 DAvid, I think we talk past each other. But I will duly continue to complain about this :-) Le 06/03/2017 à 19:06, David Farmer a écrit : > A few more tweaks, corrections and other changes some based on feed > back; > > 1. IPv6 unicast routing is 128 bits in length [BCP198]/[RFC7608], > AKA not classful! 2. SLAAC is commonly used to generate unicast > addresses, therefore subnet prefixes and IIDs are 64 bits for most > address. This is a wrong assumption. Because of this assumption there are very bad consequences in the 3GPP networks. > 3. Explicitly allow subnet prefix lengths other than 64 bits for > manually config and DHCPv6 while still recommending 64 bits (most > code does this now and has since the beginning) Also allow them explicitely for SLAAC as well. Allow it for LL prefixes as well. > 4. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by > an IPv6-over-foo doc Really vice-versa: they are variable by default when considered by SLAAC. I think you dont want to accept it, but it's in the RFC. > (we really can't change 64 bit IIDs for SLAAC, it would break running > code, at least not right now, maybe in the future) That is what you think. Sending a RA /65 wont break an existing linux kernel, and new kernels may use 48bit IIDs out of 48bit MAC addresses, pad some 0s, and make a 128 address. I dont undersrtand what you mean by "changing 64bit IIDs for SLAAC would break running code." The person complaining about non-64bit IIDs, as I understand it, complains about non-64bit IIDs *for 464xlat*, not for SLAAC. > 5. Sites should get more than a single /64 [BCP157]/[RFC6177], and > sites include mobile Yes, that is a requirement. Mobile entities including 3GPP UEs MUST get more than a single /64. And that conflicts headfront with some 3GPP spec. That conflict should be solved, not attenuated. Until then we are not in a good position to safely assume that nodes get more than a single /64 per node. > 6. Avoid other explicit exceptions or recommendations for longer > prefixes, like RFC6164 7. include references to [BCP204]/[RFC7934] > and [RFC6052] in the right places > > In the current draft, remove the 2nd paragraph of 2.4, then add the > following sentence to the end of the first paragraph of 2.4; > > Furthermore, IPv6 unicast routing is based on prefixes of any length > up to 128 bits [BCP198]. > > Then add the following two paragraphs at the end of section 2.4; > > Stateless Address Autoconfiguration(SLAAC)[RFC4862] is commonly used > to automatically create unicast addresses, therefore most unicast > addresses have 64-bit subnet prefixes and 64-bit interface IDs. The > rationale for the 64-bit boundary in IPv6 addresses can be found in > [RFC7421]. > > Nevertheless, unicast addresses may also be provided from a node's > internal configuration (AKA manual or static configuration) or via > Dynamic Host Configuration Protocol version 6(DHCPv6)[RFC3315]. Such > addresses are assumed to be opaque 128-bit strings without any > internal structure. These addresses may be associated with subnet > prefixes of any length, while 64-bit subnet prefixes are > recommended. > > Then replace the 4th paragraph of 2.4.1 with; > > When unicast addresses are automatically created from a subnet > prefix and a interface ID (e.g. Stateless Address > Autoconfiguration(SLAAC) [RFC4862]), a 64-bit interface ID length is > required. This is wrong, again. SLAAC does not require 64bit IIDs. It is Ethernet who does. SLAAC works with 48bit IIDs. > An "IPv6 over " specification may modify this requirement for a > specific link type. This is a good requirement. But, most IPv6-over-foo documents _immitate_ Ethernet. I.e. 64+64. Continue this way and no IP-over-foo will ever dare to not immitate Ethernet. > And replace 2.4.4 with; > > The general format for IPv6 Global Unicast addresses is as follows: > > | n bits | m bits | 128-n-m bits | > +------------------------+-----------+----------------------------+ | > global routing prefix | subnet ID | interface ID | > +------------------------+-----------+----------------------------+ > > where the global routing prefix is a (typically hierarchically- > structured) value assigned to a site (a cluster of subnets/links in a > location or mobile), the subnet ID is an identifier of a link within > the site, and the interface ID is as defined in Section 2.4.1. > > As noted in Section 2.4, most unicast addresses, including Global > Unicast addresses, have 64-bit interface IDs (i.e., n + m = 64). This is so wrong, please remove it. There are many GUAs there that dont have 64bit IIDs. Sometimes the IID is just 1. > As discussed in [BCP 157], "it should be easy for an end site to And how about a mobile? Actually it is not that easy, as you can see. As such dont make the assumption. > obtain address space to number multiple subnets (i.e., a block > larger than a single /64)" or in other words the subnet ID length > should be greater than or equal to 1 (i.e., m >= 1). Subnet ID > lengths of 4, 8, 12, and 16 bits, and therefore global routing prefix > lengths of 60, 56, 52, and 48 bits respectively, are in common use > and recommended. Because your assumption for sites does not hold true for mobiles these latter find themselves in the impossibility to actually exist. Were it easy for mobiles to obtain multiple /64s then I would agree with you to continue with this 64. But it is not. > > Dynamic Host Configuration Protocol version 6 - Prefix Delegation > (DHCPv6-PD)[RFC3633] is commonly used to automate the distribution > of global routing prefixes to sites. So one would expect that to Mobiles as well, but no. Alex > > Global Unicast addresses, and their format, are discussed further in > [RFC3587]. > > A couple other quickies; > > Insert new paragraph at the end of 2.1 > > [BCP 204] recommends that networks provide general-purpose nodes > with multiple global IPv6 addresses per interface when they attach to > a link, it also describes the benefits of and the options for doing > so. > > Insert new sentence at the end of 2.4.5 > > Additional IPv6 address that carry an IPv4 address are defined in > IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]. > > Thanks > > -- =============================================== David Farmer > Email:farmer@umn.edu Networking & > Telecommunication Services Office of Information Technology > University of Minnesota 2218 University Ave SE Phone: > 612-626-0815 Minneapolis, MN 55414-3029 > Cell: 612-812-9952 > =============================================== > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Mar 7 11:11:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B879129531 for ; Tue, 7 Mar 2017 11:11:15 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 coEP-WOYxvpf for ; Tue, 7 Mar 2017 11:11:13 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39554129420 for ; Tue, 7 Mar 2017 11:11:09 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id 77so3726533pgc.1 for ; Tue, 07 Mar 2017 11:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/3RyfH7nUuelE0lqrlr/DuXCGCcetCy1gvtEC4oTWzY=; b=puDmILK2fduqBAJPS0h3bvJBr9kQd54JN3uiturbuQ906odxQYQD+Wha5WEA9PKflO x9PRj8qzbxUkJfo5USp4i58G/0whZry9wvUDB3HRpOicvfrm/uBDI5O6QZx5Q9d7PWEm HpxIyQR3W5I8P2YZ3R0zZJLMT6Hdg9By5uwDC3+437bezsLnFizKcSyOpEVQ0tCf3wcK 68pTEWUr1VSznNLvnSBd82avlFudH8MAwleoflOdihtHhrQNpYdz7Z4usor40+WfhG8/ sMfwqTOTsandBY+Obt61GqoSFbdYhiuPQh5oDwarQ6pIXCHvzcWDFKiKFDCTDvp9k6+4 +Hig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/3RyfH7nUuelE0lqrlr/DuXCGCcetCy1gvtEC4oTWzY=; b=sU8nni4Q7pWb2Wa6uV6CWs2jQozW0sDyBnKF2qvIDDNbw6ZdS1OQamlxzR+ZjJcmGX v35kY9pyHootBHcir+4YBRFFx5QV8lTCS/dDM+d7GdnxqmB+2uFbqGncmFrHOjfbhFli 7/p00cqUWUMhIVPwNdZOJkTP9KMT5V3gKW1sf/oF/JKhkNcwJt9XxICPOaHsbz9bJGc5 iSZBXwJB8Ed1P1DeEMqxXT6haZ0m/Tjfzlom83405wtIhB+Cl4bPfQOsfXpZdQuUQwDX 1ZpJsZu4B0/MqAJT9r/ApGcC/of2M2TxiBAXsz9DlXVJeHnXCj2UbzZ4giJhLrqc5N5m KeSQ== X-Gm-Message-State: AMke39kKnFPu4ZdodDVyvhLyHmmI9hdvFR1TfkwsD5Vj95lVY4a40wwOIU9bjSIdctJzALPV X-Received: by 10.99.160.89 with SMTP id u25mr2192368pgn.92.1488913868751; Tue, 07 Mar 2017 11:11:08 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id t5sm1307260pgb.36.2017.03.07.11.11.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 11:11:07 -0800 (PST) From: james woodyatt Message-Id: <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B3BB813D-20A2-4885-B955-FE9E5A9147C9" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 Date: Tue, 7 Mar 2017 11:11:06 -0800 In-Reply-To: To: Timothy Winters References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:11:15 -0000 --Apple-Mail=_B3BB813D-20A2-4885-B955-FE9E5A9147C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 7, 2017, at 11:05, Timothy Winters wrote: >=20 > Last Paragraph of Section 6.3.4=20 >=20 > " Similarly,[ADDRCONF] may impose certain restrictions on the prefix = length for > address configuration purposes. Therefore, the prefix might be > rejected by [ADDRCONF] implementation in the host. However, the > prefix length is still valid for on-link determination when = combined > with other flags in the prefix option." >=20 > It allows for rejection in ADDRCONF as LwIP does, but requires on-link = determination. Respectfully, my concern is that the Note, which immediately follows = that excerpt (see my previous message), provides sufficient = clarification that on-link determination is not REQUIRED to proceed if = Prefix Length is invalid for address configuration purposes in a host = that implements RFC 4862. It is merely OPTIONAL. --james woodyatt > --Apple-Mail=_B3BB813D-20A2-4885-B955-FE9E5A9147C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Mar 7, 2017, at 11:05, Timothy Winters <twinters@iol.unh.edu> wrote:

    Last Paragraph of = Section 6.3.4 

    "  Similarly,[ADDRCONF] may impose certain restrictions = on the prefix length for
       address = configuration purposes.  Therefore, the prefix might be
       rejected by [ADDRCONF] implementation in the = host.  However, the
       prefix length = is still valid for on-link determination when combined
       with other flags in the prefix = option."

    It = allows for rejection in ADDRCONF as LwIP does, but requires on-link = determination.

    Respectfully, my concern is that the Note, which = immediately follows that excerpt (see my previous message), provides = sufficient clarification that on-link determination is not REQUIRED to = proceed if Prefix Length is invalid for address configuration purposes = in a host that implements RFC 4862. It is merely OPTIONAL.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_B3BB813D-20A2-4885-B955-FE9E5A9147C9-- From nobody Tue Mar 7 11:18:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AD912948D for ; Tue, 7 Mar 2017 11:18:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 24HTj3T7yha9 for ; Tue, 7 Mar 2017 11:18:26 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BF1129426 for ; Tue, 7 Mar 2017 11:18:26 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id u30so18995108uau.0 for ; Tue, 07 Mar 2017 11:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VoWgSIs0E+h8QrvpyRwF2yYnm/ecxhs56efUFDBEcUA=; b=Ar38rkB0tUtuOA/5hhJeMcDBeIpf3Ixu8CqET0PsGxWxwyTpE6GdWV6rwXXeZ4P/+v s92EWW1BjSMS4zbkZSDsknNwdB8pmGzSms++uAAnEf8TKiTrIfRixNDTf1UClM0G5gFv YqfG0FY32/T8ttsGqXW7u2CNucKidrqQ2MQSI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VoWgSIs0E+h8QrvpyRwF2yYnm/ecxhs56efUFDBEcUA=; b=QWOwmVi4F7XE5BIHJYHM9+MwajPqqKB201B1Wfr48FCw38INY6OfGvVS459AUzPrM4 xqUKRoYp5sPyNW0j2KsvzC3L8LQ4lEw2m+zFEzx8grCnzxoS9hVWEsc+VMOfUE5iifxb eLzE9W7Cm6uno8o3wy+hQgzys8AiLccUcHCwYDuvlcIBz8ILpZ2nnC5iXYP+PTNNsg6Y yJMgmgibUmIsVj/hU7QYPx4eCjIHAsV/r8hru8PQA7GKWoX7SLH16HcH/Yk35kjwzAE9 SZrAJIdyhGOrJ4BiPJONke7H/pqyV9UlUi2WCvoCX8fJhYsYmkk5EXL9FUAg17EIk7rQ w58Q== X-Gm-Message-State: AMke39lb9D/EhHwoo2mF63TefyWmq9eXQOf5M/d0JA8DPUv6Lkrqnmyav2QfJlsjuDcLbdhGEuxJRVQ8pLCM80QS X-Received: by 10.237.34.125 with SMTP id o58mr2468299qtc.108.1488914305588; Tue, 07 Mar 2017 11:18:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Tue, 7 Mar 2017 11:18:24 -0800 (PST) In-Reply-To: <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> From: Timothy Winters Date: Tue, 7 Mar 2017 14:18:24 -0500 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: james woodyatt Content-Type: multipart/alternative; boundary=001a113f1416496103054a28e0a0 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:18:28 -0000 --001a113f1416496103054a28e0a0 Content-Type: text/plain; charset=UTF-8 Hi James, The NOTE in 4861 states implementations can choose to process them independently. I'm not sure where you it allows for dropping on-link determination if it fails. Can you point me at the line that allows this? Regards, Tim On Tue, Mar 7, 2017 at 2:11 PM, james woodyatt wrote: > On Mar 7, 2017, at 11:05, Timothy Winters wrote: > > > Last Paragraph of Section 6.3.4 > > " Similarly,[ADDRCONF] may impose certain restrictions on the prefix > length for > address configuration purposes. Therefore, the prefix might be > rejected by [ADDRCONF] implementation in the host. However, the > prefix length is still valid for on-link determination when combined > with other flags in the prefix option." > > It allows for rejection in ADDRCONF as LwIP does, but requires on-link > determination. > > > Respectfully, my concern is that the Note, which immediately follows that > excerpt (see my previous message), provides sufficient clarification that > on-link determination is not REQUIRED to proceed if Prefix Length is > invalid for address configuration purposes in a host that implements RFC > 4862. It is merely OPTIONAL. > > > --james woodyatt > > > > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a113f1416496103054a28e0a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi James,

    The NOTE in 4861 states imple= mentations can choose to process them independently. =C2=A0 =C2=A0I'm n= ot sure where you it allows for dropping on-link determination if it fails.= =C2=A0 =C2=A0 Can you point me at the line that allows this?
    Regards,
    Tim
    On Tue, Mar 7, 2017 at 2:11 PM, james woodyatt= <= jhw@google.com> wrote:
    On Mar 7, 2017, at 11:05, = Timothy Winters <twinters@iol.unh.edu> wrote:
    Last Paragraph of Section 6.3.4=C2=A0

    " =C2=A0Similarly,[ADDRCONF] may impose certain restr= ictions on the prefix length for
    =C2=A0 =C2=A0address configurati= on purposes.=C2=A0 Therefore, the prefix might be
    =C2=A0 =C2=A0re= jected by [ADDRCONF] implementation in the host.=C2=A0 However, the
    =C2=A0 =C2=A0prefix length is still valid for on-link determination when= combined
    =C2=A0 =C2=A0with other flags in the prefix option.&quo= t;

    It allows for rejection in ADDRCONF as LwIP doe= s, but requires on-link determination.

    Respectfully, my concern is that the Note, which immediatel= y follows that excerpt (see my previous message), provides sufficient clari= fication that on-link determination is not REQUIRED to proceed if Prefix Le= ngth is invalid for address configuration purposes in a host that implement= s RFC 4862. It is merely OPTIONAL.


    --james woodyatt <jhw@google.com>






    --

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --001a113f1416496103054a28e0a0-- From nobody Tue Mar 7 11:18:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A91C129426 for ; Tue, 7 Mar 2017 11:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 CYbsfT6ZYV0S for ; Tue, 7 Mar 2017 11:18:28 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C54129483 for ; Tue, 7 Mar 2017 11:18:27 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v27JIPk5018516; Tue, 7 Mar 2017 20:18:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 30F3D20961B; Tue, 7 Mar 2017 20:18:25 +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 236E6202938; Tue, 7 Mar 2017 20:18:25 +0100 (CET) Received: from [132.166.84.102] ([132.166.84.102]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27JIOKJ010180; Tue, 7 Mar 2017 20:18:24 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.com> From: Alexandre Petrescu Message-ID: <3a23f15e-afaf-d292-c68f-d6485c18d929@gmail.com> Date: Tue, 7 Mar 2017 20:18:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:18:29 -0000 Le 07/03/2017 à 19:36, 神明é”哉 a écrit : > At Tue, 7 Mar 2017 11:44:04 +0100, Alexandre Petrescu > wrote: > >>> But this thread and another similar discussion seem to suggest >>> that it's still not clear enough for some people. At least two >>> different readers interpret this text: >>> >>>> If the sum of the prefix length and interface identifier >>>> length does not equal 128 bits, the Prefix Information option >>>> MUST be ignored. >> >> Let me say that there are some interpretations of that sum from >> people struggling to make it work. These interpretations may be >> surprising to the specifier. >> >> The specifier is tempted to think that that "sum" equation is a >> good way to tell everything in just one phrase. >> >> But some people face the problem of making that sum be 128 even >> though the plen is less than 64 and the IID is 64. > >> It is the case with the fe80:://10 needing to become a fe80::/64, >> and it is also the case when PIO in RA has a P1::/63. > > At least the above text from Section 5.5.3 of RFC4862 is irrelevant > to link-local addresses. The entire Section 5.5 is about "Creation > of Global Addresses" as the title shows. In the case of creating > global addresses, I can't think of an interpretation of this text > > If the sum of the prefix length and interface identifier length does > not equal 128 bits, the Prefix Information option MUST be ignored. The Host won't drop it because there's that other RFC needing it, right? As such this RFC should say "the received PIO value MUST not be used as such to generate an address; but it could be used if padded with 0s, or trimmed of other bits". > as it allows the creation in the case of advertised plen=63 and IID > len=64. RFC4862 requires not to do so with the MUST. BSDs > implement it that way, and so does Linux (according to what I heard > here). I'm also pretty sure that there's a conformance test tool > like that for "IPv6 ready logo" or USGv6 that confirms the intent of > the RFC. And so I'm also pretty sure that other major OSes interpret > the RFC as it intends. So, overall, I don't think it's just what a > document editor intends in his mind, but a widely accepted > interpretation. > > That said, there's always someone who understands any seemingly > clear text differently from the actual intent, not to mention the > recent row about EH insertion. And there are people looking deep into RFC details to understand what could be implemented correctly, in order to solve this "single-/64-per-Host" delivered by 3GPP. > So I'm not surprised that there are such people. If you think this > point is so unclear for so many people, I'd suggest you write a > clarification draft or submit an errata. If you think we should > actually allow the creation in such a case, that's a protocol change, > and I'd suggest you write a draft to update RFC4862. With luck, that > will become the new standard. > > I don't think continuing this topic in this thread brings us > anywhere, so I'll stop here. This is the topic of allowing or not allowing 64 limit. I think continuing to defend that 64 limit makes no sense after all these problems. The problem is in all these RFCs, and there is no need of a new one. We wrote already too many on this topic of 64. Alex > > -- JINMEI, Tatuya > From nobody Tue Mar 7 11:34:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDEA1294CC for ; Tue, 7 Mar 2017 11:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FUbNjy2RBzm9 for ; Tue, 7 Mar 2017 11:34:48 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438F71294A4 for ; Tue, 7 Mar 2017 11:34:48 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id v125so21022724qkh.2 for ; Tue, 07 Mar 2017 11:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=AhzhYgK1Y0kVM7RyoFb3Y1/xVRro3PouhrBrBiMVAOI=; b=pTcd7Up560frCpp0Le5sBxeL4xqg7rHvYcv4ABg2oVelKilxO+ZFx0hsqYUpSvowMP 2exIYaLWyo3CdL1m34pQBMpDdGM3eXPqtmDD37dI48FyTOCqRVGdBd7e0rC65VYBlrH6 1frsVz8f05GFqTkhYCZm7P0Z68CMN6hX0YPiM3PrP9kRAsa+sZHO/J0LS9lF3sHlyHpZ m0Lk8ovpMueNyJYOq6Wog7nNB7feNp9GbLuyidvYOmOOIdRmVkF3maQ3TbmgKFjs0vol yfOTue8MaTw1yuUhfy/OkRSNrks2BxbU33oGHU9ma7h97CQndWSRPGY6t37U0GI4/9/x K18w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=AhzhYgK1Y0kVM7RyoFb3Y1/xVRro3PouhrBrBiMVAOI=; b=ZU+MzB9olxaUeTuPovf+2j8KOOAbl+GLyN4q1/S2i41ehNal7HYl3ySN89POUmIfeK 9Q04qVbISP4cdu8hr744j95mOh86tGBZWsuLuEkoW61m/MhUOAOsvW5wMcXgyyRkLR/F T7BBDoITTrGs+ZQeVdMBUxZ4AqAagMxrIMOekGuKC2HR805ZeDzPlYpqFURgwDZzA/zn BZTgz12ZVuWpcOe7vDa+lstVl25sdGUJseRkf8PkmsWLS4jNFWQlpIX34ZCYWUvLIiwt iqH/u+q4ioojVTdPielVj17xJDBRR5xNVJ/MvybwAzYBNifduoAIIpv8vxXLElCXFlLV cvag== X-Gm-Message-State: AMke39m28ICkmY4aEj6lTtGSXh4EseP8o536HAHHl+3hnKoZf9vCg1RRx5NsSqcp5aYJy85v5wiQqjwLdbqbww== X-Received: by 10.200.42.151 with SMTP id b23mr2503944qta.163.1488915287193; Tue, 07 Mar 2017 11:34:47 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Tue, 7 Mar 2017 11:34:46 -0800 (PST) In-Reply-To: <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 7 Mar 2017 11:34:46 -0800 X-Google-Sender-Auth: E6RNppaZr6slpXrRHCXvWYCbGrs Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: james woodyatt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:34:50 -0000 At Tue, 7 Mar 2017 10:59:19 -0800, james woodyatt wrote: > > It's valid to ignore it for SLAAC, but not ND. RFC 4861 is clear abou= t processing the PIO for on-link determination, LwIP isn't following ND spe= c. > > > I=E2=80=99m happy to defer to your considerable expertise in these matter= s. > > Question: could you point me at the requirements language in RFC 4861 tha= t LwIP is specifically violating? I=E2=80=99m confused because when I searc= h on the phrase "Prefix Length=E2=80=9D in the text, the relevant excerpt t= hat seems to apply is this one: > > >> Note: Implementations can choose to process the on-link aspects = of > >> the prefixes separately from the stateless address > >> autoconfiguration aspects of the prefixes by, e.g., passing a co= py > >> of each valid Router Advertisement message to both an "on-link" > >> and an "addrconf" function. Each function can then operate > >> independently on the prefixes that have the appropriate flag set= . > > The way I read this is that implementations MAY choose to process the Pre= fix Length validation differently in on-link determination and SLAAC functi= ons, but that it doesn=E2=80=99t seem to be expressly REQUIRED. Sadly, ther= e don=E2=80=99t seem to be any other relevant texts about the Prefix Length= . Hmm...are seeking an RFC2119 keyword REQUIRED, MUST or SHALL in RFC4861 that would make the LwIP implementation non-compliant on this point undeniably? If so, I'm afraid there is no such explicit keyword. Personally, however, the overall text both in RFC4861 and RFC4862 is so clear that such an implementation would be considered non-compliant. In addition to other things pointed out in this discussion, if RFC4862 Section 5.5.3 bullet d If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. would be interpreted as it allows the host to ignore such a prefix (with L=3D1) even for on-link determination, we'd also apply the same logic for other cases, like this one: a) If the Autonomous flag is not set, silently ignore the Prefix Information option. But, I (hopefully) believe no one would ever argue that a host is allowed to ignore a prefix with A=3D0 and L=3D1 for on-link determination because of this bullet. So, if you see the context rather than a specific sentence without taking into account the context, it's also pretty clear to me that bullet d only talks about SLAAC. If these circumstantial evidences are really not enough to convince LwIP implementers, maybe we should file an errata for RFC4861 and/or 4862 to clarify that point. I believe we can at least reach a wg consensus that it's the intent of the RFCs (I'm not sure if we can add an RFC2119 keyword in an errata, though). -- JINMEI, Tatuya From nobody Tue Mar 7 13:19:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B953F1295F9 for ; Tue, 7 Mar 2017 13:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7JWm3CG07MjY for ; Tue, 7 Mar 2017 13:19:24 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DC41295F3 for ; Tue, 7 Mar 2017 13:19:23 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v27LJL12011459 for ; Tue, 7 Mar 2017 22:19:21 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 867A120DA75 for ; Tue, 7 Mar 2017 22:19:21 +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 7D6AF202D39 for ; Tue, 7 Mar 2017 22:19:21 +0100 (CET) Received: from [132.166.84.145] ([132.166.84.145]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27LJLgJ028914 for ; Tue, 7 Mar 2017 22:19:21 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9 To: ipv6@ietf.org References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 7 Mar 2017 22:19:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 21:19:25 -0000 Thanks to this discussion, I would like to promote the following fact that I did not know: If you say "FE80::" without telling the prefix length, that actually means "FE80::/9" (and not FE80::/10, nor FE80::/64). Because 0xFE80 is "1111 1110 1000 0000" in binary representation. Alex Le 07/03/2017 à 19:49, Alexandre Petrescu a écrit : > > > Le 07/03/2017 à 17:38, Sander Steffann a écrit : >> Hi, >> >>>> In step 3 the N rightmost bits of that are overwritten with the >>>> N-bits-long IID. >>> >>> YEs, that covers the 64bit rightmost part. But that does not say >>> what to put between /10 and /64. >> >> Yes it does. In whatever way you read it those bits contain 0. > > Here it goes: FE80:1::1 does not contain 0s. > > Nothing can stop me from putting a 1 there. > > The RFCs should get corrected. > >> I'm going to stop this thread, this discussion is going nowhere... >> You seem to have made up your mind that you *want* to interpret the >> RFCs in a way that doesn't make sense, and it's not my job to fix >> that... > > "prefix FE80::0" is incorrect please remove that from that RFC. Say > "prefix FE80::/10" instead. > > Alex > >> >> Cheers, Sander >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Mar 7 13:22:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061C81289C4 for ; Tue, 7 Mar 2017 13:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 wAYcUqh-djXh for ; Tue, 7 Mar 2017 13:22:39 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595D91204D9 for ; Tue, 7 Mar 2017 13:22:39 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 187so4822848pgb.3 for ; Tue, 07 Mar 2017 13:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zcYyDAZ/HB7w/d/NlOHVkNV7DCma1OSjkJYlJaLkI+8=; b=uhUQB+ZN2+qEnLL9byz0VRm6QAFJMeTw0UKMwIp+BoXOTFerBRMMgYdRBfqj/QNknd Yqzqye/QD5XY3DFXP12UowZzEqmiSPUr6tBhSViSzzJiFg1zwWGza2KD9wJKN+onEmZv QSKZptxfK8y59zXsd252e+lMppnCNHX6vqs3u6QLBFZq0tjMtwpXo+EDFhfBur+Z0hHK 34C5V9XkPrTHmMnG5HXWKBxATqxgS8VaE+W2laqMnCt7WWhBI0WLt5zsusjn/OxSm6Xr WNaeBcDhIhJwqYGuf0dYtv+zImet6Qbg+65WrNdi5tv5VoCOakRVKyesKSQrgQMQszLu FN1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zcYyDAZ/HB7w/d/NlOHVkNV7DCma1OSjkJYlJaLkI+8=; b=G6c2KpwXgL9AWB33lBRYSangrp/InEyxjwVch8GAWv2cKNgKLrnH6wharJcjU4uOKr 8IA3KsGwUXQ1EodCERwGpIxtHsn6uZwqHYWlUROw4aUOPzese/W+nF7m2ZVGeKMn72VL oSGXtEcSTmKd3bSXpzQpyBKG5UKJ5e/LKyf3Dbsg5EO/SzlGD+hdzz5AttBAGTTiE6U9 k/+G247ODD/h176/Y5tBfVMdBcGSYE+OMLXwRXcjTDdzVQ5/nSM4UVL1//fDelJyEbbY IZUs94PZNyE0bTB6zxml4it8MSVkWcCg2iMnu2g6ymweCkCrCWX8akOjsNvHLcoNAjn8 8geQ== X-Gm-Message-State: AMke39kxUqohR+nMsIHXrDOL3DBq3nX86X6Ad3m6w4XcSexz7ygl6ygOvuM8O4DSiqsMJgO5 X-Received: by 10.99.222.17 with SMTP id f17mr2763409pgg.127.1488921758483; Tue, 07 Mar 2017 13:22:38 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id a16sm1543155pgd.62.2017.03.07.13.22.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 13:22:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 From: james woodyatt In-Reply-To: Date: Tue, 7 Mar 2017 13:22:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> To: Timothy Winters , =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 21:22:41 -0000 Hi Tim, To be clear, I=E2=80=99m not trying to be combative. I=E2=80=99m trying = to prepare a case for the LwIP maintainers so that when I ask for my = pull request to be considered I can refer them to this thread. Please be = patient with me here. On Mar 7, 2017, at 11:18, Timothy Winters wrote: >=20 > The NOTE in 4861 states implementations can choose to process them = independently. I'm not sure where you it allows for dropping on-link = determination if it fails. Can you point me at the line that allows = this? Okay, I=E2=80=99m going to go through this line by line, because I think = the case that LwIP is clearly violating RFC 4861 is open to question. = Furthermore, I think the inference from the informative text rather = clearly implies that LwIP is not violating even the *spirit* of the = text, much less the letter of its RFC 2119 keyword language. Please help me find where this argument fails. In RFC 4862, =C2=A76.3.4 Processing Received Router Advertisements: >> Similarly, [ADDRCONF] may impose certain restrictions on the prefix = length for address configuration purposes. I read this to say that additional requirements language MAY apply to = processing the Prefix Length field in PIO elements (the relevant = sections are quoted below) for hosts capable of stateless address = configuration. >> Therefore, the prefix might be rejected by [ADDRCONF] implementation = in the host. I read this as recognizing implicitly that it=E2=80=99s OPTIONAL = (implicitly, because of the use of =E2=80=9Cmight=E2=80=9D instead of = =E2=80=9Cmay=E2=80=9D here is not RFC 2119) for a host to reject a PIO = because of the additional =E2=80=9Ccertain restrictions on prefix = length=E2=80=9D it imposes, cited in RFC 4861. >> However, the prefix length is still valid for on-link determination = when combined with other flags in the prefix option. I read this at face value: prefixes are valid for on-link determination = when combined with other flags in the PIO element *and*, in light of the = preceding sentence, when the =E2=80=9Ccertain restrictions on prefix = length=E2=80=9D imposed by RFC 4862 do not apply, because for example, = the host is configured not to use stateless address configuration for = the interface where the RA message was received. Further discussion is entailed here, because this where the argument = gets a little twisty and legalistic, but as I said, I=E2=80=99m trying = to prepare a case for defending the correctness of the USGv6 and IPv6 = Ready Logo tests to the maintainers of the LwIP project by taking the = opposite view. At this point in the text, it=E2=80=99s an open question which document = has primacy over the validity of a PIO in the case of a host that claims = to conform with both RFC 4861 and RFC 4862, but see the following Note, = which seems to be there for the express purpose of resolving the = question. >> Note: Implementations can choose to process the on-link aspects = of >> the prefixes separately from the stateless address >> autoconfiguration aspects of the prefixes by, e.g., passing a = copy >> of each valid Router Advertisement message to both an "on-link" >> and an "addrconf" function. Each function can then operate >> independently on the prefixes that have the appropriate flag = set. I read this as RFC 4861 again recognizing implicitly that it's OPTIONAL = (using =E2=80=9Ccan=E2=80=9D instead of =E2=80=9Cmay=E2=80=9D) whether = hosts process PIO elements for on-link determination even when they are = rejected by RFC 4862. For this reason, for hosts that choose to reject PIO elements, even for = on-link determination, when the =E2=80=9Ccertain restrictions on the = prefix length=E2=80=9D in RFC 4862 apply, the relevant text from RFC = 4862 needs to be consulted. In RFC 4862, =C2=A75.3 Creation of Link Local Addresses: >> If the sum of the link-local prefix length and N is larger than 128, = autoconfiguration fails and manual configuration is required. The = length of the interface identifier is defined in a separate link- = type-specific document, which should also be consistent with the address = architecture [RFC4291] (see Section 2). These documents will carefully = define the length so that link-local addresses can be autoconfigured on = the link. The key sentence in this passage is "The length of the interface = identifier is defined in a separate link- type-specific document, which = should also be consistent with the address architecture [RFC4291] (see = Section 2).=E2=80=9D As we are preparing to publish a successor to RFC 4291, I will quote the = relevant (and controversial) section of I-D.ietf-6man-rfc4291bis-07: >> IPv6 unicast routing is based on prefixes of any valid length up to = 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on = inter-router point-to-point links. However, the Interface ID of all = unicast addresses, except those that start with the binary value 000, is = required to be 64 bits long. The rationale for the 64 bit boundary in = IPv6 addresses can be found in [RFC7421]. In light of the plethora of updates to RFC 4291, I believe the above to = be a reasonable clarification of the existing text in RFC 7136, =C2=A75, = which expressly updates the original text in RFC 4291, =C2=A72.5.1 as = follows: >> For all unicast addresses, except those that start with the binary = value 000, Interface IDs are required to be 64 bits long. If derived = from an IEEE MAC-layer address, they must be constructed in Modified = EUI-64 format. In both cases, RFC 4291 (updated by RFC 7136) and = I-D.ietf-6man-rfc4291bis-07 (currently awaiting IESG writeup), the = requirement is that IID length for all unicast addresses starting with = 0b000 is 64 bits. Which is relevant to the excerpt above in RFC 4862, = =C2=A75.3 saying that =E2=80=9Cthe length of the interface identifier is = defined in a separate link- type-specific document, which should also be = consistent with the address architecture [RFC4291] (see Section 2).=E2=80=9D= Note Well: the SHOULD in that sentence is a recommendation not a = requirement. So, I read RFC 4862 to REQUIRE that the IID length be defined in a = separate link-type document and to RECOMMEND that the IID length be 64 = bits. (Note: the LwIP implementation only supports link types where the = IID length is already defined in standard documents to be 64 bits). Now, this is important because RFC 4862, =C2=A75.5.3 Router = Advertisement Processing is the text that imposes the =E2=80=9Ccertain = restrictions on prefix length=E2=80=9D referenced in RFC 4861, =C2=A76.3.4= Processing Received Router Advertisements. Here=E2=80=99s what that = says in =C2=B6d after specifying how to form an address by stateless = address configuration: >> If the sum of the prefix length and interface identifier length does = not equal 128 bits, the Prefix Information option MUST be ignored. Reading this in light of the Note in RFC 4862, =C2=A76.3.4, it clearly = imposes =E2=80=9Ccertain restriction on prefix length=E2=80=9D for the = validity of PIO elements. It further REQUIRES that PIO elements with = invalid Prefix Length fields not be used for stateless address = configuration. It does not, however, explicitly override the Note in RFC = 4862, =C2=A76.3.4 that clarifies that it is OPTIONAL for hosts to = process PIO elements for on-link determination even when they have = invalid Prefix Length for stateless address configuration. >> The length of the interface identifier is defined in a separate = link-type specific document, which should also be consistent with the = address architecture [RFC4291] (see Section 2). Here again, RFC 4862 repeats its previous guidance to REQUIRE that the = IID length be defined in a separate link-type document and to RECOMMEND = that the IID length be 64 bits (which LwIP requires of all supported = interface types). But we=E2=80=99re not done. RFC 4862 continues: >> It is the responsibility of the system administrator to ensure that = the lengths of prefixes contained in Router Advertisements are = consistent with the length of interface identifiers for that link type. I do not read this as any requirement on the host implementer to = accommodate system administrators who use Prefix Length values that are = not consistent with the IID length defined for the link type in use. >> It should be noted, however, that this does not mean the advertised = prefix length is meaningless. This is informative and helpful, and not normative text. >> In fact, the advertised length has non-trivial meaning for on-link = determination in [RFC4861] where the sum of the prefix length and the = interface identifier length may not be equal to 128. Indeed, as I read RFC 4861, this recognizes *explicitly* that hosts MAY = use advertised prefixes with invalid Prefix Length for address = configuration, for example, for the purpose of on-link determination. >> Thus, it should be safe to validate the advertised prefix length = here, in order to detect and avoid a configuration error specifying an = invalid prefix length in the context of address autoconfiguration. This is not in conflict with the observation of RFC 4861 that processing = Prefix Lengths for on-link determination that are invalid for address = configuration is not REQUIRED and merely OPTIONAL.=20 >> Note that a future revision of the address architecture [RFC4291] and = a future link-type-specific document, which will still be consistent = with each other, could potentially allow for an interface identifier of = length other than the value defined in the current documents. Thus, an = implementation should not assume a particular constant. Rather, it = should expect any lengths of interface identifiers. As I read this excerpt, this is RFC 4862 expressly recognizing that = future standards action could introduce new valid IID lengths for = address configuration other than 64 bits. This hasn=E2=80=99t happened = yet. (And there is still some controversy about whether RFC 4291 should = not be revised unless it is changed to do so.) Another text relevant to this discussion is IPv6 Subnet Model [RFC = 5942], which has this to say in =C2=A75 Observed Incorrect = Implementation Behavior: >> One incorrect implementation behavior illustrates the severe = consequences when the IPv6 subnet model is not understood by the = implementers of several popular host operating systems. In an access = concentrator network ([RFC4388]), a host receives a Router Advertisement = message with no on-link prefix advertised. For the purposes of this discussion, I invite the reader to imagine in = this scenario the additional consideration that the Prefix Length is not = valid for stateless address configuration and the A flag is also zero. = In other words, a scenario where the rules in question here are = relevant. >> An address could be acquired through the DHCPv6 identity association = for non-temporary addresses (IA_NA) option from [RFC3315] (which does = not include a prefix length), or through manual configuration (if no = prefix length is specified). This address would have to have a valid IID for the link type, according = to RFC 4291. The PIO element here with A=3D0 and L=3D0 and Prefix Length = > 64 is simply advertising legitimately that the router provides = reachability to this longer prefix only to a subset of the valid host = addresses on the subnet. Hosts are not required to add the prefix to the = on-link prefix list, nor to configure an address in that prefix. Hosts could be manually configure addresses with that prefix or obtain = them from DHCPv6 (they would be reachable), but they cannot use SLAAC to = assign addresses with that prefix. And RFC 5942 says they cannot add the = prefix to the on-link prefix list. (It does have some squirrels bits = about RFC 4903.) The rest of this text in RFC 5942 goes on to describe the observed = incorrect behavior in this scenario, and it=E2=80=99s behavior that LwIP = does not have. >> The host incorrectly assumes an invented prefix is on-link. In other words, it=E2=80=99s violating RFC 4861 by failing to recognize = what L=3D0 signifies. >> This invented prefix typically is a /64 that was written by the = developer of the operating system network module API to any IPv6 = application as a "default" prefix length when a length isn't specified. = This may cause the API to seem to work in the case of a network = interface initiating stateless address autoconfiguration (SLAAC); = however, it can cause connectivity problems in Non-Broadcast = Multi-Access (NBMA) networks. Having incorrectly assumed an invented = prefix, the host performs address resolution when the host should send = all non-link-local traffic to a default router. Neither the router nor = any other host will respond to the address resolution, preventing this = host from sending IPv6 traffic. I should observe again here that LwIP performs correctly here, despite = having an implementation defined restriction on link types that have IID = length of 64 bits. It does not add the prefix for two reasons, not just = one: the L flag is zero, and the Prefix Length is invalid. Its behavior also complies with all the rules defined in RFC 5942, =C2=A74= Host Rules, which I will not repeat here. =E2=80=94 In summary, there is a deficit of RFC 2119 keyword language here, and we = have to make the case that the standards texts make a sufficiently = strong implicit case rather than an explicit normative requirement. As explained above, it sure looks to me like a very fair reading of the = implicit requirements language is that LwIP is within the limits of RFC = 4291, RFC 4861 and RFC 4862 when it choose the option of ignoring PIO = elements with invalid prefix length for IID on the underlying link type. Yes, the USGv6 and IPv6 Ready Logo tests are well within their rights to = apply additional requirements beyond the IETF standards, but it seems = like a strict interpretation of the standards allow for LwIP to claim = conformance. How can we counter this argument? --james woodyatt From nobody Tue Mar 7 13:33:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5633B127601 for ; Tue, 7 Mar 2017 13:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 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=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6iklF5nFTDce for ; Tue, 7 Mar 2017 13:33:33 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BA61204D9 for ; Tue, 7 Mar 2017 13:33:32 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id f54so21390414uaa.1 for ; Tue, 07 Mar 2017 13:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p3qt8xG3oPZJdV9mbxg3iyfiZycSjydR7UZDlUR3WkA=; b=vLHYUWPVt6ypmSNq5flfGOhq1xifEl9qCU0iDhpQq6F7nE5n37jVufk3aTKdL+Ze1t 1q9yckFRGWQd8u5LMYHBLXsQCYCTDeGKzVIrJbHrbtZyJmDbJIymB2VBR7Fa6AaQS6GQ Fe5++fwu6uv0oLfqGj5DXW9qnqPwGypxEYauo0e3zlx3DJpIZlj9oUNsmirKCrV0biLJ tFjpSE4mAwVxbkC6t+BWnVpWMn0E83NRam6p8q/ZwIpkFFu1CJH1qVkLnyLjaU+l5etc JH/4p7eKHJZsqEIWWiMmjPEFQUng10rMrQ9eJxUFakIwlb6ZJa8R76KcnsTsYQXfHYYk e6Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p3qt8xG3oPZJdV9mbxg3iyfiZycSjydR7UZDlUR3WkA=; b=s4D+eCUySX7j3tURMvsP0SXkLiOAU6K5w27HgqzkNSvsJRSLToxZdTR8j5eMlK68lg 1XPxG9I6CKcvrFEUBnX7Iv79VV4R6tGulqiR8dwawOiSi72OTt3beKeTLEJuY8wcMvV8 uKd5WsXrNFoRWYYrRy2NOw0LedwPTZ94dbIyjc+kRN4RgVtI5oL48XxRoHfy3EQOA+RN IbId9fzw7MJx+oLWltPvWrIeLQS1sDuZgjzbVfvdxt+0mP1hi4A9lqT8TzpNrAyXG4dg aL1Zg2e2TB+d5/2L3bnJfEhBAZU0Bkkp5Q57ROPQVN8eKOJjuAMYdzJeaEAc+dBdVGK/ /JcA== X-Gm-Message-State: AMke39mcT7F4RQfXKQCfcc31Ztcg2p1TtCIM5Ma+wr9zGBlVp3Uuuph6SO74cKE7YbpnhFoHTxw/6TaWZRkzFA== X-Received: by 10.31.162.130 with SMTP id l124mr1570901vke.123.1488922411940; Tue, 07 Mar 2017 13:33:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.144 with HTTP; Tue, 7 Mar 2017 13:33:31 -0800 (PST) Received: by 10.159.36.144 with HTTP; Tue, 7 Mar 2017 13:33:31 -0800 (PST) In-Reply-To: References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl> From: Mark Smith Date: Wed, 8 Mar 2017 08:33:31 +1100 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum" To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a1143fcf27641a8054a2ac3e1 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 21:33:35 -0000 --001a1143fcf27641a8054a2ac3e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alex, I don't think it is necessary to come up with a further text representation to distinguish between addresses and prefixes. A prefix is a general concept, it specifies, within a set of bits, the set and values of the bits that are defined, and the range of bits that are ignored, in the context where the prefix is used. fe80::/10 is the link-local prefix from within which all more specific link local prefixes come from. An address is a specific example of a prefix, where all bit's value are defined, meaning none are ignored. An address is therefore a prefix with a /128 prefix length. A prefix without a shown prefix length is assumed to have a prefix length of /128. If that doesn't make sense in context, then the error is that the prefix length hasn't been specified. That's the fault of the writer not the reader. We could entirely eliminate the term 'address' by replacing it with '/128 length prefix'. It would be entirely correct, but clumsy. This is all true for IPv4 too, as that is where it has come from. It has been accurate for long enough that trying to change it may cause more confusion not less. Regards, Mark. On 8 Mar. 2017 2:06 am, "Alexandre Petrescu" wrote: Le 07/03/2017 =C3=A0 13:15, Sander Steffann a =C3=A9crit : > Hi Alex, > > Op 7 mrt. 2017, om 11:44 heeft Alexandre Petrescu >> het volgende geschreven: >> >> Le 07/03/2017 =C3=A0 02:11, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3= =A9crit : [...] >> >>> But this thread and another similar discussion seem to suggest >>> that it's still not clear enough for some people. At least two >>> different readers interpret this text: >>> >>> If the sum of the prefix length and interface identifier >>>> length does not equal 128 bits, the Prefix Information option >>>> MUST be ignored. >>>> >>> >> Let me say that there are some interpretations of that sum from >> people struggling to make it work. These interpretations may be >> surprising to the specifier. >> >> The specifier is tempted to think that that "sum" equation is a >> good way to tell everything in just one phrase. >> >> But some people face the problem of making that sum be 128 even >> though the plen is less than 64 and the IID is 64. >> >> It is the case with the fe80:://10 needing to become a fe80::/64 >> > > Which is explicitly specified in RFC 4862 section 5.3. The /10 is > used as the basis and adapted to the IID length on the link. It > explicitly says that all bits between fe80::/10 and the IID are zero > (point 2). > That is how you read it, and you read it so because you want to make it work. But this is what the text says: RFC4862: > A link-local address is formed by combining the well-known link-local > prefix FE80::0 > Hold on? Isn't that denoting an address? Rather than a prefix? FE80::0 is an address, not a prefix. Were it a prefix it should have been named FE80::/plen. I suspect the author could not write FE80::/10 because s/he was not sure whether that should be FE80::/10 or FE80::/64. So she came up with FE80::0, ignoring that it can be understood as an address by some. And naturally so, because, notationally, it is not clear whether FE80::0 is even allowed, from the point of view of the "::". We know the "::" can not be preceded by 0s in the same sextet (notation FE80:0::/64 is forbidden). But we dont know whether "::" could be followed by hextets made of 0s (we dont know whether FE80::0:0 is allowed). Notationally, we do know that an address written like FE80::1 is a full address (there is no plen specified). It is possible to assign FE80::0 as an address on an interface. Given that, how can the RFC4862 say "the link-local prefix FE80::0"? If so, how much trust can we put in that? If this approximation is permitted, which other approximations are allowed? What does the point 2. actually meant? (As a side remark, it is obvious that these things may appear as too much detail for the person looking from high up, but the notational definition is of utmost importance for someone trying to write a lexical analysis and grammar for textual representation of IPv6 addresses. I.e. any of the numerous GUI or CLI interfaces.) 2. The bits in the address to the right of the link-local prefix are > set to all zeroes. > What is then a "link-local prefix"? Is it fe80::/10? Is it fe80::/64? Did the author actually mean "left" instead of "right", and mean "IID" instead of link-local prefix? We dont know. But we must make it work. So we come up with interpretations. It also says "The length of the interface identifier is defined in a > separate link-type-specific document". RFC 2464, which is that > link-type-specific document for ethernet, specifies in section 5 that > on ethernet the prefix for link-local addresses is a fe80::/64 with a > 64-bit IID. > Yes. Everything is specified: the /10 to use as the basis, > At this time, it seems that /10 is not used for anything else. It is reserved for nothing. You call it a 'basis' but nobody uses such a basis, and it creates confusion as noted above. So someone who insists on 64bit IID and 64bit plens can't continue with that /10 for any reason. the /64 being the length used on ethernet and the bits between the > two having to be zero. > > , and it is also the case when PIO in RA has a P1::/63. >> >> For this latter case, one wonders: am I allowed to form an address >> when all I have is a P1::/63, and an IIDlen 64? Can I make a >> P2::/64 by padding with 0s? >> >> The specs dont answer these questions. The specs think that the >> "sum" equation is enough. >> > > It is. A "sum" is a quite clearly defined mathematical concept. > Well, it is as shady as when we say a=3D1. The mathematician reads it differently than the programmer. A useful equation for programmer is like this: m+n MUST equal 128. You are not allowed to pad if you receive a /63 in RA, or if you have a IID-shorter-than-64; you are not allowed to make addresses of length 129. just the equation is not enough. Moreover, that unclarity leads to deviations like this: 128 can only be made of 2 parts each being 64. As you quoted above RFC 4862 section 5.5.3 says "If the sum of the > prefix length and interface identifier length does not equal 128 > bits, the Prefix Information option MUST be ignored." Let's test > this. In your example case: - P1::/63 has a prefix length of 63 - > IIDlen (interface identifier length) is 64 - the sum of the prefix > length and the interface identifier length is 63 + 64 =3D 127 - 127 > does not equal 128 - therefore the Prefix Information option MUST be > ignored > And what if I add a 0 bit between the 63 and 64? That plen would become 64. At that point the sum would become 128 again. It's the same thing that people did when adding 0s between /10 and /64 of the FE80:://10 to make it become FE80::/64. Why the specifier can silently add 0bits to make plens 64 for the LL, but implementer couldnt do the same with a received /63? Further, because of that, some people think P1::/63 is forbidden >> from being advertised on Ethernet. >> > > According to RFC 4862 you can advertise it, but receivers must ignore > it. > And if so then it is wrong. Others think fe80:://10 is the same as fe80::/64. >> > > As you can see above the fe80::/10 prefix is used as the basis for > the link-local addresses, with the actual prefix length defined per > link-type. For ethernet that has been specified as 64-bits, so that > leads to fe80::/64 on ethernet. > > Please read the RFCs. All the examples you provide are quite > explicitly covered there... > I read many times these RFCs... I know what I talk about. You may be overwhelmed by too many emails from my part, but that's another aspect. Alex > Cheers, Sander > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --001a1143fcf27641a8054a2ac3e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Alex,

    I don't think it is necessary to come up with a further text = representation to distinguish between addresses and prefixes.

    A prefix is a general concept, it spe= cifies, within a set of bits, the set and values of the bits that are defin= ed, and the range of bits that are ignored, in the context where the prefix= is used.

    fe80::/10 is t= he link-local prefix from within which all more specific link local prefixe= s come from.

    An address = is a specific example of a prefix, where all bit's value are defined, m= eaning none are ignored. An address is therefore a prefix with a /128 prefi= x length.

    A prefix witho= ut a shown prefix length is assumed to have a prefix length of /128. If tha= t doesn't make sense in context, then the error is that the prefix leng= th hasn't been specified. That's the fault of the writer not the re= ader.

    We could entirely = eliminate the term 'address' by replacing it with '/128 length = prefix'. It would be entirely correct, but clumsy.

    This is all true for IPv4 too, as that is wh= ere it has come from. It has been accurate for long enough that trying to c= hange it may cause more confusion not less.

    Regards,
    Mark.

    <= br>
    On 8 Mar. 2017 2:06 am, "Alexandre Petre= scu" <alexandre.pet= rescu@gmail.com> wrote:


    Le 07/03/2017 =C3=A0 13:15, Sander Steffann a =C3=A9crit :
    Hi Alex,

    Op 7 mrt. 2017, om 11:44 heeft Alexandre Petrescu
    <alexa= ndre.petrescu@gmail.com> het volgende geschreven:

    Le 07/03/2017 =C3=A0 02:11, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3=A9cr= it : [...]
    But this thread and another similar discussion seem to suggest
    that it's still not clear enough for some people.=C2=A0 At least two different readers interpret this text:

    If the sum of the prefix length and interface identifier
    length does not equal 128 bits, the Prefix Information option
    MUST be ignored.

    Let me say that there are some interpretations of that sum from
    people struggling to make it work.=C2=A0 These interpretations may be
    surprising to the specifier.

    The specifier is tempted to think that that "sum" equation is a good way to tell everything in just one phrase.

    But some people face the problem of making that sum be 128 even
    though the plen is less than 64 and the IID is 64.

    It is the case with the fe80:://10 needing to become a fe80::/64

    Which is explicitly specified in RFC 4862 section 5.3. The /10 is
    used as the basis and adapted to the IID length on the link. It
    explicitly says that all bits between fe80::/10 and the IID are zero
    =C2=A0(point 2).

    That is how you read it, and you read it so because you want to make it
    work.

    But this is what the text says:

    RFC4862:
    A link-local address is formed by combining the well-known link-local
    prefix FE80::0

    Hold on?=C2=A0 Isn't that denoting an address?=C2=A0 Rather than a pref= ix?

    FE80::0 is an address, not a prefix.=C2=A0 Were it a prefix it should have<= br> been named FE80::/plen.=C2=A0 I suspect the author could not write FE80::/1= 0
    because s/he was not sure whether that should be FE80::/10 or FE80::/64. =C2=A0So she came up with FE80::0, ignoring that it can be understood as an=
    address by some.

    And naturally so, because, notationally, it is not clear whether FE80::0 is even allowed, from the point of view of the "::".=C2=A0 We kno= w the "::"
    can not be preceded by 0s in the same sextet (notation FE80:0::/64 is
    forbidden).=C2=A0 But we dont know whether "::" could be followed= by hextets
    made of 0s (we dont know whether FE80::0:0 is allowed).

    Notationally, we do know that an address written like FE80::1 is a full
    address (there is no plen specified).=C2=A0 It is possible to assign FE80::= 0
    as an address on an interface.

    Given that, how can the RFC4862 say "the link-local prefix FE80::0&quo= t;?=C2=A0 If
    so, how much trust can we put in that?=C2=A0 If this approximation is
    permitted, which other approximations are allowed?=C2=A0 What does the poin= t
    2. actually meant?

    (As a side remark, it is obvious that these things may appear as too
    much detail for the person looking from high up, but the notational
    definition is of utmost importance for someone trying to write a lexical analysis and grammar for textual representation of IPv6 addresses.=C2=A0 I.= e.
    any of the numerous GUI or CLI interfaces.)

    2.=C2=A0 The bits in the address to the right of the link-local prefix are<= br> set to all zeroes.

    What is then a "link-local prefix"?=C2=A0 Is it fe80::/10?=C2=A0 = Is it fe80::/64?

    Did the author actually mean "left" instead of "right",= and mean "IID"
    instead of link-local prefix?

    We dont know.=C2=A0 But we must make it work.=C2=A0 So we come up with
    interpretations.


    It also says "The length of the interface identifier is defined in a =C2=A0separate link-type-specific document". RFC 2464, which is that link-type-specific document for ethernet, specifies in section 5 that
    on ethernet the prefix for link-local addresses is a fe80::/64 with a
    64-bit IID.

    Yes.


    Everything is specified: the /10 to use as the basis,

    At this time, it seems that /10 is not used for anything else.=C2=A0 It is<= br> reserved for nothing.=C2=A0 You call it a 'basis' but nobody uses s= uch a
    basis, and it creates confusion as noted above.

    So someone who insists on 64bit IID and 64bit plens can't continue with=
    that /10 for any reason.


    the /64 being the length used on ethernet and the bits between the
    two having to be zero.

    , and it is also the case when PIO in RA has a P1::/63.

    For this latter case, one wonders: am I allowed to form an address
    =C2=A0when all I have is a P1::/63, and an IIDlen 64?=C2=A0 Can I make a P2::/64 by padding with 0s?

    The specs dont answer these questions.=C2=A0 The specs think that the
    "sum" equation is enough.

    It is. A "sum" is a quite clearly defined mathematical concept.

    Well, it is as shady as when we say a=3D1.=C2=A0 The mathematician reads it=
    differently than the programmer.

    A useful equation for programmer is like this: m+n MUST equal 128.=C2=A0 Yo= u are not allowed to pad if you receive a /63 in RA, or if you have a IID-s= horter-than-64; you are not allowed to make addresses of length 129.

    just the equation is not enough.

    Moreover, that unclarity leads to deviations like this: 128 can only be mad= e of 2 parts each being 64.


    As you quoted above RFC 4862 section 5.5.3 says "If the sum of the
    prefix length and interface identifier length does not equal 128
    bits, the Prefix Information option MUST be ignored." Let's test this. In your example case: - P1::/63 has a prefix length of 63 -
    IIDlen (interface identifier length) is 64 - the sum of the prefix
    length and the interface identifier length is 63 + 64 =3D 127 - 127
    does not equal 128 - therefore the Prefix Information option MUST be
    =C2=A0ignored

    And what if I add a 0 bit between the 63 and 64?=C2=A0 That plen would beco= me
    64.=C2=A0 At that point the sum would become 128 again.

    It's the same thing that people did when adding 0s between /10 and /64<= br> of the FE80:://10 to make it become FE80::/64.

    Why the specifier can silently add 0bits to make plens 64 for the LL,
    but implementer couldnt do the same with a received /63?


    Further, because of that, some people think P1::/63 is forbidden
    from being advertised on Ethernet.

    According to RFC 4862 you can advertise it, but receivers must ignore
    it.

    And if so then it is wrong.


    Others think fe80:://10 is the same as fe80::/64.

    As you can see above the fe80::/10 prefix is used as the basis for
    the link-local addresses, with the actual prefix length defined per
    link-type. For ethernet that has been specified as 64-bits, so that
    leads to fe80::/64 on ethernet.

    Please read the RFCs. All the examples you provide are quite
    explicitly covered there...

    I read many times these RFCs...=C2=A0 I know what I talk about.

    You may be overwhelmed by too many emails from my part, but that's
    another aspect.

    Alex


    Cheers, Sander


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

    --001a1143fcf27641a8054a2ac3e1-- From nobody Tue Mar 7 13:34:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083F21294CD for ; Tue, 7 Mar 2017 13:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 cbT108ArGf48 for ; Tue, 7 Mar 2017 13:34:03 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id BB3B01204D9 for ; Tue, 7 Mar 2017 13:34:03 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Mar 2017 21:34:02 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id CCE4BD788B; Tue, 7 Mar 2017 13:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=G3kABBJAM2mLxN2sW/l08rGz6bM=; b= eyhnqZBjo6ZtmfqzcgsQa6ULOqu7yJekBydR0PT6W6H11B/aswKk/z86q9YKw9mj 7nH1rhSbTZy1CFsHx7HfAZKomqHITiz48IkuQDXe8Z0rAmkkXPky1x1wS15mP1Sl EVX82U2mDzA4F/JX01+Lxc2afjLSCkc2ZG5Xg0/JL+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=Stf7Ur+DLuwl2+jXUePhwyp reAqnDYrmwIViOP8Ths66xTjb16o/Vb73tIBiwJkqehELNXmejpD0Jdlj9XYp1rs mKn4r4tHPCrC0pH8C4TmlUtEdC94e81RH48N/wduNIaayodFTRDT//wRYo8+Juc3 vC3QOp9laKXwLGFwFZXs= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A1930D7890; Tue, 7 Mar 2017 13:34:01 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1EA7B977B1BB; Tue, 7 Mar 2017 22:34:00 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EE1B7A9D-F23F-46EC-A359-2B8187E49333"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9 Date: Tue, 7 Mar 2017 22:33:58 +0100 In-Reply-To: To: Alexandre Petrescu References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 21:34:05 -0000 --Apple-Mail=_EE1B7A9D-F23F-46EC-A359-2B8187E49333 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Thanks to this discussion, I would like to promote the following fact = that I did not know: >=20 > If you say "FE80::" without telling the prefix length, that actually = means "FE80::/9" (and not FE80::/10, nor FE80::/64). Because 0xFE80 is = "1111 1110 1000 0000" in binary representation. No it doesn't. FE80:: means FE80:0000:0000:0000:0000:0000:0000:0000 Cheers, Ole --Apple-Mail=_EE1B7A9D-F23F-46EC-A359-2B8187E49333 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYvydHAAoJEL7aWKiYQt92+6UP/1rRIxiwfl/mYt1+itJ4gWJv zsEX3xXUk1tmCC0W+v7kww6gSGoquxc8AFP+SbGqTeug3+ODSEGVYL0rRYCKiUpj oLGuha0+/ST+R/5XqF3vjgOC6ANskQhBnpSzT4DhkNS1vHNi+SyWn0qTH4Atk6fu 1p4jqCowmWv2QXl/l+uWhSgh4MmrJhMMpONLoUgqZUPMxsFJCtjyr3DuDVM9tlvt IxOwycM4D1CN/Hd99MyfjsN2BU5WfwA6M7eZp/oZ8KUM/hFjcLVS7UHFaZY5b4sf xUL0nVOQ4RNU0O6BRB9tEUHmVBmKduiQ2u7qKAQm2hQX3+xIWnoS9GnM8OWI4uhQ XHfCUtn4Pp4As91g0763AsJcTL/0O4vyErSExPThSmDDmw9of+DXS2jmIH/a2ptC n+RyYSfgKLuMGS8jd3qER1a1jGAuc/LhCzqfW64Y3h5g+VwGCbTDs6npnMhNNLME c9aNrhHHFMNBjFyqYn4PZhkW4Mq6ZKo5V6eHhpRlrIPOtlfUGLsJQ5Kz6C7r/ai3 qwp2UEDz04c6KC6z8kT/bIHf8fWIAum5cKSag4htI2bbngus/IVnEhzAvqavz2Th aHiL8XXXoUSYNnKGeOI+xHD0NfNB1HU5uJnC2FKRdnAwogBzkRYkFrUTVnUL76o6 IpcIKdiVH5Uz5YStFGqz =vbQQ -----END PGP SIGNATURE----- --Apple-Mail=_EE1B7A9D-F23F-46EC-A359-2B8187E49333-- From nobody Tue Mar 7 13:42:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACB91294D6 for ; Tue, 7 Mar 2017 13:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 Q1ULUuOt-GCz for ; Tue, 7 Mar 2017 13:41:59 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D22E21204D9 for ; Tue, 7 Mar 2017 13:41:59 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Mar 2017 21:41:59 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 8235ED788D; Tue, 7 Mar 2017 13:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=qwqkyPXxKGPiFYTC0G+wx0xesrk=; b= U5e3HIMZ08StrXRUpiS5yQKktX3R84tkA+iZZzKMquX+9tyD0isorIHrE3u0vRbJ KX3UEdG5xMiV+N0VsArGjmUzlIuNQCU/t0ZMCqDzEsIlnXceN0wpB0r9JSH0v5fy jtSy7gaR8Cexw8bqEAil6vLcgJZAHTR1Qix3vCvPE7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=X8xBE2W7UjjyKthPAZdpJPp NhnKXvRPw5q0S80a6hJrBE5M5k2v7cQh1wnoSUP1RJjbBrnPBoetMVcL10SAVgZS Utdk4AmXfwd4kRfQJ93HSMpPKJhqejdNvXKKAzoLHAkIdyHKkGSNZCIc8Y1gHouk it2MyN2JIDyjeeCltIzE= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 0D7D1D788A; Tue, 7 Mar 2017 13:41:59 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 48148977D8DC; Tue, 7 Mar 2017 22:41:56 +0100 (CET) From: otroan@employees.org Message-Id: <36251EE1-309C-44B5-BEAE-591889492547@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_E60C85FE-301D-4898-9F58-B9BDC9FA8233"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 Date: Tue, 7 Mar 2017 22:41:55 +0100 In-Reply-To: To: james woodyatt References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , =?utf-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 21:42:01 -0000 --Apple-Mail=_E60C85FE-301D-4898-9F58-B9BDC9FA8233 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 7 Mar 2017, at 22:22, james woodyatt wrote: >=20 > In summary, there is a deficit of RFC 2119 keyword language here, and = we have to make the case that the standards texts make a sufficiently = strong implicit case rather than an explicit normative requirement. >=20 > As explained above, it sure looks to me like a very fair reading of = the implicit requirements language is that LwIP is within the limits of = RFC 4291, RFC 4861 and RFC 4862 when it choose the option of ignoring = PIO elements with invalid prefix length for IID on the underlying link = type. >=20 > Yes, the USGv6 and IPv6 Ready Logo tests are well within their rights = to apply additional requirements beyond the IETF standards, but it seems = like a strict interpretation of the standards allow for LwIP to claim = conformance. >=20 > How can we counter this argument? We're not writing law, we're specifying what it takes to have = implementations of a specification interoperate. That implementation would fail to interoperate. Cheers, Ole --Apple-Mail=_E60C85FE-301D-4898-9F58-B9BDC9FA8233 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYvykkAAoJEL7aWKiYQt92/r8P/i5ZXDhl3tx7k75Ieaj+QQQ2 i0PMXarqmoK2HXOtfRk5elcO3Ft5PovHG8euYeLr9r57N+gBs02pC0eKztJqkERR 19RcDWYOAHDJBVM50KbYgMBFzq5Z4xdiFsOgwKGTN4pSvK4jktbUezC9yZeyGn+z MMTUOl7rxemSZv/oalMYRWNtlyqX97i9XBfuDqlnzWk1jLaHsGfUg+wZkN9qSz3t +V6bU1bZYaT46JylWJx8Fbv+axVoJ6AcD4f8Yb/9t1OQbclFfmTSLeOgAb1drfhe xDAXwS2Gk/F0y9euwYu5vUQvoRXfZk+UJ8thmTGtipW8bXvZEbPGt3Mmp6G0879U 1xF1HhNKPY6tXORhhq/le5hi3DC4mbko40hsaitwo/wZa/2Xd3rIKAAQ3JAEF71q G9OYKZ/iU0nnDRJS4UccKeLfGkaMQfQGAMUvjJktoRqYCT0oI7mdx5ANIkRrS/9+ HvsuIRSbuO3RBmJak6O4fTNMFRX0D1D0bfdgnr7w1vWBI2BGc+wY47vsDjDi1Tbb WsTu5jviijP2m+m+jkcDGgK7yqPzNQqM/fUvcmwMtIrSHDJK1sY0+ovUkMccQyd1 yGSQEGPcdk4sSBvZEX1bVg2BISL77si17wYAMcOTzDo317TxCY3rQulfDePuSGy0 d4ohgjxdkfDNfpY+joiS =4czb -----END PGP SIGNATURE----- --Apple-Mail=_E60C85FE-301D-4898-9F58-B9BDC9FA8233-- From nobody Tue Mar 7 16:02:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E90F129516; Tue, 7 Mar 2017 16:02:36 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 MA-vKLPOZ6e2; Tue, 7 Mar 2017 16:02:34 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7E0129489; Tue, 7 Mar 2017 16:02:34 -0800 (PST) X-AuditID: c6180641-c3fff70000000a06-d5-58bf03c15d30 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id 79.ED.02566.1C30FB85; Tue, 7 Mar 2017 20:02:28 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0319.002; Tue, 7 Mar 2017 19:02:30 -0500 From: Suresh Krishnan To: Susan Hares Subject: Re: Review of draft-ietf-6man-rfc1981bis-04 Thread-Topic: Review of draft-ietf-6man-rfc1981bis-04 Thread-Index: AQHSlQrd5BFYuQiyL06FWZtjocLrOqGI8MuAgAAj+oCAAVN9gA== Date: Wed, 8 Mar 2017 00:02:30 +0000 Message-ID: <31B447FF-6D4D-4D2A-BD25-FB93D58B08E6@ericsson.com> References: <148864769030.23464.9110014115039938058.idtracker@ietfa.amsl.com> <00fb01d296f5$85c57570$91506050$@ndzh.com> In-Reply-To: <00fb01d296f5$85c57570$91506050$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/signed; boundary="Apple-Mail=_A7DE507A-13D0-4DF8-9820-AA1A7A2ED685"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyuXRPgu4R5v0RBjcXCFlsfb+PzeLY2tcs Fs82zmexeHn2PZNFb9MSZos/b16xOLB57Jx1l91jyZKfTB6zX19nDWCO4rJJSc3JLEst0rdL 4MrYeeM+S8Fl64pV0w6xNDDOMu9i5OSQEDCReHPpK1sXIxeHkMB6RonZr/ezQjjLGCXmXZjC AlLFBlS1YednJhBbREBR4sjVdewgRcwCNxklOi4tYQVJCAMVTZsziRmiyFTi5Pqr7BC2k8Tj o5fYQGwWARWJfxePgQ3iFbCXODr9GjvEtrWMEst/32YESXAKmEuc3HwRrIFRQEzi+6k1YA3M AuISt57MZ4K4W0Ti4cXTbBC2qMTLx/9YIWwliTmvrzFDXDeFUWLR5qXMENsEJU7OfMIygVFk FpJZs5DVzUJSB1GkLbFs4WugOAeQrSMxeSEjRNhU4vXRj1C2tcSMXwfZIGxFiSndD9kXMHKs YuQoLS7IyU03MtzECIzHYxJsjjsY9/Z6HmIU4GBU4uHdMGlfhBBrYllxZe4hRhWg1kcbVl9g lGLJy89LVRLhbbfcHyHEm5JYWZValB9fVJqTWnyIUZqDRUmc93rI/XAhgfTEktTs1NSC1CKY LBMHp1QDo8Pm3Ya63+5wTNWKrFkqzHih6VFN26H8JYtFw31Ftp24KXXtWcZnm5YN28yOu2jc u91u8O3tXo6VJ1++3cfxXz/mVgyvXKTEhRf8RnblNX+/l7gIV8UdXRSfJnNjr5XHpSR5PoEt C8ymXHAKdn523oEpJeufuJTuxKtM+455hZ05X2j6U6tMVomlOCPRUIu5qDgRAChfW6HPAgAA Archived-At: Cc: 6man WG , "ops-dir@ietf.org" , Robert Hinden , IETF , "draft-ietf-6man-rfc1981bis.all@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 00:02:36 -0000 --Apple-Mail=_A7DE507A-13D0-4DF8-9820-AA1A7A2ED685 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sue, Thanks for your review.=20 > On Mar 6, 2017, at 10:47 PM, Susan Hares wrote: >=20 > Bob:=20 >=20 > Thank you for your response. I'm pulling up the remaining questions = to the top here. All my questions were about corner cases and "what = ifs" - which is just the result of being a reviewer of a = long-implemented specification.=20 >=20 > 1) I thought the IPv6 LAN was targeted for new mobile networks or = sensor networks. If so, it may be in the future that the wireless = connections would want to change the MTU on a network to increase the = ability to change the MTU. If you're answer is, we'll make the timer = adjustment when these technology use it in this way, this is a fine = answer.=20 The mobile and sensor networks you talk about can independently increase = the MTU on the access link to which the host initiating PMTUD connects = to. While this will affect the assumed initial value of the PMTU, it may = or may not affect the final PMTU. If the first hop link was the link = with the smallest MTU on the path, increasing it would have an effect on = the PMTU. Else, it will not.=20 >=20 > 3) The question #4 - I was trying to determine what the interaction = between the SEND with an MTU size option, and this update to RFC1918. = It appears in the specification these two functions are interacting. = Is this my imagination? If not, just for my own information - where do = I find this in the specification. =20 The SEND MTU option (which is the same as the ND MTU option - type 5) is = used just to communicate the MTU of the local link. There is no real = interaction between this and PMTUD except for the fact that the Path MTU = cannot exceed this number. Thanks Suresh --Apple-Mail=_A7DE507A-13D0-4DF8-9820-AA1A7A2ED685 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzA4MDAwMjI0WjAjBgkqhkiG9w0B CQQxFgQUZDqtU2YDu+51htj/Hp0X6OFLVWYwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQBdUJvLN2k0SO77M6cEn3F8KcbkVGav5o58lJ4qyej0jXS1hVGl1p7ARJKzbxdQ 4MKjPA2vXWflqucD+ndzOrpF0c29wdofYM4CKKxmjgQOCpJwz88mGfK4yKQ3i4QQ/YTZiKlR9zsM cEJkB9XwY2CrnTjLYkUDW2L0lEHWNc0opFAbbHuESrAyh2JbReFqMLJsaqvCRhslwFWpGVYDkwzk 7BztiALV+0JQHaCjw50L7wMzBmQDWzCi+/EwlAzjwY+vABHOdfOf2WEgg2rc7abx3lVck/lvnZQY A0oNGrO7Av1+rfPeXwYZLQlvV9BJ4wVuOwu/Nx14DMekwc1MRC3WAAAAAAAA --Apple-Mail=_A7DE507A-13D0-4DF8-9820-AA1A7A2ED685-- From nobody Tue Mar 7 19:29:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0833129410 for ; Tue, 7 Mar 2017 19:29: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 autolearn_force=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 5CWiuSG8Ir1A for ; Tue, 7 Mar 2017 19:29:54 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E59129400 for ; Tue, 7 Mar 2017 19:29:54 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 6D67B24AE1A; Wed, 8 Mar 2017 03:28:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 763C7160069; Wed, 8 Mar 2017 03:28:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4D614160047; Wed, 8 Mar 2017 03:28:30 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id axDzvmcbVR-N; Wed, 8 Mar 2017 03:28:30 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id E7E1C160044; Wed, 8 Mar 2017 03:28:29 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9A8FE663A11A; Wed, 8 Mar 2017 14:28:26 +1100 (EST) To: Alexandre Petrescu From: Mark Andrews References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9 In-reply-to: Your message of "Tue, 07 Mar 2017 22:19:21 +0100." Date: Wed, 08 Mar 2017 14:28:26 +1100 Message-Id: <20170308032826.9A8FE663A11A@rock.dv.isc.org> Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:29:55 -0000 In message , Alexandre Petrescu writes: > Thanks to this discussion, I would like to promote the following fact > that I did not know: > > If you say "FE80::" without telling the prefix length, that actually > means "FE80::/9" (and not FE80::/10, nor FE80::/64). Because 0xFE80 is > "1111 1110 1000 0000" in binary representation. > > Alex No. FE80:: is always 128 bits. FE80::/9 says take the first 9 bits from those 128 bits. FE80::/10 says take the first 10 bits from those 128 bits. FE80::/64 says take the first 64 bits from those 128 bits. FE80::/128 says take the first 128 bits from those 128 bits. All link local addresses have a prefix of FE80::/10. Link local addresses on ethernet are further restricted to have a prefix of FE80::/64. They are a strict subset of all valid link local addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Mar 7 21:26:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A421279EB for ; Tue, 7 Mar 2017 21:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 I02y0jRSDyYk for ; Tue, 7 Mar 2017 21:26:10 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C143E129405 for ; Tue, 7 Mar 2017 21:26:09 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 72so29999403uaf.3 for ; Tue, 07 Mar 2017 21:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PX9365nQr6rUh7Jg0zzWT6xY6C8apCnCjh6u66IPdPU=; b=DW4usUSqj1npVF2oov2pzckPzwXBl0+A59KJvRpFkOfQa2MvRLWvlFKDhMMUlo/vZg cgXoYKonfy16kHSbnSdgak1XxtgvtL26WXffW4ypvWN5vcMqwFY1go5Nav5KTTlKG2yb PbhE7Z2qEubrKcaVYebfBw3TbQaj5Bsq9JzTX2uc1/GqoRyCJPjw6OPL+IdwtHSUKcwC KgzB6DpIHPUUEmZgs76SJHteKDyRB1LR1Z+mt/gElCjNK7bT/oWnEE0kYr5+UMMvMExq tnuEp79sKs3FEJ4OiSkBwY8KEg/Um9saF+zhZ1ZMNmxmnEWQVpeiUKSfBC3O/REUGjth xKqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PX9365nQr6rUh7Jg0zzWT6xY6C8apCnCjh6u66IPdPU=; b=gJdom0Gus3xoOPpdbDcRNaAVeY8gScsoAKJAe8IvgeHgTfIEeKbISWLY9YRVWnPfc3 YtGIXLTsjhxU3DB0cEwMn8xODZCycuGkDsB4uNjjP33RkUeEi7/n0P90EvZff8gypxJs lY2RnnFOP9uj7iNtfmYdLOQbXsxIF08u+txeUnjWZJJKpsnmDZNLiTr0g8hGrvBiUHyF xMxQnGPntdkfdUJkGdWkrj4WYM8KoP7vk57k3nemKpPlcT+xuTZKeFea37CBjpUYjVEr 3J1p+hHh8OF/AZwfgmaB85UmuI8ojGVMml4eg7sJSdJJ0kxuLXk/V1vQjSfUXaYMrqFs 5kiw== X-Gm-Message-State: AMke39lsZiSS9PmudDjbeWLVvEVHf5yYXNfYxQk1Ac1ByfO/J2qBjF5LcZIn53HSW3ejZ7RdfaD65gzjuxO81g== X-Received: by 10.176.74.86 with SMTP id r22mr2342007uae.18.1488950768939; Tue, 07 Mar 2017 21:26:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.144 with HTTP; Tue, 7 Mar 2017 21:26:08 -0800 (PST) Received: by 10.159.36.144 with HTTP; Tue, 7 Mar 2017 21:26:08 -0800 (PST) In-Reply-To: References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> From: Mark Smith Date: Wed, 8 Mar 2017 16:26:08 +1100 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9 To: Ole Troan Content-Type: multipart/alternative; boundary=f403045f8ee4abb8e5054a315d9a Archived-At: Cc: Alexandre Petrescu , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 05:26:10 -0000 --f403045f8ee4abb8e5054a315d9a Content-Type: text/plain; charset=UTF-8 On 8 Mar. 2017 8:34 am, wrote: > Thanks to this discussion, I would like to promote the following fact that I did not know: > > If you say "FE80::" without telling the prefix length, that actually means "FE80::/9" (and not FE80::/10, nor FE80::/64). Because 0xFE80 is "1111 1110 1000 0000" in binary representation. No it doesn't. FE80:: means FE80:0000:0000:0000:0000:0000:0000:0000 Or FE80:0000:0000:0000:0000:0000:0000:0000/128 which is an address within the LL space. Possible a statement that a /128 is implied if no prefix length is stated, and is the definition of an "address", could be put in RFC4291bis during AUTH48? Is it a trivial enough change (I think it probably isn't, although it'd be a bit of a shame to have to wait until the next RFC revision of it.) Regards, Mark. Cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --f403045f8ee4abb8e5054a315d9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On 8 Mar. 2017 8:34 am, <otroan@employees.org> wrote:
    > Thanks to this discussion, I = would like to promote the following fact that I did not know:
    >
    > If you say "FE80::" without telling the prefix length, that = actually means "FE80::/9" (and not FE80::/10, nor FE80::/64).=C2= =A0 Because 0xFE80=C2=A0 is "1111 1110 1000 0000" in binary repre= sentation.

    No it doesn't.

    FE80:: means FE80:0000:0000:0000:0000:0000:0000:0000
    <= /div>


    Or

    FE80:0000:0000:0000:0000:0000:00= 00:0000/128

    w= hich is an address within the LL space.

    Possible a statement that a /128 is implied if no prefix le= ngth is stated, and is the definition of an "address", could be p= ut in RFC4291bis during AUTH48? Is it a trivial enough change (I think it p= robably isn't, although it'd be a bit of a shame to have to wait un= til the next RFC revision of it.)

    Regards,
    Mark.

    =




    Cheers,
    Ole


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


    --f403045f8ee4abb8e5054a315d9a-- From nobody Tue Mar 7 23:36:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E8B129635 for ; Tue, 7 Mar 2017 23:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 KvLERlLu_PrX for ; Tue, 7 Mar 2017 23:36:18 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 15E48129613 for ; Tue, 7 Mar 2017 23:36:18 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 08 Mar 2017 07:36:17 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 6D1BFD788D; Tue, 7 Mar 2017 23:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=tIAooMu/lr6PKjuoTvLq140bNu0=; b= nNKc9k3yUh74hOnlvGRhusJN5NrT7+XhrIuMeqf9vQGlRWDwhBWP6YH8KB5S7mJp X/u2R/W1IkKO4RXbNebmwF76qdsJOC07xFo64NV0IoCX4Cts11+4GQrAADnY72JY JmmVReNdtGBtCA4gOO3WK5yyBLrwdqD4QywtkWETQNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=LS5uVGjkZxpoFE8JPJtVbH5 tiK1OFvLLku8DECoqfw058a6/jiws5MIhm6/ul0znIItwb0KdJDez5Xy8DpYeySK KK+2kMTc8Hq4hZ64+xM2iwc6SH8nUKECAqhXOQ3IajixFLqoU9EDMrPIl8LrEifw 4l96kVpPt/wS21rZbgPw= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 00501D788A; Tue, 7 Mar 2017 23:36:17 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 52EFA98296DE; Wed, 8 Mar 2017 08:36:14 +0100 (CET) From: otroan@employees.org Message-Id: <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_DC1D7DDC-5E6A-4D80-A86D-68892EEEACA9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9 Date: Wed, 8 Mar 2017 08:36:13 +0100 In-Reply-To: To: Mark Smith References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Alexandre Petrescu , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 07:36:19 -0000 --Apple-Mail=_DC1D7DDC-5E6A-4D80-A86D-68892EEEACA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, > > Thanks to this discussion, I would like to promote the following = fact that I did not know: > > > > If you say "FE80::" without telling the prefix length, that actually = means "FE80::/9" (and not FE80::/10, nor FE80::/64). Because 0xFE80 is = "1111 1110 1000 0000" in binary representation. >=20 > No it doesn't. >=20 > FE80:: means FE80:0000:0000:0000:0000:0000:0000:0000 >=20 >=20 > Or >=20 > FE80:0000:0000:0000:0000:0000:0000:0000/128 >=20 > which is an address within the LL space. >=20 > Possible a statement that a /128 is implied if no prefix length is = stated, and is the definition of an "address", could be put in = RFC4291bis during AUTH48? Is it a trivial enough change (I think it = probably isn't, although it'd be a bit of a shame to have to wait until = the next RFC revision of it.) I don't see why it would be necessary to imply anything. FE80:: is an address. Not a prefix. E.g. you wouldn't say the packet was = sent from the source FE80::/128. Cheers, Ole --Apple-Mail=_DC1D7DDC-5E6A-4D80-A86D-68892EEEACA9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYv7RuAAoJEL7aWKiYQt92TRQP/2ouQJJUFYFMyxRl1Y3wFu/s ZomRVkdrUgOdTcr858B19uSWph7ebBONa7Vc3UpY/g8AKTfW91vq5MFobNEwaStt awXy+cmZsXLP3l2tobcvS+/G/S7TDeiMLhDrBGAaWCqU73VlE1HGXJ65ybDHWaLz Gj6b84gsgxny8yhzcwZ+9/RRcvtpFlrRzhzJnM0oORs04sI8MBjv5Mxt72m2TCXQ L8x3VKc75bIYW3Wzr+JrszH4VDYwDkUnacdy3KIr84/enhC8jNjLokuU4ikgNw8J iSPG2eLYjByigltP+cn745IPS/mTaBFzyI9V0R+ni2PKiTcAXBDu6z9pFyZyMQHe kVNvjItIPVSuB2jBr31PmBYIZ/OiBzdRsqOAuHCAoOBiiPdJKjX8nfy9O8bg7nP6 mVpKyMqMB+KaLML+rYHzMRkoOPvL+15R/QVcl1L0ZpWW4+I4qoCybTYLKhwoKZKN rCKwiPClE0w8u8TAhi5Wc12GpSqdMBxZ9JbAN77COztuQS4raeRqdKqn97lwV8Co 85B+nkrqIZEowqPxrWYaWorfHs4eJNA+fxlsgTkCoXrHuX7kvS6SpYsVGOhWYvoE ye0ZU2psCa9fAX1AqLXsIUXy7P4T2f2ZGLTG8kbm2k/c2bSTA4Hks1iKb6uTrJc8 sYcyGpn5nYu0BXHM2kdo =SPzO -----END PGP SIGNATURE----- --Apple-Mail=_DC1D7DDC-5E6A-4D80-A86D-68892EEEACA9-- From nobody Wed Mar 8 00:00:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6B91293EE for ; Wed, 8 Mar 2017 00:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 GJLnx0XgeS_4 for ; Wed, 8 Mar 2017 00:00:30 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC50127071 for ; Wed, 8 Mar 2017 00:00:30 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2880SIr008512; Wed, 8 Mar 2017 09:00:28 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9FAA5203C71; Wed, 8 Mar 2017 09:00: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 92B1D200B5B; Wed, 8 Mar 2017 09:00:28 +0100 (CET) Received: from [132.166.84.122] ([132.166.84.122]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2880SOw011176; Wed, 8 Mar 2017 09:00:28 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - LL notation To: Mark Andrews References: <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <6f532a72-a142-5d84-f351-c38cba5230d! d@gmail.c om> <5773AF65-4E7E-43B6-BCB1-26F6E9CD3C60@steffann.nl! > <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <20170308032826.9A8FE663A11A@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: <500edabb-add1-e344-6c97-62bbe70d1988@gmail.com> Date: Wed, 8 Mar 2017 09:00:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170308032826.9A8FE663A11A@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 08:00:32 -0000 Le 08/03/2017 à 04:28, Mark Andrews a écrit : > > In message , Alexandre Petrescu writes: >> Thanks to this discussion, I would like to promote the following fact >> that I did not know: >> >> If you say "FE80::" without telling the prefix length, that actually >> means "FE80::/9" (and not FE80::/10, nor FE80::/64). Because 0xFE80 is >> "1111 1110 1000 0000" in binary representation. >> >> Alex > > No. > > FE80:: is always 128 bits. > FE80::/9 says take the first 9 bits from those 128 bits. YEs, and so it is if we just say "prefix FE80::" without specifying a plen. > FE80::/10 says take the first 10 bits from those 128 bits. YEs, and thus FE81::, FE82:: ... FEBF:: are all LL addresses. I wonder why people only say FE80:: when talking LL address? > FE80::/64 says take the first 64 bits from those 128 bits. > FE80::/128 says take the first 128 bits from those 128 bits. > > All link local addresses have a prefix of FE80::/10. But that does not mean that the notation of all LLs must start precisely with "FE80". These notations could start with "FE81", "FE82" ... "FEBF". Up to "FEC0" which is a GUA not an LL. As such, a better way would be to say that LL addresses are of the form "FE##" where ## range from 81 to BF hexa. > Link local addresses on ethernet are further restricted to > have a prefix of FE80::/64. They are a strict subset of > all valid link local addresses. YEs, and moreover, in this particular LL case, I suppose not only IP-over-Ethernet requires FE80::/64 but also SLAAC. I.e. SLAAC on _any_ link (be it Ethernet or any other future link) seems to require the use of FE80::/64 prefix and does not allow for "FE81" or "FEBF". An I-D describing the formation of LL addresses out of "FE##:://10" prefixes could make sense. Alex From nobody Wed Mar 8 02:08:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA00129468 for ; Wed, 8 Mar 2017 02:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mE-bs4GKt5dJ for ; Wed, 8 Mar 2017 02:08:09 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA62127071 for ; Wed, 8 Mar 2017 02:08:09 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id t8so6705511vke.3 for ; Wed, 08 Mar 2017 02:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xQY46JBfComnHIRklo+yhw1Yer8ZBiSSuqqGEkqbETo=; b=KGlMfbyAX+EDA5yWcOQy96QibXRZ0t4L+qggZ7H77ke0/6hIvRXsGah3mQrN7GW0v1 +oMYLo6vWGNaUoSWAEpn2gvWj2ysAoM/RUE0DYmoV8icOADLShm/GRlxOC5Ro3fhG7+d 2sE5Ful8C+9/ocyc/dw93EFP5Zck6fIef1YglC2c3Dzf+eKkqsu0lKXKkVwV/TDImoE0 N/gatJ0MLjyZOLYyQruKGOTpPIJsbnINqihMuDkja/Zt2H62YIwBGDFah3jqHbz8ra0P o9nyA8VrL2ElAdfC7qGf2URewsxEBDDBJezyo9s0zDEMdJqtnJ6uDKlcObisw/VVHqk2 KONg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xQY46JBfComnHIRklo+yhw1Yer8ZBiSSuqqGEkqbETo=; b=jUqQv3Ugcaic6K8WHg2+SodbPgvAYzTEe4OcjzsPUdndaYgRkNf3QDyMoyma+cuoog yS6RIigjwknj673uo9VrsuPq8n1jU2ialeT7qagiogtdF5F0P0kT+SDhBKxaVbF4o+DJ G9T2IUi4BiBwT9Ir4OLRi4ZZ4uxenlqtUN+GYd8yvkzKiyN2970jz9zHtSB/kJu2i+Jt tCMJD1wJPPXbzOeVCf0srDBWTx/UqfH4Hoa4lmd1UfGzVWN/1L3oAMkyNngTDjZRiM6E 7YOn0d2NY7STiEJiMgF6eZjQ7KkenAXMJFWxC5njH0Z4W1TqoVRM4pOiJ5yGz3En+pL0 Gr5A== X-Gm-Message-State: AMke39lCyQtn3OPzXXZ9Qk2fdI8sSsWu3bDiVP5O0J+DiE3AT0w/wX4QlbTzWXrBA/3WZuz+5c+t9cVhhuXgsg== X-Received: by 10.31.162.130 with SMTP id l124mr3154939vke.123.1488967688641; Wed, 08 Mar 2017 02:08:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.144 with HTTP; Wed, 8 Mar 2017 02:07:38 -0800 (PST) In-Reply-To: <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> From: Mark Smith Date: Wed, 8 Mar 2017 21:07:38 +1100 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9 To: Ole Troan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alexandre Petrescu , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 10:08:10 -0000 On 8 Mar. 2017 6:36 pm, wrote: Mark, > > Thanks to this discussion, I would like to promote the following fact t= hat I did not know: > > > > If you say "FE80::" without telling the prefix length, that actually me= ans "FE80::/9" (and not FE80::/10, nor FE80::/64). Because 0xFE80 is "111= 1 1110 1000 0000" in binary representation. > > No it doesn't. > > FE80:: means FE80:0000:0000:0000:0000:0000:0000:0000 > > > Or > > FE80:0000:0000:0000:0000:0000:0000:0000/128 > > which is an address within the LL space. > > Possible a statement that a /128 is implied if no prefix length is stated= , and is the definition of an "address", could be put in RFC4291bis during = AUTH48? Is it a trivial enough change (I think it probably isn't, although = it'd be a bit of a shame to have to wait until the next RFC revision of it.= ) >I don't see why it would be necessary to imply anything. I say implied, because when "FE80::" is written that way, it is saying that for the purposes of IPv6 processing (what ever that processing may be), all 128 bits are significant - the "/128" is implicit. "FE80::/128" is also saying that, except that it is explicitly stating that all 128 bits are significant. >FE80:: is an address. Not a prefix. If it isn't a prefix because it doesn't have "/128" on it, then that is what makes it an "address". However, "FE80::/128" is an entirely accurate and exact equivalent replacement for it, so functionally, "FE80::" and "FE80::/128" are equal. >E.g. you wouldn't say the packet was sent from the source FE80::/128. You wouldn't say it, but you could say it, it would be correct. Here's an example of their equivalence. I assign an IPv6 address to an interface under Linux, and it shows it as a /128 prefix. [root@opy mark]# ip -6 addr add 2001:db8::1 dev dummy0 [root@opy mark]# ip -6 addr show dev dummy0 9: dummy0: mtu 1500 state UNKNOWN qlen 1000 inet6 2001:db8::1/128 scope global valid_lft forever preferred_lft forever inet6 fe80::c087:1cff:fe7a:413c/64 scope link valid_lft forever preferred_lft forever [root@opy mark]# I suppose under Linux, packets are sourced from /128s ;-) Regards, Mark. From nobody Wed Mar 8 02:15:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470A012946C for ; Wed, 8 Mar 2017 02:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 82Rzti_VqRCY for ; Wed, 8 Mar 2017 02:15:41 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id F2B541293D8 for ; Wed, 8 Mar 2017 02:15:40 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 08 Mar 2017 10:15:40 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 15094D788F; Wed, 8 Mar 2017 02:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=SlcaCNedBmgxbUtUzz7gFzBESww=; b= AZSQ91el0VYCJje/mxcsevn9uTSKtL9sTIaxjhIZ8+hQnlRY8F2KSUmb+x+WPjlj dxJN/Vr8VeD2qcbKt4RFPJtgLRX1dH5f+uhRSmfG/P22qA9NdcyZCCmv2bkGU064 N1Xut2enfKCyJ6lHu6UwSbhWWVWGjs6n9fV0443CIeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=VZN3gqywc/i+O7On4EBrhuB F7b1XGcwbm3T2MTZOAXji84wv8mvnsRORcIvDoQmKZm6uznC8MzjMKDUuu7flWJN rL2yN5tfFHBb3ay6SYKLYAfXMNnezkTValw1vpwGfa9YQ0UUoeeC0yNizYlBe0qu uQF8RX1GmUVRzW+ZTSAE= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 9C9ABD788E; Wed, 8 Mar 2017 02:15:39 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B7F689856C55; Wed, 8 Mar 2017 11:15:37 +0100 (CET) From: otroan@employees.org Message-Id: <0E14B2F8-4918-4AA0-837F-4D120FAEF17D@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_0B1FD658-D4FC-4C69-ADAC-B4BB83F3D643"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9 Date: Wed, 8 Mar 2017 11:15:36 +0100 In-Reply-To: To: Mark Smith References: <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Alexandre Petrescu , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 10:15:44 -0000 --Apple-Mail=_0B1FD658-D4FC-4C69-ADAC-B4BB83F3D643 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, [...] >> E.g. you wouldn't say the packet was sent from the source FE80::/128. >=20 > You wouldn't say it, but you could say it, it would be correct. >=20 > Here's an example of their equivalence. >=20 > I assign an IPv6 address to an interface under Linux, and it shows it > as a /128 prefix. >=20 > [root@opy mark]# ip -6 addr add 2001:db8::1 dev dummy0 > [root@opy mark]# ip -6 addr show dev dummy0 > 9: dummy0: mtu 1500 state UNKNOWN qlen = 1000 > inet6 2001:db8::1/128 scope global > valid_lft forever preferred_lft forever > inet6 fe80::c087:1cff:fe7a:413c/64 scope link > valid_lft forever preferred_lft forever > [root@opy mark]# >=20 > I suppose under Linux, packets are sourced from /128s ;-) Many implementations conflate configuring an address and configuring an = onlink prefix / connected route. That doesn't mean they are the same thing. Aren't we already far out into the weeds with this discussion? Ole --Apple-Mail=_0B1FD658-D4FC-4C69-ADAC-B4BB83F3D643 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYv9nJAAoJEL7aWKiYQt92BAgQAKmntF4Vyue0ugUCsPkPHXGH wm2jwAHC5/n6QQNXKuGYFiQRDF4dWY8jFaJLpa0EA30O5goOLntk2Lxnn17k3rSS K5RcuXCh8Rk5KOX/1EJRcGYrKNwsOK0DcKEIJ7+w19l0AFliCOOv2+nCvXgiMKyS RtEZ/YPppeEbhAKWIAmub6O3NdNlEtcnX1TcfNTYOfl0i3i0Tex697aTJr9m9R1Q tAzplgoTRVWwXw/hSjJ74Ekh6u8y0PzATCMNIfb8CLiRs1Jkd5mb19BoQl5A1M91 QQGsdagohSOH5gaJimjElcg8kDo4yxxlj40eF5Sp/8d3MkxZ6zXu5WUNtPcYDYkL /WN1gopcVM/hkjEPOqoRyvqfl5BBc5/77god2iRcPn+JHeuLGl5+TFmTM0K6xi+v GaYxSuEUmqKN3B2xVmWX7JidICXGd6BD+BsceR4TohB9yr69Rl2Hapc3VXkUm6o4 kwb6DMDvszZxJYlI0KNCczGWybtpe2pdn/Jk8LwGztiT62gAs3Ib4iMbwP+htRK4 fvACTwBdt/5gQHGDBqvaZTNDfrIXIZbsABot5qULvUah+S2ciOGyeMHm5y/sHlru f4HbHHn8iAF7a+G1ZxMXbgpQ9w5nR1z3o1iS5yVADcox2LCb6X1ji0iU7Gwl6dgI QYWxj7FOhgPUsxUCP4Br =Ufv+ -----END PGP SIGNATURE----- --Apple-Mail=_0B1FD658-D4FC-4C69-ADAC-B4BB83F3D643-- From nobody Wed Mar 8 03:03:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0D7129585 for ; Wed, 8 Mar 2017 03:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 LvJkEDQu8_dq for ; Wed, 8 Mar 2017 03:03:49 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D5612955F for ; Wed, 8 Mar 2017 03:03:48 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v28B3iDd018985; Wed, 8 Mar 2017 12:03:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 62DD1206816; Wed, 8 Mar 2017 12:03: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 53AB3203124; Wed, 8 Mar 2017 12:03:44 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v28B3iji031456; Wed, 8 Mar 2017 12:03:44 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9 To: otroan@employees.org, Mark Smith References: <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> <0E14B2F8-4918-4AA0-837F-4D120FAEF17D@employees.org> From: Alexandre Petrescu Message-ID: <425ae5ef-5cfe-5787-c6e5-9c73f09cfb20@gmail.com> Date: Wed, 8 Mar 2017 12:03:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <0E14B2F8-4918-4AA0-837F-4D120FAEF17D@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 11:03:50 -0000 Le 08/03/2017 à 11:15, otroan@employees.org a écrit : > Mark, > > [...] > >>> E.g. you wouldn't say the packet was sent from the source FE80::/128. >> >> You wouldn't say it, but you could say it, it would be correct. >> >> Here's an example of their equivalence. >> >> I assign an IPv6 address to an interface under Linux, and it shows it >> as a /128 prefix. >> >> [root@opy mark]# ip -6 addr add 2001:db8::1 dev dummy0 >> [root@opy mark]# ip -6 addr show dev dummy0 >> 9: dummy0: mtu 1500 state UNKNOWN qlen 1000 >> inet6 2001:db8::1/128 scope global >> valid_lft forever preferred_lft forever >> inet6 fe80::c087:1cff:fe7a:413c/64 scope link >> valid_lft forever preferred_lft forever >> [root@opy mark]# >> >> I suppose under Linux, packets are sourced from /128s ;-) > > Many implementations conflate configuring an address and configuring an onlink prefix / connected route. > That doesn't mean they are the same thing. > > Aren't we already far out into the weeds with this discussion? The discussion went far indeed. If I were to conclude: RFC4291bis should clear the current confusion between FE80::/9, FE80::/10 and FE80::/64. Keep FE80::/10 only, add statement that is not a /9 (despite its last set bit at position number 9), and remove FE80::/64 throughout. RFC4862 should no longer say "prefix FE80::" because it is confusing. There is more to be fixed there, but separate discussion. It would be good too if RFC4291bis said in a small place that "FEBF::1 is a Link-local address too". The fact that everybody always says "an FE80 is an LL", or "an LL is an FE80" does not mean FEBF::1 is not an LL too. And that has deep consequences to address plans. Alex > > Ole > From nobody Wed Mar 8 03:18:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83AF129556 for ; Wed, 8 Mar 2017 03:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 LN-CzdASboGK for ; Wed, 8 Mar 2017 03:18:32 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 23CF6129504 for ; Wed, 8 Mar 2017 03:18:32 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 08 Mar 2017 11:18:31 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 853C2D788B; Wed, 8 Mar 2017 03:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=rRjReI6CXRPjLmq5RPPsICDzjNY=; b= nMM5XybmE70YHljmZK9msIETOL6wGEz/78npJKjPU+Q2IucBHL1DjRHFTHRQO+ZX a4+Zm0r63cWXNGjp5rPFzSlZsm7XnNhHbphKwwGyfWJawWs+Krsacfye59+18SEg B17iTM2AT5bdZ6CaYIS6A3G8xPx5qnCnDuiGn/AFEic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=d6WawdsZ8zpTaG6DD3DWdiO 2kFsEhASW3W+CNOOWB2l5m5saOIBCF9wVPoWp4wD21VNUGaVnJ6ZhdDkKW/l2PdI HVXRe1BXc8KwVqsb5oi3Dy7cxObTaPOVIyHP1h2kuTcYFGLUTjS6NmDry+oBDd5s E8t2R6pVhKrAo1dVfy3w= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 109F5D788A; Wed, 8 Mar 2017 03:18:31 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 211479869539; Wed, 8 Mar 2017 12:18:29 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EB6787C4-4268-4FAF-999C-184339CE7FC6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80:: means FE80::/9 Date: Wed, 8 Mar 2017 12:18:28 +0100 In-Reply-To: <425ae5ef-5cfe-5787-c6e5-9c73f09cfb20@gmail.com> To: Alexandre Petrescu References: <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> <0E14B2F8-4918-4AA0-837F-4D120FAEF17D@employees.org> <425ae5ef-5cfe-5787-c6e5-9c73f09cfb20@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 11:18:34 -0000 --Apple-Mail=_EB6787C4-4268-4FAF-999C-184339CE7FC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Aren't we already far out into the weeds with this discussion? >=20 > The discussion went far indeed. >=20 > If I were to conclude: You probably shouldn't. > RFC4291bis should clear the current confusion between FE80::/9, = FE80::/10 and FE80::/64. Keep FE80::/10 only, add statement that is not = a /9 (despite its last set bit at position number 9), and remove = FE80::/64 throughout. No. I don't think anyone apart from you have been confused. > RFC4862 should no longer say "prefix FE80::" because it is confusing. = There is more to be fixed there, but separate discussion. Agree. > It would be good too if RFC4291bis said in a small place that "FEBF::1 = is a Link-local address too". No. It says the link-local prefix is FE80/10 + zeroes + interface-id. If you have a 118 bit long IID you can create the above link-local = address, but that really does not have to be stated. > The fact that everybody always says "an FE80 is an LL", or "an LL is = an FE80" does not mean FEBF::1 is not an LL too. And that has deep = consequences to address plans. No it hasn't. Ole --Apple-Mail=_EB6787C4-4268-4FAF-999C-184339CE7FC6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYv+iEAAoJEL7aWKiYQt928ycP+QFCzDHk879LHK1wfq7zj56G Q2SQH6ri59azH0aGmRT2q1txjO3Hxp9nMzeAlrezahe7f04MLPFAOvybKqeOsjMl J8vgPltBBal/zMVH3rLev294he1D+/NG20eszL5o0y3Laf+ib8BTfk9FlTAHnl7H GDayJ1APwz0sSsXgaL2klTpAb08m5vNQNNOOdCsOQBvvHoNRbzHsW+2zTtCy9uvT i39s00/Sq16jxB/+motFBwJdrEszU5qm+f1wROKtHT7NySsU96s2F34oITatFbHg 0bOBKMNbOAj1lC7U06QPse6JrrAigL3gyUveyMQ0o6hCxK0eUFX1wGmmoX0IkVzK KMr+J2sd/QALSObfG444SWslVoWdnSkbc9vjHtLePyM6zynOKGCLjZ1qSGwNYtMw lU+TW07a8bjv8f2TXAwbKooCGu7VSMpnYJEppoqq/UqKyBjuStlytF7oPPUB81tz Ck8AbUnMy6GYrxkRkzQUILYrRIX4GLfAM85vRkV2HvRa8ZNpVe9DffAHPTLRVjzY wlJVtwGVLnF8AIPNpxOvJvPg6ywxtrGgu4OJyzn5jfzaA1mliMqyDr74rQvMCxuB Scb9H3OljGEdAx7rCO1GouI4xAy4R7GAtNyI7sYj1GCIpqlZk6o8XX84cMJKs4ki HnjWB+5owcvkgHNPD6BP =Ppnn -----END PGP SIGNATURE----- --Apple-Mail=_EB6787C4-4268-4FAF-999C-184339CE7FC6-- From nobody Wed Mar 8 03:27:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1BE129455 for ; Wed, 8 Mar 2017 03:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 r007PB_hR3ga for ; Wed, 8 Mar 2017 03:27:50 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66DA5129421 for ; Wed, 8 Mar 2017 03:27:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v28BRlGU027815; Wed, 8 Mar 2017 12:27:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 180BE206833; Wed, 8 Mar 2017 12:27:47 +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 07BA22029D0; Wed, 8 Mar 2017 12:27:47 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v28BRjOL016041; Wed, 8 Mar 2017 12:27:46 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80::/10 and IID length To: otroan@employees.org References: <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> <0E14B2F8-4918-4AA0-837F-4D120FAEF17D@employees.org> <425ae5ef-5cfe-5787-c6e5-9c73f09cfb20@gmail.com> From: Alexandre Petrescu Message-ID: <3a1c572e-4730-1071-27b8-57999aecee5c@gmail.com> Date: Wed, 8 Mar 2017 12:27:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 11:27:52 -0000 Le 08/03/2017 à 12:18, otroan@employees.org a écrit : [...] >> It would be good too if RFC4291bis said in a small place that >> "FEBF::1 is a Link-local address too". > > No. It says the link-local prefix is FE80/10 + zeroes + > interface-id. If you have a 118 bit long IID you can create the above > link-local address, but that really does not have to be stated. But to let that happen, it should also refrain from picturing or writing that IIDs must be of 64bit length. If it needs to give examples it should rather use "e.g. /118". >> The fact that everybody always says "an FE80 is an LL", or "an LL >> is an FE80" does not mean FEBF::1 is not an LL too. And that has >> deep consequences to address plans. > > No it hasn't. Well... Alex From nobody Wed Mar 8 03:35:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665B9129421 for ; Wed, 8 Mar 2017 03:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 JXilR8nQxm50 for ; Wed, 8 Mar 2017 03:35:14 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF51129434 for ; Wed, 8 Mar 2017 03:35:14 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 08 Mar 2017 11:35:14 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BD9AAD788D; Wed, 8 Mar 2017 03:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=a0/5HVGtq3NT494Z924Od04k35Q=; b= Yr41jPiQH7dXdFix6KPdsPjS/ikwQSCoRi3lT3wCw9mMbPbSVVdxFcxitn/m0+3z FuWjadpi2///15IG3GvXadxSwvzqcnWya0W5hjvLVylHKzoThuOMfhrvdM15hjXi n/Fa4MvLBp9syXAe10aXUcqq0HROsHcTSOptMu5UQXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=pcbdBLIZVF8L+Plqicj65KB n3/K7RG/46/mbhxmBgBxfzFxogn/nX3G69/nv3bYTk7pbpO844iYWMSObdspeQcE vhkbvP1bKBsKsD8O+MktW4+nkCnG4vwbH7jmm6l0TK9xdmfnAgyueiEiuIiH4tpV d6RpX14KZJ5yl+NqHfsU= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 4F7CAD788B; Wed, 8 Mar 2017 03:35:13 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6AFDE986EAE9; Wed, 8 Mar 2017 12:35:11 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5AD40B48-92C8-428D-928D-0123B60549CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80::/10 and IID length Date: Wed, 8 Mar 2017 12:35:10 +0100 In-Reply-To: <3a1c572e-4730-1071-27b8-57999aecee5c@gmail.com> To: Alexandre Petrescu References: <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> <0E14B2F8-4918-4AA0-837F-4D120FAEF17D@employees.org> <425ae5ef-5cfe-5787-c6e5-9c73f09cfb20@gmail.com> <3a1c572e-4730-1071-27b8-57999aecee5c@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 11:35:16 -0000 --Apple-Mail=_5AD40B48-92C8-428D-928D-0123B60549CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> It would be good too if RFC4291bis said in a small place that >>> "FEBF::1 is a Link-local address too". >>=20 >> No. It says the link-local prefix is FE80/10 + zeroes + >> interface-id. If you have a 118 bit long IID you can create the above >> link-local address, but that really does not have to be stated. >=20 > But to let that happen, it should also refrain from picturing or = writing that IIDs must be of 64bit length. If it needs to give examples = it should rather use "e.g. /118". Write an IPv6 over foo document with 118 bit IIDs. There is a good reason the prefix-length of the link-local address space = is explicitly specified. If all nodes on a link didn't agree on this value, you would get into = problems with protocols using the link-local address. E.g. address resolution for the default router, or sending packets from = DHCP server to host... >>> The fact that everybody always says "an FE80 is an LL", or "an LL >>> is an FE80" does not mean FEBF::1 is not an LL too. And that has >>> deep consequences to address plans. >>=20 >> No it hasn't. >=20 > Well... Ole --Apple-Mail=_5AD40B48-92C8-428D-928D-0123B60549CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYv+xvAAoJEL7aWKiYQt92l8YQAImcWPBKn9v5iqy/E2VUet7b 9X6CQUYG9B1YEkfzqCqpp7y2jCVCYjtFxS//HayHITNEDDGj+fglZ727+Y9NXQZz ewVKHOASGnreYmdi6Ss/LYy+2lQChQZ5Q96krQMnc6SLnH5fSkG4EtxtieQKDOnj +VEqW5h7HqQGzKaPq6WQRYEXcTQ9ZS1zFjUHncnjrCXQy5VNyFG1zlbzBicbonTH JELWN97ivBl4u0uKUkcUlCd/m+ZgC3F3nE/hCvbYZ92ogRdCWSbiQqSUCtzAVAJW SCIgp2IfEKNa3K87xfvr8XbMqCwxRA2IBoMAsPY8sWkpv/G+6ph+xZy1+8OIfK3C mkPxTgAB0RzJ6XGDm6kdgdFnPeKLRHc9i74KQaQTj1U2eG4ky4V09C4CxBW0CHf5 +Dq855Lh1tjiitDO5yi+tcnp5gKY6drUh2ty47Ou+IYkS2vHCMmeVGuS7Wdc78Ma iEpAYrqrTuk0lElOO7Vxn4VwwEXBlODCR/fjCgMP2a/KZuOQIPJ1GyjwfCZDl5T1 BwPPPO8BGqa6RG6s5S1gF7g+OWmrNMbU3JH1Fu0VpigzuKDmIa2AQf4LGx+ahMkw EK2vA0RxNcYYrkZif3Js5/nRM/jzUZncGnNg015UwIK2dqRviTLzNrJjUn3MiRn2 GQNbf10loT7pzkqrFWsQ =TQeg -----END PGP SIGNATURE----- --Apple-Mail=_5AD40B48-92C8-428D-928D-0123B60549CE-- From nobody Wed Mar 8 04:13:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69139129610 for ; Wed, 8 Mar 2017 04:13:52 -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=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RHPHhBk-XGe0 for ; Wed, 8 Mar 2017 04:13:51 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D6712960B for ; Wed, 8 Mar 2017 04:13:51 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 72so35693466uaf.3 for ; Wed, 08 Mar 2017 04:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Pvawf/6EkNpdkwAiXPTRAcYheWIBcwDscVFLx7JDFdo=; b=MKhtI5CIEUednNUsvDFT0bwQrjavOb9TQdQkkWyiUK4RPnwibvKTKmHRyxwes57vrR xGsdnQSVCBkfEwldHEzKr2Q2blWdE9OibJO6e/0zpEgM+IiYNUsby4UNjk82+7zV3IGQ H6QosTJP/0WQva6s+TQeNFYitGxjHFLNS203AWfKewLjj4878c1joGhrughV+JcqziYa UO98xzONAi+EOp0kRmhB/vUF7Ci78ZvuseqXGBxKTjDZvruuJhe2ahlqcrfukll0BCN3 DFCCoV7lbhs/KLhMIg8xpbq9DBfN57i6KXnMwPp+6n0zrnWFFOTmtyOL+KAsAtD+Rjra izpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Pvawf/6EkNpdkwAiXPTRAcYheWIBcwDscVFLx7JDFdo=; b=BIanxaPqHQVDsXTSetR7L/ZY77C98eYXlpusGYMgqH4B+EcBhbvijPB1l+p/ltARP5 FzOKtLq0Z3BteGPWkbqHPQfLf4BNwQszmHQNIdEYcI5ZNNjoKj6ClMEiqQh8GIFnvhs3 z5K75Uvc2uQXL/pWAQIFUeK/n4Xia0JSquoxmKCbXLQSq3x1J8AS0tLHB+IX4jSl33yM FgoMOyjHpkCze2ynh54/ulVsz/tp6Y1+g1Ur3HDxPYc9+sGsqDQsS+oC+z7XnrYeeDpJ x9FqHO+LGML14w4Unq5J4LC81buLvxPCz+e910UKfov2dSrOgMQ3+cx8Y0/J6NqFEFTl Zdew== X-Gm-Message-State: AMke39lzJ5ZV9lUgQcBxW5mYRkl+tXl/As9HVMIVDxXrOUSmD5m88kqYTzJmo7nOiIjw2MRXi2liq3hxcbqlNg== X-Received: by 10.176.74.86 with SMTP id r22mr3021492uae.18.1488975230118; Wed, 08 Mar 2017 04:13:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.144 with HTTP; Wed, 8 Mar 2017 04:13:19 -0800 (PST) In-Reply-To: References: From: Mark Smith Date: Wed, 8 Mar 2017 23:13:19 +1100 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 12:13:52 -0000 On 7 Mar. 2017 7:47 am, "Alexandre Petrescu" wrote: agreed with some of the things that I cut but I have one question. Le 06/03/2017 =C3=A0 19:46, Lorenzo Colitti a =C3=A9crit : > > If we allow the boundary to change, there is a near certainty that > too-small subnets *will* be configured in some places, >and is IETF a place to make recommendations of making big or small > subnets? Isnt it for the RIRs to make such recommendations? Protocol designers have to make addressing design decisions, such as the structure of addresses and special address value semantics. If they didn't, then it would only be possible to have a single forwarding method and no other semantics embedded in addresses for the entire address space. For example, if the entire address space is chosen to be destination based unicast addresses, because only a single choice can be made, there will be no possibility of any multicast forwarding, or a special purpose loopback address or prefix. It is also useful if they choose general defaults, so that things can work without significant or ideally any configuration. Imagine the situation of buying a car, and not being able to drive it, because none of its tunable parameters had been set to reasonable defaults. Mechanics wouldn't have a problem, and may enjoy the experience of setting all the parameters to make the car work. The rest of wouldn't find buying a car an easy experience at all. Mechanics would lobby against making cars (literally) turn-key, because they would be making money from setting all the parameters. Regards, Mark. From nobody Wed Mar 8 06:24:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84ECF1296A9 for ; Wed, 8 Mar 2017 06:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 c0VT4Ci2sdkP for ; Wed, 8 Mar 2017 06:23:58 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3D8129637 for ; Wed, 8 Mar 2017 06:23:58 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v28ENsJu003402; Wed, 8 Mar 2017 15:23:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 217FF206A6E; Wed, 8 Mar 2017 15:23:54 +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 12DD6200B51; Wed, 8 Mar 2017 15:23:54 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v28ENraC026074; Wed, 8 Mar 2017 15:23:53 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80::/10 and IID length To: otroan@employees.org References: <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> <0E14B2F8-4918-4AA0-837F-4D120FAEF17D@employees.org> <425ae5ef-5cfe-5787-c6e5-9c73f09cfb20@gmail.com> <3a1c572e-4730-1071-27b8-57999aecee5c@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 8 Mar 2017 15:23:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:23:59 -0000 Le 08/03/2017 à 12:35, otroan@employees.org a écrit : >>>> It would be good too if RFC4291bis said in a small place that >>>> "FEBF::1 is a Link-local address too". >>> >>> No. It says the link-local prefix is FE80/10 + zeroes + >>> interface-id. If you have a 118 bit long IID you can create the >>> above link-local address, but that really does not have to be >>> stated. >> >> But to let that happen, it should also refrain from picturing or >> writing that IIDs must be of 64bit length. If it needs to give >> examples it should rather use "e.g. /118". > > Write an IPv6 over foo document with 118 bit IIDs. Invitation considered. > There is a good reason the prefix-length of the link-local address > space is explicitly specified. Well, I think there is no such reason. > If all nodes on a link didn't agree on this value, you would get into > problems with protocols using the link-local address. Well, I dont think so. > E.g. address resolution for the default router, Well, address resolution: the default router sends NA including its source address. It does not include a plen. If the Host does not want to wait for the NA it will send an NS; this NS does not include a plen either. I dont know where do you see the need to agree on a plen for the LL addresses? Can I know? > or sending packets from DHCP server to host... Well... it's the same: NS and NA are needed, and these dont use a plen. Besides, LL addresses are only valid on a link; so there is no need to perform some matching in the tables to identify whether should go to rt table or to neighbor cache (which would need plen, or otherwise exact match). Alex >>>> The fact that everybody always says "an FE80 is an LL", or "an >>>> LL is an FE80" does not mean FEBF::1 is not an LL too. And >>>> that has deep consequences to address plans. >>> >>> No it hasn't. >> >> Well... > > Ole > From nobody Wed Mar 8 06:34:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C651296BF for ; Wed, 8 Mar 2017 06:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 jcwklgK5RhaV for ; Wed, 8 Mar 2017 06:34:10 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFA61296C1 for ; Wed, 8 Mar 2017 06:34:09 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 08 Mar 2017 14:34:09 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 9DE5FD788D; Wed, 8 Mar 2017 06:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=6X8XSpKmN+LIxISQd3O+78nl/WU=; b= clrr4Qv8a+Cpr/7tdmpbCZo+D7UGX5jVtMGn+aLCNljoHKc0m2GK/JWGHLzXcVDf Z58CmsRgaRqBhNxAvSest8xAWiVFAUKr6PbNbbv5sSav1fuzfqhjF+0qY63+5GkY S+r2eP33QzJn8oFWU+WrMyw+DBn7DgheHQ8z07wRYm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=FOUqPtMFie0I5cfMBPfCHbY ierCnvMPifdVOHOKTUbEzBIMSFZd9VJZX/f0Ca1JnBTUUoEGaor0+ccyKWjz2m3u UTHPg+uTW6bHJBf1zDNMvMKkmoptWrt+0y4m10nPr357v1uEeshoe64cY4hbsStf k8XWoo9q2+AZDVVItnQ0= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 28D1AD788A; Wed, 8 Mar 2017 06:34:08 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3269998A480E; Wed, 8 Mar 2017 15:34:06 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5D04682F-ACE3-4D0D-9347-32F62D8382EB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80::/10 and IID length Date: Wed, 8 Mar 2017 15:34:05 +0100 In-Reply-To: To: Alexandre Petrescu References: <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> <0E14B2F8-4918-4AA0-837F-4D120FAEF17D@employees.org> <425ae5ef-5cfe-5787-c6e5-9c73f09cfb20@gmail.com> <3a1c572e-4730-1071-27b8-57999aecee5c@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:34:11 -0000 --Apple-Mail=_5D04682F-ACE3-4D0D-9347-32F62D8382EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alex, >>>>> It would be good too if RFC4291bis said in a small place that >>>>> "FEBF::1 is a Link-local address too". >>>>=20 >>>> No. It says the link-local prefix is FE80/10 + zeroes + >>>> interface-id. If you have a 118 bit long IID you can create the >>>> above link-local address, but that really does not have to be >>>> stated. >>>=20 >>> But to let that happen, it should also refrain from picturing or >>> writing that IIDs must be of 64bit length. If it needs to give >>> examples it should rather use "e.g. /118". >>=20 >> Write an IPv6 over foo document with 118 bit IIDs. >=20 > Invitation considered. >=20 >> There is a good reason the prefix-length of the link-local address >> space is explicitly specified. >=20 > Well, I think there is no such reason. >=20 >> If all nodes on a link didn't agree on this value, you would get into >> problems with protocols using the link-local address. >=20 > Well, I dont think so. >=20 >> E.g. address resolution for the default router, >=20 > Well, address resolution: the default router sends NA including its = source address. It does not include a plen. >=20 > If the Host does not want to wait for the NA it will send an NS; this = NS > does not include a plen either. >=20 > I dont know where do you see the need to agree on a plen for the LL > addresses? Can I know? https://tools.ietf.org/html/rfc4861#section-5.2 Has a good introduction to the topic. >> or sending packets from DHCP server to host... >=20 > Well... it's the same: NS and NA are needed, and these dont use a = plen. >=20 > Besides, LL addresses are only valid on a link; so there is no need to = perform some matching in the tables to identify whether should go to rt = table or to neighbor cache (which would need plen, or otherwise exact = match). on-link determination also applies to link-local addresses. Are you by any chance talking about how you _would_ have liked the IPv6 = specifications to be, as opposed to how they actually are? Ole --Apple-Mail=_5D04682F-ACE3-4D0D-9347-32F62D8382EB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwBZeAAoJEL7aWKiYQt92Hc8QAL22AhTs48qlg3Asup3dPU7l NuYtwY2uO34Gptfqkk5MGVlok4e6Yp+U19crifNaQUW5A/aVkHuZlsQLZj+D+mbG UuB++Rq8el3h4bAxbH3YBzjt15FSpmMzjUT5WX/hJHgleQnpoLKXqZoxOZmKtCfU W2lX70GSI7/4qdRUVW0nHhJXiEH3IbqZ5uSwGeWhsAIjY8JC2O3Bo59hHaP9/P2/ XDFssv8Rhl9E7xnbdtWp+tuJpyhvHv1IACyNUGYUdv3V3uY2MHHx7MLIn2Oxiv4W X/m+hh2S696A/UJLi44oCk/RVRk+EnDuvziVAFY/QHi4dvmK8RylAeYf1f3Qm+AJ J+HtLnpEBlqZF3V+kbF3cMyDL/T1Yl2UNWtf1GyYdDH/VnQMW9G3D/u92c5uObP3 5ozt+KYyPm0BmTBb652JHh0ZFZ++61vnuxOZqJ+mNYD9iFlJXlrVoKJv44xBSZ9B iMREJ4fHeUizXdR9cBcTf235dXAiV8I1qu+Fx1+o9+3EH27o3KWt4vUHn2KqGviw G1/XXR19pFByUTIq27+aRy7eDGRz0csyL5crDae8ORU2qVuShfE1a0kDv7Nra4UM Ad8BytfJuqxkV++TqzCFhD2xTp5q8D5Y+XKIe+w202tgRjgSCDVs8tI6tFyCyRPE OpV8T6O9MG7/Qnec1RDV =vs+b -----END PGP SIGNATURE----- --Apple-Mail=_5D04682F-ACE3-4D0D-9347-32F62D8382EB-- From nobody Wed Mar 8 07:45:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B09012966C for ; Wed, 8 Mar 2017 07:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 onwkOapRhdrW for ; Wed, 8 Mar 2017 07:45:54 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759BF1296E8 for ; Wed, 8 Mar 2017 07:45:54 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v28FjnAg007279; Wed, 8 Mar 2017 16:45:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2E8E7206D2E; Wed, 8 Mar 2017 16:45:49 +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 1F67B206D36; Wed, 8 Mar 2017 16:45:49 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v28FjmiX023286; Wed, 8 Mar 2017 16:45:49 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - FE80::/10 and IID length To: otroan@employees.org References: <7A10E8D9-02F4-4D1C-B422-86ACCAABCB38@steffann.nl> <1F674D50-1C89-444C-A617-C528951F80EC@steffann.nl> <6f2b4f35-8501-f9d8-e2f6-9e545419fb76@gmail.com> <224F03DD-D876-4288-B48D-04D997ACBE76@employees.org> <0E14B2F8-4918-4AA0-837F-4D120FAEF17D@employees.org> <425ae5ef-5cfe-5787-c6e5-9c73f09cfb20@gmail.com> <3a1c572e-4730-1071-27b8-57999aecee5c@gmail.com> From: Alexandre Petrescu Message-ID: <2b92329c-df1b-9a9f-4b72-e96a247c026c@gmail.com> Date: Wed, 8 Mar 2017 16:45:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:45:56 -0000 Le 08/03/2017 à 15:34, otroan@employees.org a écrit : [...] >> I dont know where do you see the need to agree on a plen for the LL >> addresses? Can I know? > > https://tools.ietf.org/html/rfc4861#section-5.2 I guess you refer to this part of that section: > The sender performs a longest prefix match against the Prefix List to > determine whether the packet's destination is on- or off-link. With LL addresses the destination is necessarily on-link, so why performing that check? Second, a "fe80::/64" is the same on each interface, so performing that check can not distinguish between interfaces. It could as well be a "fe80::/10." Or maybe you referred to another paragraph that I miss. Yours, Alex From nobody Wed Mar 8 08:42:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4C71295F2 for ; Wed, 8 Mar 2017 08:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 gNCuU4LLHz_W for ; Wed, 8 Mar 2017 08:42:01 -0800 (PST) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1051295C7 for ; Wed, 8 Mar 2017 08:42:01 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 8F2AF9BC for ; Wed, 8 Mar 2017 16:42:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtcdSNs4LKge for ; Wed, 8 Mar 2017 10:42:00 -0600 (CST) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 56952747 for ; Wed, 8 Mar 2017 10:42:00 -0600 (CST) Received: by mail-ua0-f200.google.com with SMTP id 81so56445873ual.3 for ; Wed, 08 Mar 2017 08:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+LO1QVgQlwGZhAsvRLLyyKLu7xVYNuwgMKxp26JWYEQ=; b=ZO+/ACpcKiVycK43KV6usekt3QiF75OqOXzP4R1IKzR/fAWR3Z5tFH1mZIv9kAMmtA 0pq2UZQD5PcCbV6mE2GCRBFLtkVAmuyVJbw8PH9+nX7OhAJSiDXiPYSel480rU79EzLN WGaOXrtUkc9FzeN7ArT9jp+1pbJuR+xznKMG7FswIatqAcpfNghoncguB0n9Zor+VaR3 8WdttIiAq0YQHVjmVU0aTH+MIslzLeV4Fls926DWaBo7OFa3c7OCTDmMXf/vpZ++v5gP HwcmaIA53jVHBbRxwUBn8VTBh945ay4mt4K9HFmPaAqA8FfLE3iEurAyC9fQQaCLtUIC 9xLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+LO1QVgQlwGZhAsvRLLyyKLu7xVYNuwgMKxp26JWYEQ=; b=pagSJMpVwvetg9FbYf9siqdghHikZ182bYaxhGHcvsMAvqnkKVHf4nzNb/I+QLNH7H F1PjkQlms33AMSyxMX46d0p58imL6JKLkqmV/p+ubHEpIZC8mY+0RY9yKbTGx4jGpQou 5b18osN5zJH+3vvmzQBY9mrwuwGYoBEIMWWhoXXO1SaNQjrlZU4l2W1b8ae3br7ITyDb wIPxeJ71TnVkI92mayN1v+RBEXY3EfN7D/iHDqziHShoAsdhgnKg5rqyDtRP5t4tQDcV OtrKYTQ1+q8AhlCmVXHX+UCDCXGDB9YxOJg9wD2wxav9Pj1bYFiYs+ozVz3J1RubHxCT h+7g== X-Gm-Message-State: AMke39n3OItrKILhWp9narCEbUmDBX8afhzwaTCwfCCfcN52ljDUithMdc3ADdwxKcUCWQdYHDaSLVJXw1xMaxNtyulyAiGwBxRxUxaotbZ3IBTnMjLteDxi5e6G6gCJo7p3OSEoYKkwF+mfIrk= X-Received: by 10.31.192.204 with SMTP id q195mr4294727vkf.155.1488991319674; Wed, 08 Mar 2017 08:41:59 -0800 (PST) X-Received: by 10.31.192.204 with SMTP id q195mr4294718vkf.155.1488991319471; Wed, 08 Mar 2017 08:41:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.134.129 with HTTP; Wed, 8 Mar 2017 08:41:58 -0800 (PST) In-Reply-To: References: From: David Farmer Date: Wed, 8 Mar 2017 10:41:58 -0600 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: Mark Smith Content-Type: multipart/alternative; boundary=001a114388ccabd3ab054a3ace8a Archived-At: Cc: Alexandre Petrescu , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:42:02 -0000 --001a114388ccabd3ab054a3ace8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 8, 2017 at 6:13 AM, Mark Smith wrote: > On 7 Mar. 2017 7:47 am, "Alexandre Petrescu" > wrote: > > agreed with some of the things that I cut but I have one question. > > > Le 06/03/2017 =C3=A0 19:46, Lorenzo Colitti a =C3=A9crit : > > > > If we allow the boundary to change, there is a near certainty that > > too-small subnets *will* be configured in some places, > >and is IETF a place to make recommendations of making big or small > > subnets? Isnt it for the RIRs to make such recommendations? > > > Protocol designers have to make addressing design decisions, such as > the structure of addresses and special address value semantics. If > they didn't, then it would only be possible to have a single > forwarding method and no other semantics embedded in addresses for the > entire address space. > > For example, if the entire address space is chosen to be destination > based unicast addresses, because only a single choice can be made, > there will be no possibility of any multicast forwarding, or a special > purpose loopback address or prefix. > > It is also useful if they choose general defaults, so that things can > work without significant or ideally any configuration. > > Imagine the situation of buying a car, and not being able to drive it, > because none of its tunable parameters had been set to reasonable > defaults. Mechanics wouldn't have a problem, and may enjoy the > experience of setting all the parameters to make the car work. The > rest of wouldn't find buying a car an easy experience at all. > Mechanics would lobby against making cars (literally) turn-key, > because they would be making money from setting all the parameters. > Following that analogy, I'd agree that most cars have default parameters and they should, but almost all car actually have parameters, sometime thos parameters are exposed to the most naive users, not just expert users. (e.g. many cars have a Sport/Econo button on the dashboard, and then almost all cars have tunable parameters under the hood). Lorenzo seems to be arguing that all cars must not have any tunable parameters, at least none that are exposed on the dashboard. And I have to disagree. > Regards, > Mark. > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114388ccabd3ab054a3ace8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Wed, Mar 8, 2017 at 6:13 AM, Mark Smith <markzzzsmith@gmail.co= m> wrote:
    alexandre.petrescu@gmai= l.com> wrote:

    agreed with some of the things that I cut but I have one question.


    Le 06/03/2017 =C3=A0 19:46, Lorenzo Colitti a =C3=A9crit :
    >
    > If we allow the boundary to change, there is a near certainty that
    > too-small subnets *will* be configured in some places,
    >and is IETF a place to make recommendations of making big or small
    > subnets?=C2=A0 Isnt it for the RIRs to make such recommendations?


    Protocol designers have to make addressing design decisions, such as
    the structure of addresses and special address value semantics. If
    they didn't, then it would only be possible to have a single
    forwarding method and no other semantics embedded in addresses for the
    entire address space.

    For example, if the entire address space is chosen to be destination
    based unicast addresses, because only a single choice can be made,
    there will be no possibility of any multicast forwarding, or a special
    purpose loopback address or prefix.

    It is also useful if they choose general defaults, so that things can
    work without significant or ideally any configuration.

    Imagine the situation of buying a car, and not being able to drive it,
    because none of its tunable parameters had been set to reasonable
    defaults. Mechanics wouldn't have a problem, and may enjoy the
    experience of setting all the parameters to make the car work. The
    rest of wouldn't find buying a car an easy experience at all.
    Mechanics would lobby against making cars (literally) turn-key,
    because they would be making money from setting all the parameters.

    Following that analogy, I'd agree that mos= t cars have default parameters and they should, but almost all car actually= have parameters, sometime thos parameters are exposed to the most naive us= ers, not just expert users. =C2=A0(e.g. many cars have a Sport/Econo button= on the dashboard, and then almost all cars have tunable parameters under t= he hood).

    Lorenzo seems to be arguing that all car= s must not have any tunable parameters, at least none that are exposed on t= he dashboard.=C2=A0 And I have to disagree. =C2=A0
    =C2=A0
    Regards,
    Mark.

    =C2=A0

    = --
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking & Telecommunication = Services
    Office of Information Technology
    University of Minnesota=C2= =A0=C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-= 626-0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    --001a114388ccabd3ab054a3ace8a-- From nobody Wed Mar 8 12:20:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE511295BE for ; Wed, 8 Mar 2017 12:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 wK4ZiLp-2Hfd for ; Wed, 8 Mar 2017 12:20:41 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB401294FB for ; Wed, 8 Mar 2017 12:20:41 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id 77so17025630pgc.1 for ; Wed, 08 Mar 2017 12:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=96ux6/yHb2C1ltc1qZjZ82wH2wDibNnlcVte8jvrm3I=; b=L3bbP8jIn37QLzARs/7jQaAE+D0g+kRlwpaxxS5waGhkCeVfcjHbKAJRt0mwWnbpK/ umK0cRilUWu8yskpxOugETdYTcrlmoS/NqrCt4VVWsW8zmenWczsIGU6KvQjBHhsD8C5 vGoff2ha8ECP4Ty3C+hlrB+xzdwG4MYcCwxsUd6L/Pcg8kRDlNy+mQhvMJTX9/g2/Npr vsnP+y9UvDrPThrqJNHUVXNwJbAnTqHHczJ4WVaVAQ2snybx4S4CITLuRkIdcdRMG0Id qBBOCWR7G5zQCfwhfkSPxv+KFdSdOVLQ1/UQ/Od2+4Gn+0yh0gzcQmpBWGZLFe6kUD3H nOag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=96ux6/yHb2C1ltc1qZjZ82wH2wDibNnlcVte8jvrm3I=; b=BcXcZmxP3CSE6TMafn3p0JuCwvF6P/hp+vw7j5n28RLU3zGM7fH+FfOucnPNufqpj9 09rsPNL3YmvL5Ez0hvQTnkxCLMWelnK1dPrLkVVzls2tFF8pOr7o4cm8qpZUHleP+Xsb 6KL+NxUPaOxBM8PDphGsz7S4eCo9ZLFAX9H6z9NDKWBf1ey/CAlPC13DCyvkmKbVtp+6 2SZCDBBYPoSkDKD39unAwTn0EhmkFuxINWoNCprI0lfp+hoGfz9aB2DGGxQmWtz32Vxd E/9hU+Gq5FKxq2yAqNQEv/7lR84dPPIWpfIzeGw6bqm+uItqcJK+BnVgF6q2DmttweAv E0VQ== X-Gm-Message-State: AMke39n2Qd4r99YPasqtehIv8dFfRSkov5xM/5KE0mR3MtH2BswuVNBWOwWt31W9KNtst5AK X-Received: by 10.99.4.134 with SMTP id 128mr9203564pge.77.1489004440559; Wed, 08 Mar 2017 12:20:40 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id f21sm7820641pff.48.2017.03.08.12.20.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 12:20:39 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_59C50459-0CB9-4F67-9AF4-B06DE994B3C8" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 Date: Wed, 8 Mar 2017 12:20:38 -0800 References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> To: 6man WG In-Reply-To: <36251EE1-309C-44B5-BEAE-591889492547@employees.org> Message-Id: <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 20:20:42 -0000 --Apple-Mail=_59C50459-0CB9-4F67-9AF4-B06DE994B3C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 7, 2017, at 13:41, otroan@employees.org wrote: > On 7 Mar 2017, at 22:22, james woodyatt wrote: >>=20 >> In summary, there is a deficit of RFC 2119 keyword language here, and = we have to make the case that the standards texts make a sufficiently = strong implicit case rather than an explicit normative requirement. >>=20 >> As explained above, it sure looks to me like a very fair reading of = the implicit requirements language is that LwIP is within the limits of = RFC 4291, RFC 4861 and RFC 4862 when it choose the option of ignoring = PIO elements with invalid prefix length for IID on the underlying link = type. >>=20 >> Yes, the USGv6 and IPv6 Ready Logo tests are well within their rights = to apply additional requirements beyond the IETF standards, but it seems = like a strict interpretation of the standards allow for LwIP to claim = conformance. >>=20 >> How can we counter this argument? >=20 > We're not writing law, we're specifying what it takes to have = implementations of a specification interoperate. I agree, and I contend there's something missing here in what we=E2=80=99v= e said it takes to interoperate. > That implementation would fail to interoperate. As I wrote to the other participants in this exchange off list, I remain = convinced that the interoperability issue here is due to system = administrators ignoring the recommendation in RFC 4862 to always use a = valid Prefix Length for the link type in PIO elements without also = ensuring that all hosts on the link implement behavior that RFC 4861 = implies is OPTIONAL for performing on-link determination. Here I will add that I=E2=80=99m not going to push for changes to LwIP = either locally or upstream until I=E2=80=99m persuaded this = interpretation of the existing text is wrong. --james woodyatt > --Apple-Mail=_59C50459-0CB9-4F67-9AF4-B06DE994B3C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 7, 2017, at 13:41, otroan@employees.org = wrote:
    On 7 Mar 2017, at 22:22, james woodyatt <jhw@google.com> = wrote:

    In summary, there is a deficit of RFC 2119 = keyword language here, and we have to make the case that the standards = texts make a sufficiently strong implicit case rather than an explicit = normative requirement.

    As explained above, = it sure looks to me like a very fair reading of the implicit = requirements language is that LwIP is within the limits of RFC 4291, RFC = 4861 and RFC 4862 when it choose the option of ignoring PIO elements = with invalid prefix length for IID on the underlying link type.

    Yes, the USGv6 and IPv6 Ready Logo tests are = well within their rights to apply additional requirements beyond the = IETF standards, but it seems like a strict interpretation of the = standards allow for LwIP to claim conformance.

    How can we counter this argument?

    We're not writing law, we're = specifying what it takes to have implementations of a specification = interoperate.

    I agree, and I contend there's something missing = here in what we=E2=80=99ve said it takes to interoperate.

    That implementation would fail to = interoperate.

    As I = wrote to the other participants in this exchange off list, I remain = convinced that the interoperability issue here is due to system = administrators ignoring the recommendation in RFC 4862 to always use a = valid Prefix Length for the link type in PIO elements without also = ensuring that all hosts on the link implement behavior that RFC 4861 = implies is OPTIONAL for performing on-link determination.

    Here I will add that I=E2=80=99m not going to push = for changes to LwIP either locally or upstream until I=E2=80=99m = persuaded this interpretation of the existing text is = wrong.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_59C50459-0CB9-4F67-9AF4-B06DE994B3C8-- From nobody Wed Mar 8 13:05:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE521294D4 for ; Wed, 8 Mar 2017 13:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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-USd24EMuWy for ; Wed, 8 Mar 2017 13:04:57 -0800 (PST) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99471295BB for ; Wed, 8 Mar 2017 13:04:57 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 0B3C4525 for ; Wed, 8 Mar 2017 21:04:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_aIGPuF5eSl for ; Wed, 8 Mar 2017 15:04:56 -0600 (CST) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id C6A78E6 for ; Wed, 8 Mar 2017 15:04:56 -0600 (CST) Received: by mail-ua0-f198.google.com with SMTP id w33so70625044uaw.4 for ; Wed, 08 Mar 2017 13:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fKaGS4mX2VYOYOx4WoEOCJT3pyNqT59rYeLmZjr17wc=; b=BieRU1qLehsB7splsnGBe529wLKo/oSl3KJpMPBszv6GwFDk+GkGfflm4wFM+c1GFY LqSHIW4uCQ9D+MJJ1UI7xQVwDxid98HRUbVA7hi0i66WYOV8hV97lQGdOhf8gtF4WyIS CGNIDaFOgu6lfr+EkOXFyr5v4xHiSNHzsbmmWln5snfWWSqTJ/49VfDdpGEmDB+9Nj+Y HUDCj53r8bp4uApzxJ/dP+ZgOB5JwycHtdLzui9G6Hj/O4a3gYHmZrFkQC8FbqgQVnLD T0saemFuSmTl13MXE3U1JIAs0bzdT3YCAJVJEfxvAICv8zQUOvzEcSM2EcJC1c8GJNqJ MR/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fKaGS4mX2VYOYOx4WoEOCJT3pyNqT59rYeLmZjr17wc=; b=umVM6pv6GVfTkRLVVwWMHJ1NmkTROHVR77qhfrGIkgTYRBQp6yP12WavjYaxTBl8pn hrEIqAXagDqNkQ1fql2te6xsBbn/JX8+iG/IQr6U0iFimJNmtcei5y4/m6oyx/mCjPoX hydJYZpq83BAbs2aOHr8+kLQYRdxUdL7Z5Z0bOpyTTyEh3+by6aP2OFpit3eJz3Emb/6 an6oRs4XOxZsoB8/SAV83HrBZBBywEUclgg/iI8v0QisV+DIATulIMD/3E1uOhWN7Mdq og+JTwsv2zVqD0x+y8mk1mQsundebkBUH5uEcz5sQURVVUZRnuJzDqnoZ+7i2UO3CxYU GYOg== X-Gm-Message-State: AMke39mbtJph7wam7j0O90LdW75dE5AL5mUrwHV+2k+4rakw5vUWYv3SOEzkH0PLsobtPWmF0FRv9pU3++9mStsnQCGKvmZUfyJFbAIweOxZUbEB4c5G1l1zee7/TSjpNEIqgG6Dh77PC1OcLsY= X-Received: by 10.176.80.66 with SMTP id z2mr5583436uaz.151.1489007096159; Wed, 08 Mar 2017 13:04:56 -0800 (PST) X-Received: by 10.176.80.66 with SMTP id z2mr5583416uaz.151.1489007095883; Wed, 08 Mar 2017 13:04:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.134.129 with HTTP; Wed, 8 Mar 2017 13:04:54 -0800 (PST) In-Reply-To: <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> From: David Farmer Date: Wed, 8 Mar 2017 15:04:54 -0600 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: james woodyatt Content-Type: multipart/alternative; boundary=94eb2c19233004e28c054a3e7b87 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:04:59 -0000 --94eb2c19233004e28c054a3e7b87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 8, 2017 at 2:20 PM, james woodyatt wrote: > On Mar 7, 2017, at 13:41, otroan@employees.org wrote: > > On 7 Mar 2017, at 22:22, james woodyatt wrote: > > > In summary, there is a deficit of RFC 2119 keyword language here, and we > have to make the case that the standards texts make a sufficiently strong > implicit case rather than an explicit normative requirement. > > As explained above, it sure looks to me like a very fair reading of the > implicit requirements language is that LwIP is within the limits of RFC > 4291, RFC 4861 and RFC 4862 when it choose the option of ignoring PIO > elements with invalid prefix length for IID on the underlying link type. > > Yes, the USGv6 and IPv6 Ready Logo tests are well within their rights to > apply additional requirements beyond the IETF standards, but it seems lik= e > a strict interpretation of the standards allow for LwIP to claim > conformance. > > How can we counter this argument? > > > We're not writing law, we're specifying what it takes to have > implementations of a specification interoperate. > > > I agree, and I contend there's something missing here in what we=E2=80=99= ve said > it takes to interoperate. > > That implementation would fail to interoperate. > > > As I wrote to the other participants in this exchange off list, I remain > convinced that the interoperability issue here is due to system > administrators ignoring the recommendation in RFC 4862 to always use a > valid Prefix Length for the link type in PIO elements without also ensuri= ng > that all hosts on the link implement behavior that RFC 4861 implies is > OPTIONAL for performing on-link determination. > > Here I will add that I=E2=80=99m not going to push for changes to LwIP ei= ther > locally or upstream until I=E2=80=99m persuaded this interpretation of th= e existing > text is wrong. > So one question, where in your mind do the standards say what is a valid prefix for PIO on link? Or the conversely, where does it define invalid prefixes for such? Thanks --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --94eb2c19233004e28c054a3e7b87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On Wed, Mar 8, 2017 at 2:20 PM, james woodyatt <jhw@google.com> wrote:
    On Mar 7, 2017, at 13:41, otroan@employees.org wrote:
    On 7 Mar 2017, at 22:22, james woodyatt <jhw@google.com> wrote:

    In summary, there is a deficit of RFC 2119 keyword language here, a= nd we have to make the case that the standards texts make a sufficiently st= rong implicit case rather than an explicit normative requirement.

    As= explained above, it sure looks to me like a very fair reading of the impli= cit requirements language is that LwIP is within the limits of RFC 4291, RF= C 4861 and RFC 4862 when it choose the option of ignoring PIO elements with= invalid prefix length for IID on the underlying link type.

    Yes, the= USGv6 and IPv6 Ready Logo tests are well within their rights to apply addi= tional requirements beyond the IETF standards, but it seems like a strict i= nterpretation of the standards allow for LwIP to claim conformance.

    = How can we counter this argument?

    We're not writing= law, we're specifying what it takes to have implementations of a speci= fication interoperate.

    I ag= ree, and I contend there's something missing here in what we=E2=80=99ve= said it takes to interoperate.

    That implementation would fail to interoperate.
    <= br>
    As I wrote to the other participants in this exchange off lis= t, I remain convinced that the interoperability issue here is due to system= administrators ignoring the recommendation in RFC 4862 to always use a val= id Prefix Length for the link type in PIO elements without also ensuring th= at all hosts on the link implement behavior that RFC 4861 implies is OPTION= AL for performing on-link determination.

    Here I wi= ll add that I=E2=80=99m not going to push for changes to LwIP either locall= y or upstream until I=E2=80=99m persuaded this interpretation of the existi= ng text is wrong.

    So one questi= on, where in your mind do the standards say what is a valid prefix for PIO = on link? Or the conversely, where does it define invalid prefixes for such?= =C2=A0

    Thanks

    --
    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking &am= p; Telecommunication Services
    Office of Information Technology
    Univer= sity of Minnesota=C2=A0=C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Ce= ll: 612-812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
    --94eb2c19233004e28c054a3e7b87-- From nobody Wed Mar 8 13:55:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3B71296C2 for ; Wed, 8 Mar 2017 13:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 cV6v4Ik2cZAT for ; Wed, 8 Mar 2017 13:54:56 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D75D129672 for ; Wed, 8 Mar 2017 13:54:56 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id 1so89714462qkl.3 for ; Wed, 08 Mar 2017 13:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xe3bP0hwgMpyKgEV9+8pOQusuq+6KXeKd2e+hP/q2sk=; b=MmClP3QgQnE9SPLRQtNqy2rlFPgS7ehxL/SHAFnV7pvosg5Bv7Wz6bd/SZTrGW2lCO RhwH6h0eGE2nXwwNQPtJE36VUzCEJkeC4Z+Qet9sjElJp1spEH+tD+h+rxLK/93uJehK vcGx0CNfLD+8TRzECvIe3JGRbFn4VEgqstmH4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xe3bP0hwgMpyKgEV9+8pOQusuq+6KXeKd2e+hP/q2sk=; b=IZqvfye6TxSMTHm/qqv8wVQJyAKuj0KBq5LJ6/Lr1BO+JzPFN3RodkzZUZmG+haSP1 tvVFkaqrakDC5SDbNgqi7jr9/bDzJL/Njeeg8lWQuLRFsXbeqYopx/UM/rpFeMAlkDXo qGEJAj7WaXjhigGRPYpxliTmjPqkGqxcYih1j9LpblFx/ZeKPzM6C3v1GDL/n6QrgP/C 1HPS0N2OiLbM8zMyTB52Sbm39Mx6PLvOLBeofJ+GaTVAhpjXboHT3Pr55+XmDeMU1kdg W0Hl/gwn1O89qJtgAHl7qGZqiSQyX3c0WiBXoLNruhRvnBu6s8IT8XD5WnaiQ7hvVlsO eTww== X-Gm-Message-State: AMke39k6cN5yEAHoLXFqfHGC0ZsuOTvt4S4FX9pe7TNH4QWuI7sW5Hoq/ylHcBNSDwzjQv+CPIVBVVnZcMikli9j X-Received: by 10.237.36.172 with SMTP id t41mr10204732qtc.142.1489010084912; Wed, 08 Mar 2017 13:54:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Wed, 8 Mar 2017 13:54:43 -0800 (PST) In-Reply-To: <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> From: Timothy Winters Date: Wed, 8 Mar 2017 16:54:43 -0500 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: james woodyatt Content-Type: multipart/alternative; boundary=001a113f386446aa16054a3f2d2f Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:55:00 -0000 --001a113f386446aa16054a3f2d2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, Since this was added in the update from RFC 2461 to 4861 I went to go look for why this was added and found the following thread. Discussion: https://mailarchive.ietf.org/arch/search/?email_list=3Dipv6&q=3DRequirement= +for+64bit+I%2FF+ID&so=3Ddate&gbt=3D1&index=3DrJtLf5Krh0X9vg3vYts_xO1oUCw Final Decision: https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4 This is clearly about the spirit of this clarification, the working group when adding this text wanted to allow prefix lengths much larger then 64 (80 is the example). ~Tim On Wed, Mar 8, 2017 at 3:20 PM, james woodyatt wrote: > On Mar 7, 2017, at 13:41, otroan@employees.org wrote: > > On 7 Mar 2017, at 22:22, james woodyatt wrote: > > > In summary, there is a deficit of RFC 2119 keyword language here, and we > have to make the case that the standards texts make a sufficiently strong > implicit case rather than an explicit normative requirement. > > As explained above, it sure looks to me like a very fair reading of the > implicit requirements language is that LwIP is within the limits of RFC > 4291, RFC 4861 and RFC 4862 when it choose the option of ignoring PIO > elements with invalid prefix length for IID on the underlying link type. > > Yes, the USGv6 and IPv6 Ready Logo tests are well within their rights to > apply additional requirements beyond the IETF standards, but it seems lik= e > a strict interpretation of the standards allow for LwIP to claim > conformance. > > How can we counter this argument? > > > We're not writing law, we're specifying what it takes to have > implementations of a specification interoperate. > > > I agree, and I contend there's something missing here in what we=E2=80=99= ve said > it takes to interoperate. > > That implementation would fail to interoperate. > > > As I wrote to the other participants in this exchange off list, I remain > convinced that the interoperability issue here is due to system > administrators ignoring the recommendation in RFC 4862 to always use a > valid Prefix Length for the link type in PIO elements without also ensuri= ng > that all hosts on the link implement behavior that RFC 4861 implies is > OPTIONAL for performing on-link determination. > > Here I will add that I=E2=80=99m not going to push for changes to LwIP ei= ther > locally or upstream until I=E2=80=99m persuaded this interpretation of th= e existing > text is wrong. > > > --james woodyatt > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a113f386446aa16054a3f2d2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi James,

    Since this was added in the u= pdate from RFC 2461 to 4861 I went to go look for why this was added and fo= und the following thread.

    Discussion:
    https://mailarchive.ietf.org/arch/search/?email_l= ist=3Dipv6&q=3DRequirement+for+64bit+I%2FF+ID&so=3Ddate&gbt=3D1= &index=3DrJtLf5Krh0X9vg3vYts_xO1oUCw

    F= inal Decision:

    This is clear= ly about the spirit of this clarification, the working group when adding th= is text wanted to allow prefix lengths much larger then 64 (80 is the examp= le). =C2=A0

    ~Tim

    On Wed, Mar 8, 2017 at 3:20 PM, james w= oodyatt <jhw@google.com> wrote:
    On Mar 7, 2017, at = 13:41, otroan@emp= loyees.org wrote:
    On 7 Mar 2017, at 22:22, james woodyatt <jhw@google.com> wrote:

    In summary, there is a deficit of RFC 2119 keyword language here, and= we have to make the case that the standards texts make a sufficiently stro= ng implicit case rather than an explicit normative requirement.

    As e= xplained above, it sure looks to me like a very fair reading of the implici= t requirements language is that LwIP is within the limits of RFC 4291, RFC = 4861 and RFC 4862 when it choose the option of ignoring PIO elements with i= nvalid prefix length for IID on the underlying link type.

    Yes, the U= SGv6 and IPv6 Ready Logo tests are well within their rights to apply additi= onal requirements beyond the IETF standards, but it seems like a strict int= erpretation of the standards allow for LwIP to claim conformance.

    Ho= w can we counter this argument?

    We're not writing l= aw, we're specifying what it takes to have implementations of a specifi= cation interoperate.

    I agree, and I contend there's something missing here in what we=E2=80= =99ve said it takes to interoperate.

    That implementation would fail to interoperate.

    As I wrote to the other particip= ants in this exchange off list, I remain convinced that the interoperabilit= y issue here is due to system administrators ignoring the recommendation in= RFC 4862 to always use a valid Prefix Length for the link type in PIO elem= ents without also ensuring that all hosts on the link implement behavior th= at RFC 4861 implies is OPTIONAL for performing on-link determination.
    =

    Here I will add that I=E2=80=99m not going to push for = changes to LwIP either locally or upstream until I=E2=80=99m persuaded this= interpretation of the existing text is wrong.


    --james woodyatt <jhw@google.com>




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




    --
    =

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --001a113f386446aa16054a3f2d2f-- From nobody Wed Mar 8 14:38:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64361294E8 for ; Wed, 8 Mar 2017 14:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 vVn347eHdPUh for ; Wed, 8 Mar 2017 14:38:23 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67001294B2 for ; Wed, 8 Mar 2017 14:38:23 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id j5so20258131pfb.2 for ; Wed, 08 Mar 2017 14:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RteeBaso+lLaXwoaBDZY2/WlL2J75IVEwgVH5n9KOIM=; b=nh7RCG8+nWGblZyyAu91ve6d9QxoIJkaIk76YwXQFd+aDUSyHY9fshVIL6zZlPFAw7 Y27RKRKDV0vu/4vYPXC/5BNmi23DkIKaUhqQu3VKQZy1Bd8npjXwO8iBVaJXVKuSy2z9 MTS+5DDRM2FDj+I2haQBpSj2268eh3b/mnQTdgHlsvgrwdAizjSjWTVvMNzQEm3fTYfw mdHgug0mS327G26dWjWfRAA/m+CV8ENYLkMysSVkjxfCHkL6USTUQRpNxy0KStvERiF+ YMZQMNRn8GM6iNUrSfQ4MMnE3uCkfveeP/XgleLpZHp2wOSw1IHVv7RS+I0g9a4jEQhP trrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RteeBaso+lLaXwoaBDZY2/WlL2J75IVEwgVH5n9KOIM=; b=JiYscOPPN/jl3YjBoAo+IUFcr0qew5ONeYx1g8UbugtFpXc2ASaf/NnjoaIhZilWIG xZ8B9MyNv/7P372+x+CXJ6MtoEua++9BECZ0FqO0PtcB3bQspB77AcZISfMN9VJK08Zs ZXLV7mKbFPmB7tG3nrGDtLKbygK9yOcfuzO/wUi/U1lf+qFD8YLQ6N6KRwGxzrq1C9CI KS3olsB9LNrTZc1w38t7+MrKazADM0Mib5DRpbLalg+jN7Hel9bnZeUzoSGysV7LhKWs C+h8JCxhYMuRoZQ+EVp5wqSmVcX5PdovwYfQm6w+eOO8P5JeogSmv8oiMswJfN6KXMB1 ZN5w== X-Gm-Message-State: AMke39nBCgnmcYYUd4v8QeVuD9qFT4KoTKl4ayfBNwszhsBoJwUY9KnKI4N0j74PemFin5cA X-Received: by 10.84.225.22 with SMTP id t22mr12274076plj.14.1489012703196; Wed, 08 Mar 2017 14:38:23 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id a62sm8070214pgc.60.2017.03.08.14.38.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 14:38:22 -0800 (PST) From: james woodyatt Message-Id: <9E57925B-6E4B-4B0C-8846-E4F8E96CF52C@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F3FBFB44-ECE4-4109-86AC-C64ABB098494" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 Date: Wed, 8 Mar 2017 14:38:21 -0800 In-Reply-To: To: Timothy Winters References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 22:38:26 -0000 --Apple-Mail=_F3FBFB44-ECE4-4109-86AC-C64ABB098494 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 8, 2017, at 13:54, Timothy Winters wrote: >=20 > Since this was added in the update from RFC 2461 to 4861 I went to go = look for why this was added and found the following thread. >=20 > Discussion: > = https://mailarchive.ietf.org/arch/search/?email_list=3Dipv6&q=3DRequiremen= t+for+64bit+I%2FF+ID&so=3Ddate&gbt=3D1&index=3DrJtLf5Krh0X9vg3vYts_xO1oUCw= = = >=20 > Final Decision: > https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4 = >=20 > This is clearly about the spirit of this clarification, the working = group when adding this text wanted to allow prefix lengths much larger = then 64 (80 is the example). I think the most we can say there is that the working group wanted to = reserve power in the future to define new link types (or revise existing = link types) to allow for standard use of an IID length other than 64 = bits (for example 48 bits). There appears to be no evidence in that thread that the working group = wanted to REQUIRE hosts to accept PIO elements for purposes of on-link = determination even when their Prefix Length is invalid for address = configuration on the link type in use. I discussed this in detail in my long previous message reviewing this = text. = > The relevant excerpt of my previous message follows: >> But we=E2=80=99re not done. RFC 4862 continues: >>=20 >> >> It is the responsibility of the system administrator to ensure = that the lengths of prefixes contained in Router Advertisements are = consistent with the length of interface identifiers for that link type. >>=20 >> I do not read this as any requirement on the host implementer to = accommodate system administrators who use Prefix Length values that are = not consistent with the IID length defined for the link type in use. >>=20 >> >> It should be noted, however, that this does not mean the = advertised prefix length is meaningless. >>=20 >> This is informative and helpful, and not normative text. >>=20 >> >> In fact, the advertised length has non-trivial meaning for on-link = determination in [RFC4861] where the sum of the prefix length and the = interface identifier length may not be equal to 128. >>=20 >> Indeed, as I read RFC 4861, this recognizes *explicitly* that hosts = MAY use advertised prefixes with invalid Prefix Length for address = configuration, for example, for the purpose of on-link determination. >>=20 >> >> Thus, it should be safe to validate the advertised prefix length = here, in order to detect and avoid a configuration error specifying an = invalid prefix length in the context of address autoconfiguration. >>=20 >> This is not in conflict with the observation of RFC 4861 that = processing Prefix Lengths for on-link determination that are invalid for = address configuration is not REQUIRED and merely OPTIONAL.=20 >>=20 >> >> Note that a future revision of the address architecture [RFC4291] = and a future link-type-specific document, which will still be consistent = with each other, could potentially allow for an interface identifier of = length other than the value defined in the current documents. Thus, an = implementation should not assume a particular constant. Rather, it = should expect any lengths of interface identifiers. >>=20 >> As I read this excerpt, this is RFC 4862 expressly recognizing that = future standards action could introduce new valid IID lengths for = address configuration other than 64 bits. This hasn=E2=80=99t happened = yet. (And there is still some controversy about whether RFC 4291 should = not be revised unless it is changed to do so.) In a forthcoming message, I will propose text for inclusion in = I-D.ietf-6man-rfc4291bis with the hope that it may help clarify this = matter further. --james woodyatt > --Apple-Mail=_F3FBFB44-ECE4-4109-86AC-C64ABB098494 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 8, 2017, at 13:54, Timothy Winters <twinters@iol.unh.edu> wrote:

    Since this was added in the update from RFC 2461 to 4861 I = went to go look for why this was added and found the following = thread.

    Discussion:
    https://mailarchive.ietf.org/arch/search/?email_list=3Dipv6&= ;q=3DRequirement+for+64bit+I%2FF+ID&so=3Ddate&gbt=3D1&index=3D= rJtLf5Krh0X9vg3vYts_xO1oUCw

    Final Decision:
    https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAI= k4yeyK4

    This is clearly about the spirit of this clarification, the = working group when adding this text wanted to allow prefix lengths much = larger then 64 (80 is the example).

    I think the most we can say there is that the = working group wanted to reserve power in the future to define new link = types (or revise existing link types) to allow for standard use of an = IID length other than 64 bits (for example 48 bits).

    There appears to be no evidence in that thread = that the working group wanted to REQUIRE hosts to accept PIO elements = for purposes of on-link determination even when their Prefix Length is = invalid for address configuration on the link type in use.

    I discussed this in detail in my long previous = message reviewing this text.


    The relevant excerpt of my previous message = follows:

    But we=E2=80=99re not done. RFC 4862 = continues:

    >> It is the responsibility of the system administrator = to ensure that the lengths of prefixes contained in Router = Advertisements are consistent with the length of interface identifiers = for that link type.

    I do not read this as any requirement on the host implementer = to accommodate system administrators who use Prefix Length values that = are not consistent with the IID length defined for the link type in = use.

    >> = It should be noted, however, that this does not mean the advertised = prefix length is meaningless.

    This is informative and helpful, and = not normative text.

    >> In fact, the advertised length has non-trivial = meaning for on-link determination in [RFC4861] where the sum of the = prefix length and the interface identifier length may not be equal to = 128.

    Indeed, = as I read RFC 4861, this recognizes *explicitly* that hosts MAY use = advertised prefixes with invalid Prefix Length for address = configuration, for example, for the purpose of on-link = determination.

    >> Thus, it should be safe to validate the advertised = prefix length here, in order to detect and avoid a configuration error = specifying an invalid prefix length in the context of address = autoconfiguration.

    This is not in conflict with the observation of RFC 4861 that = processing Prefix Lengths for on-link determination that are invalid for = address configuration is not REQUIRED and merely = OPTIONAL. 

    >> Note that a future revision of the address = architecture [RFC4291] and a future link-type-specific document, which = will still be consistent with each other, could potentially allow for an = interface identifier of length other than the value defined in the = current documents.  Thus, an implementation should not assume a = particular constant.  Rather, it should expect any lengths of = interface identifiers.

    As I read this excerpt, this is RFC 4862 expressly = recognizing that future standards action could introduce new valid IID = lengths for address configuration other than 64 bits. This hasn=E2=80=99t = happened yet. (And there is still some controversy about whether RFC = 4291 should not be revised unless it is changed to do = so.)

    In a forthcoming message, I will = propose text for inclusion in I-D.ietf-6man-rfc4291bis with the hope = that it may help clarify this matter further.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_F3FBFB44-ECE4-4109-86AC-C64ABB098494-- From nobody Wed Mar 8 15:24:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC761294EC for ; Wed, 8 Mar 2017 15:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 v6jY4am0lp89 for ; Wed, 8 Mar 2017 15:23:58 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D4C1293EC for ; Wed, 8 Mar 2017 15:23:57 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id y76so94310953qkb.0 for ; Wed, 08 Mar 2017 15:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N53wkYM95CHJVIvDgDZXx2URrKdam6GURG3Ia8DZtnE=; b=IY5YHbkA7KeG4BkiG8rEmKRxMxXsGmj+X7HPpAjBgFNOVwODpYcB4XIi+/b6jwXMTe DdbBcHVjDqsCNlxjnJ/83AfbraLDP7nbmQrJ4QFvXDegwbPVju+4UeX4DLh90VPHydLF LLuQYe4ifP1GtnubRJVKgZWR55kugfa4DTdjs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N53wkYM95CHJVIvDgDZXx2URrKdam6GURG3Ia8DZtnE=; b=IvrHnoAs3iI84MR6Ayy4WaekcknPi9YTLMHcDhRWCM3/aC4wRKh3sxgOziwKOCvRDQ kSKKzwogBdrefxkfIWjJVZvH6dIL1RJMwQR/ZfPGKbEiYDYv3aSgLr/Emo6/99Yt4vNq v58A5pZFnaV2NI8jeRq0XyItnaMO+LFt1EGXplpIP0Zl9zIrvIDdvdgL04hAvgkAXhcq wZbNzfHwrK8lVEiM2YD8alNAdVKSojWPcve4pYeRqMlk21UfBpGYtNuqudNkC2Q88ufc AGlQigTKqVhkvhveHi44z1Fb4nclS/YuKwxsjn6y3E5UarYwQqVtQH9RZH8l67Y0II9L JwjA== X-Gm-Message-State: AMke39mpczCwLkJImkj4qpbXj3YGTrlrRfJGjhtz6wj0Zw56ASqsKxgf/oAGV97KGPJhnzcnNw1ZuDTm3aF0/cb4 X-Received: by 10.237.54.194 with SMTP id f60mr11652692qtb.123.1489015436842; Wed, 08 Mar 2017 15:23:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Wed, 8 Mar 2017 15:23:55 -0800 (PST) In-Reply-To: <9E57925B-6E4B-4B0C-8846-E4F8E96CF52C@google.com> References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> <9E57925B-6E4B-4B0C-8846-E4F8E96CF52C@google.com> From: Timothy Winters Date: Wed, 8 Mar 2017 18:23:55 -0500 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: james woodyatt Content-Type: multipart/alternative; boundary=001a1145c1942dc28b054a406c15 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 23:24:01 -0000 --001a1145c1942dc28b054a406c15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, I look forward to the text, but it won't change the fact the 4861 expects variable length for on-link determination. This excerpt, from Erik Nordmark (author) seems to agree with that: "we should hard-code the /64 boundary in as few places as possible to allow for future evolution. Your 80 bit interface ID on some new links is one example of possible future evolution. Another example is cases where 20 years from now having less than 64 bit interface IDs (or addresses allocated with DHCP from a >64 bit subnet prefix) might fill a useful role. Hard-coding the /64 address too me sounds like the original Arpanet design with 8 bit network numbers and 24 bit host numbers; which was revised/relaxed first with class A/B/C and later with CIDR. I don't know of a technical reason why /64 needs to be a hard limit." I did some we have tested well over 500 IPv6 Implementations are the lab and I'm aware of this failing 4 times ever. This doesn't cover the number of devices that have failed inhouse and haven't come to the IOL. It would seem that almost all current devices support the ND interpretation, and changing this might cause other Interoperability issues. That's my main concern, and I'd have to think on this a bit more. Maybe your text will help clarify this... Regards, Tim On Wed, Mar 8, 2017 at 5:38 PM, james woodyatt wrote: > On Mar 8, 2017, at 13:54, Timothy Winters wrote: > > > Since this was added in the update from RFC 2461 to 4861 I went to go loo= k > for why this was added and found the following thread. > > Discussion: > https://mailarchive.ietf.org/arch/search/?email_list=3Dipv6& > q=3DRequirement+for+64bit+I%2FF+ID&so=3Ddate&gbt=3D1&index=3D > rJtLf5Krh0X9vg3vYts_xO1oUCw > > > Final Decision: > https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4 > > This is clearly about the spirit of this clarification, the working group > when adding this text wanted to allow prefix lengths much larger then 64 > (80 is the example). > > > I think the most we can say there is that the working group wanted to > reserve power in the future to define new link types (or revise existing > link types) to allow for standard use of an IID length other than 64 bits > (for example 48 bits). > > There appears to be no evidence in that thread that the working group > wanted to REQUIRE hosts to accept PIO elements for purposes of on-link > determination even when their Prefix Length is invalid for address > configuration on the link type in use. > > I discussed this in detail in my long previous message reviewing this tex= t. > > > > The relevant excerpt of my previous message follows: > > But we=E2=80=99re not done. RFC 4862 continues: > > >> It is the responsibility of the system administrator to ensure that th= e > lengths of prefixes contained in Router Advertisements are consistent wit= h > the length of interface identifiers for that link type. > > I do not read this as any requirement on the host implementer to > accommodate system administrators who use Prefix Length values that are n= ot > consistent with the IID length defined for the link type in use. > > >> It should be noted, however, that this does not mean the advertised > prefix length is meaningless. > > This is informative and helpful, and not normative text. > > >> In fact, the advertised length has non-trivial meaning for on-link > determination in [RFC4861] where the sum of the prefix length and the > interface identifier length may not be equal to 128. > > Indeed, as I read RFC 4861, this recognizes *explicitly* that hosts MAY > use advertised prefixes with invalid Prefix Length for address > configuration, for example, for the purpose of on-link determination. > > >> Thus, it should be safe to validate the advertised prefix length here, > in order to detect and avoid a configuration error specifying an invalid > prefix length in the context of address autoconfiguration. > > This is not in conflict with the observation of RFC 4861 that processing > Prefix Lengths for on-link determination that are invalid for address > configuration is not REQUIRED and merely OPTIONAL. > > >> Note that a future revision of the address architecture [RFC4291] and = a > future link-type-specific document, which will still be consistent with > each other, could potentially allow for an interface identifier of length > other than the value defined in the current documents. Thus, an > implementation should not assume a particular constant. Rather, it shoul= d > expect any lengths of interface identifiers. > > As I read this excerpt, this is RFC 4862 expressly recognizing that futur= e > standards action could introduce new valid IID lengths for address > configuration other than 64 bits. This hasn=E2=80=99t happened yet. (And = there is > still some controversy about whether RFC 4291 should not be revised unles= s > it is changed to do so.) > > > In a forthcoming message, I will propose text for inclusion in > I-D.ietf-6man-rfc4291bis with the hope that it may help clarify this matt= er > further. > > > --james woodyatt > > > > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a1145c1942dc28b054a406c15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi James,

    I look forward to the text, b= ut it won't change the fact the 4861 expects variable length for on-lin= k determination. =C2=A0

    This excerpt, from Erik No= rdmark (author) seems to agree with that:

    "we= should hard-code the /64 boundary in as few places
    as possible t= o allow for future evolution. Your 80 bit interface ID
    on some ne= w links is one example of possible future evolution.
    Another exam= ple is cases where 20 years from now having less than 64 bit=C2=A0
    interface IDs (or addresses allocated with DHCP from a >64 bit subnet = prefix)
    might fill a useful role.

    Hard-c= oding the /64 address too me sounds like the original Arpanet design
    <= div>with 8 bit network numbers and 24 bit host numbers; which was revised/r= elaxed
    first with class A/B/C and later with CIDR.
    I do= n't know of a technical reason why /64 needs to be a hard limit."<= /div>

    I did some we have tested well over 500 IPv6 Imple= mentations are the lab and I'm aware of this failing 4 times ever. This= doesn't cover the number of devices that have failed inhouse and haven= 't come to the IOL. =C2=A0 It would seem that almost all current device= s support the ND interpretation, and changing this might cause other Intero= perability issues. That's my main concern, and I'd have to think on= this a bit more.=C2=A0 Maybe your text will help clarify this...

    Regards,
    Tim

    On Wed, Mar 8, 2017 at 5:38 PM, james wood= yatt <jhw@google.com> wrote:
    =
    On Mar 8, 2017, at 13:= 54, Timothy Winters <twinters@iol.unh.edu> wrote:

    Since this was added in the upd= ate from RFC 2461 to 4861 I went to go look for why this was added and foun= d the following thread.

    Discussion:


    This is clearly about the s= pirit of this clarification, the working group when adding this text wanted= to allow prefix lengths much larger then 64 (80 is the example).

    I think the most we can say ther= e is that the working group wanted to reserve power in the future to define= new link types (or revise existing link types) to allow for standard use o= f an IID length other than 64 bits (for example 48 bits).

    There appears to be no evidence in that thread that the working gro= up wanted to REQUIRE hosts to accept PIO elements for purposes of on-link d= etermination even when their Prefix Length is invalid for address configura= tion on the link type in use.

    I discussed this in = detail in my long previous message reviewing this text.

    =C2=A0 <https://mailarchi= ve.ietf.org/arch/msg/ipv6/oZ3dnjn3-tl8y1Gypgo3Eycco6g>

    The relevant excerpt of my previous message follows:<= /div>

    <= div>
    But we=E2=80=99re = not done. RFC 4862 continues:

    >> It is the r= esponsibility of the system administrator to ensure that the lengths of pre= fixes contained in Router Advertisements are consistent with the length of = interface identifiers for that link type.

    I do not= read this as any requirement on the host implementer to accommodate system= administrators who use Prefix Length values that are not consistent with t= he IID length defined for the link type in use.

    &g= t;> It should be noted, however, that this does not mean the advertised = prefix length is meaningless.

    This is informative = and helpful, and not normative text.

    >> In f= act, the advertised length has non-trivial meaning for on-link determinatio= n in [RFC4861] where the sum of the prefix length and the interface identif= ier length may not be equal to 128.

    Indeed, as I r= ead RFC 4861, this recognizes *explicitly* that hosts MAY use advertised pr= efixes with invalid Prefix Length for address configuration, for example, f= or the purpose of on-link determination.

    >> = Thus, it should be safe to validate the advertised prefix length here, in o= rder to detect and avoid a configuration error specifying an invalid prefix= length in the context of address autoconfiguration.

    This is not in conflict with the observation of RFC 4861 that processing= Prefix Lengths for on-link determination that are invalid for address conf= iguration is not REQUIRED and merely OPTIONAL.=C2=A0

    >> Note that a future revision of the address architecture [RFC429= 1] and a future link-type-specific document, which will still be consistent= with each other, could potentially allow for an interface identifier of le= ngth other than the value defined in the current documents.=C2=A0 Thus, an = implementation should not assume a particular constant.=C2=A0 Rather, it sh= ould expect any lengths of interface identifiers.

    = As I read this excerpt, this is RFC 4862 expressly recognizing that future = standards action could introduce new valid IID lengths for address configur= ation other than 64 bits. This hasn=E2=80=99t happened yet. (And there is s= till some controversy about whether RFC 4291 should not be revised unless i= t is changed to do so.)

    In a forthcoming message, I will propose text for inclusion in= I-D.ietf-6man-rfc4291bis with the hope that it may help clarify this matte= r further.


    --james woodyatt <jhw@google.com>






    --

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --001a1145c1942dc28b054a406c15-- From nobody Wed Mar 8 16:33:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8017712950C for ; Wed, 8 Mar 2017 16:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BSwozhWYlYU9 for ; Wed, 8 Mar 2017 16:33:52 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DBAB1294E6 for ; Wed, 8 Mar 2017 16:33:52 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id 1so95766597qkl.3 for ; Wed, 08 Mar 2017 16:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QoXBgu/8RDUyMCFO2aLPnz5Ryn53KW1RUT9MyeEbvaU=; b=P4qFYbF7knnaxlemr3d24XeWUOq/CSIzenytb/Bn7t4G1sf6+ILUIzISYL61YbY50v cDon4U90eMt13inHuHjJFkUJcebjOpEG9h36eqVgtemDrh1zidqLsF0zEC1msU+N2evl DhMzA4ZpM9TUn00t5iFT2tZCMwynOeYgs2uMmAvJI20rekmobh9XpEAk8T1Rbo8frZG/ iE5vC1A/dL+59bTnIpgx7a89wtAiGVCZjzCKMX+7eOWc4rGoVAqNeySHbfnvmnL1FuiO KZncq1a8rx+Zo1SWWAK2L5+yoyJD4xTJuL7oF3UdgqolQgSdigHeCItrO1GWJQ96aikM NukA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QoXBgu/8RDUyMCFO2aLPnz5Ryn53KW1RUT9MyeEbvaU=; b=IGBO1h6r+N7T689ZN6BPO59tr/AFksJrCVcZZq3WJWiPM78D3XlmtEQp21UURRCbFT PCxlYMcN6/bYPLy3zXRqAqHwbUS+P7ZBzMMivVlquiGEWWVZKaoF7IWfaNNBHi4urPke v7ggZEBUCIC2huQdqbWxgiAJuStD4lmpcf6G2bqY1+2Yz7BuyceEyPgap5K1hNW0c/Nt pIepI4m9T1nZzXbdPOhe8W9JfZ0MayrlVx8VyOszWoW0mTyJ8qoQqJMD9me728gju/oT xhvuM8gZRoo6nrwMUt9aHze4ZKn63MD3hcyen4/7q7ThDcRwJrZGQbMXinK7JQb35/WM IZ8g== X-Gm-Message-State: AMke39mHxRO8bgtPMxR5agvPy51MAdm+S37XEFCkVdJvfMkyg3JnNotuoGukszZzWz8dupSAbzRK2r7C1eSdWQ== X-Received: by 10.233.222.197 with SMTP id s188mr10337795qkf.311.1489019631206; Wed, 08 Mar 2017 16:33:51 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Wed, 8 Mar 2017 16:33:50 -0800 (PST) In-Reply-To: References: <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 8 Mar 2017 16:33:50 -0800 X-Google-Sender-Auth: IVOMqsxHYJU9kIxw0N8paOSEhJI Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 To: Timothy Winters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: james woodyatt , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 00:33:55 -0000 At Wed, 8 Mar 2017 16:54:43 -0500, Timothy Winters wrote: > Since this was added in the update from RFC 2461 to 4861 I went to go look > for why this was added and found the following thread. > > Discussion: > https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I%2FF+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw I guess a more relevant discussion is this: https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Reception+of+prefix+option+with+prefix+length+%3E+64&so=date&gbt=1 > Final Decision: > https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4 In that thread, I asked the very same question as that we are having now: >> For example, assuming a 64-bit interface identifier, if we receive >> an RA containing an prefix information option with 80-bit prefix >> length and with the L and A bits both being set, [...] >> [...] I think the receiving node should still consider the >> prefix as valid in terms of ND (i.e., consider it as "on-link") and >> modify the next-hop determination accordingly. >> The questions are: >> 1. is this a correct understanding of the intention of RFC2461? And, Erik Nordmark ("the father of ND") gave a "yes" answer to the question: https://www.ietf.org/mail-archive/web/ipv6/current/msg01801.html So, the fact is that: - the "lenient behavior" (like what BSDs or Linux implementations do) is the intent of the very original designer of ND - we explicitly discussed this in the work on rfc2461bis and confirmed it I'm not sure if this helps the current discussion, though, since one may still insist that he is not convinced unless the RFC enforces this intent with a strongest RFC2119 keyword (e.g., a MUST). -- JINMEI, Tatuya From nobody Wed Mar 8 23:58:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD45129418 for ; Wed, 8 Mar 2017 23:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jc48342xVcBC for ; Wed, 8 Mar 2017 23:58:43 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D182128E18 for ; Wed, 8 Mar 2017 23:58:42 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v297we0h011142 for ; Thu, 9 Mar 2017 08:58:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2B6B1201F7F for ; Thu, 9 Mar 2017 08:58:40 +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 225DC203C57 for ; Thu, 9 Mar 2017 08:58:40 +0100 (CET) Received: from [132.166.84.188] ([132.166.84.188]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v297wd1J008929 for ; Thu, 9 Mar 2017 08:58:39 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - timeline To: ipv6@ietf.org References: <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> From: Alexandre Petrescu Message-ID: <3397bed0-1ca8-7b62-8215-7561883de4a9@gmail.com> Date: Thu, 9 Mar 2017 08:58:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 07:58:44 -0000 Hi, Thanks for the pointers to the earlier discussion. Le 08/03/2017 à 22:54, Timothy Winters a écrit : > Hi James, > > Since this was added in the update from RFC 2461 to 4861 I went to > go look for why this was added and found the following thread. > > Discussion: > https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I%2FF+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw > > > > Final Decision: > https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4 I think that decision is that ND should work with arbitrary plens, not just 64. In light of that ND decision, it is strange to see an RFC at the same time IPv6 Addressing Architecture mandating IIDs 64 (and implicit mathematical plen 128). Retrospectively: At time of that discussion, year 2004, there was no IPv6 on cellular links, [I-D]. Since then 3GPP got many recommendations from IETF about how to run IPv6. The result is 3GPP User Equipment links only support a single 64 today. My supposition, and many indications converge, is that the 64 recommendation from the IPv6 Addressing Architecture RFC led to this undesirable situation of a single 64 for an UE. If we were again in 2004, I would tell that decision maker: not only ND should avoid the 64 limit, but the IPv6 Addressing Archi should too. That would have saved us many recent RFCs discussing 64 (the BCP CIDR IPv6, the multiple-address per Host recommendation, the why64 RFC, and many others I mistakenly forgot). We are now in 2017... Alex From nobody Thu Mar 9 00:18:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4931204D9 for ; Thu, 9 Mar 2017 00:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 IgYYgSMetsqY for ; Thu, 9 Mar 2017 00:18:37 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADD9129480 for ; Thu, 9 Mar 2017 00:18:37 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 09 Mar 2017 08:18:37 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id C0267D788D; Thu, 9 Mar 2017 00:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=K8ZeFYOMXPAu2kPxSs3WhYxyCHs=; b= qTfkh7RIAWki9hksTntWIjehaOhzuVrLidNdCexBXxjv3AIYmO7eGMHIIZAXB5wl f3pXWcLsZQMK4UceMJRrgeais6PJZuYCO6JA+g8CLtbqz5TGYhDicEIkI9ZFrqs6 e3sTpHBIdozNYVOU+nOeZyl0VeMxVRFYxCRh0SAda8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=U9nr/HUYq5U+vqrXfnt00em tumQbaKPevnh1KVighDgOCsO4BqfRH4eaz4FJl4P4Z3gNJZixRujXrJ4/FHMj/Sh S7KCEF9JuSVC1CLRs7mCHxicvu+5qXOLFcac47yJy+Q+2YGnY+nS+GO2HInmbh3k hCp573/IHfoTcj2tj43E= Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 88C58D788B; Thu, 9 Mar 2017 00:18:36 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8C3C999CC966; Thu, 9 Mar 2017 09:18:34 +0100 (CET) From: otroan@employees.org Message-Id: <420E5EB5-2FD8-4CF6-B067-5C51501911CE@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_7A23F8F7-2886-44CE-BAA5-DAF1060AE679"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - timeline Date: Thu, 9 Mar 2017 09:18:34 +0100 In-Reply-To: <3397bed0-1ca8-7b62-8215-7561883de4a9@gmail.com> To: Alexandre Petrescu References: <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> <3397bed0-1ca8-7b62-8215-7561883de4a9@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 08:18:38 -0000 --Apple-Mail=_7A23F8F7-2886-44CE-BAA5-DAF1060AE679 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alex, [...] > Retrospectively: >=20 > At time of that discussion, year 2004, there was no IPv6 on cellular > links, [I-D]. Since then 3GPP got many recommendations from IETF about > how to run IPv6. The result is 3GPP User Equipment links only support = a > single 64 today. >=20 > My supposition, and many indications converge, is that the 64 > recommendation from the IPv6 Addressing Architecture RFC led to this > undesirable situation of a single 64 for an UE. That is one speculation. You may reconstruct history differently: If it wasn't for RFC6177/RFC3177 combined with the 64-bit boundary (and = SLAAC), what you would have had on a UE would be a single IPv6 address. Cheers, Ole --Apple-Mail=_7A23F8F7-2886-44CE-BAA5-DAF1060AE679 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwQ/aAAoJEL7aWKiYQt92MtcP/jG0jwzx4T2TbjBAY/TGW/QX d5vot82UA2FA1NM5vWBN0sMbf9BC1T75hcQjNWVXddchtS8rrWTC7iAXPf6ZEHKt BKK4iCatxrjue2uhHCfzBsGcJTB8GU3QivIDzUD8x5nAlxsWbuA4xJV4I8DyMlps bFMipkXl6vAW1MZKxPzAW6wkqD09OPbcIEUKsF2txKcZwfvqP3WBXUtvmtwk9IU7 SYPbk9srgXkFycWw+Rf/ZvrAK7TPgwv3l1DRxiRLuXmaRkUDOfbpfpwTMia/tJ4l UPLOndMyOLglYBPUNLo0mmzmly7vERx81ysjIjuHHq543peEk4zFQQmdkNJoeDwH 98Ow7dAVCZNKBnsTF5I0nAg8XhiPjx1s05NCEP1/q5ZaSsC07N1IghXDrTh6cIXh uMBmdpirN5XvNcasLjHPYSrbRlwRSkcJCZahxX0RPNE9yr6S2+hXL5PitKbte0ti /G0WQQeuqC0b4PkT+IenmZhOjHctY0UX7+m349Dna7ojdWnqBv/UplvC9ByCFjSl F52Pn8DYk3DvOKbt9dRA8JzosPT0mC3J15I5PJHDGuht8nKxlE0RAtby0vxOmowO B4NHDakquYsMqOUaB/gTf1BrX84ss7ACN+CHt40jSZ0mGt1xnovW8qvNvRraoDIK IibP3w8ZCtHw1yUPotwP =nUHY -----END PGP SIGNATURE----- --Apple-Mail=_7A23F8F7-2886-44CE-BAA5-DAF1060AE679-- From nobody Thu Mar 9 00:19:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D07B12949D for ; Thu, 9 Mar 2017 00:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 xeRBswSfRKCU for ; Thu, 9 Mar 2017 00:19:24 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753521204D9 for ; Thu, 9 Mar 2017 00:19:24 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id b129so23758902pgc.2 for ; Thu, 09 Mar 2017 00:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=w63yz06bWrmlLlw7vX1rRKyuzYvo+OOI6OKsWw8bzgw=; b=RdrqzrwvVEFYS4jT2YFGFXim/ErYkETxxtC6EbdlwlDVnHclmaJt/9amX5ft8bWR0D O87s7cKRBRYb/mDXQBz9z6hjPPkV7kQdHvAmb/b+JrZBLOYO8Hy49/rTFuY32xKySPdf WQkJ1Gos73SNvrg4TUjhid2gwQsOoKtOl3Cjg3CnwZJbNiNgt/Rw/QBqlYsWWlO/z7sz gjsMQdzXlhwKvvXpxDYbv55c2eWyqwU622f5Qnk/sxXAU3cOEa6SZiCKSmAfMCwZF+84 ZYfoTfuovKRNxicTJksv9owUwHb4XqyKcIN+S+2dw9KJoBstbBe+LRdxS+p1cnSH9lOU 872A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=w63yz06bWrmlLlw7vX1rRKyuzYvo+OOI6OKsWw8bzgw=; b=qCAEajelEWs68GtrNSE4h03yBKX1VYYj8jz+KKQ5Q38V4nunIgQQ4bB9FIaI3VDtmB eF8JLv6ew882mCZbNIx8hYwJ/g8dOCnit4rnDNR0U9qiPxcq+mJFofL6XWNZqFmY9hdF IbTYO0oo9nMjr0D/BiYGyC0XNOBemAnGuvsl5uBUPgVyWP5Is6V3Jm+nujlScxV0dJ3n 9TMtQ9NkoRbHywZ6a904YID8A6iCCCaZqnHRTBwzCKJ58OglZfNyqszh3DDIKyjEr4+h hqhFh5LSKR96GmWT+0BJu+LhBjZjS7VQSVI2DJ4o+6yjwCnACUwkpcQ3ikgP0/xWb8ed r3xA== X-Gm-Message-State: AMke39l1Shl8tVDa7NWJlDj/Atg6yw12icHRJOWagiVSjhKwcQU8cu/1VxDluZzF1/TexKvn X-Received: by 10.84.168.4 with SMTP id e4mr15434273plb.138.1489047563410; Thu, 09 Mar 2017 00:19:23 -0800 (PST) Received: from [10.0.1.14] (moon.conjury.org. [50.0.204.61]) by smtp.gmail.com with ESMTPSA id g27sm10697622pgn.20.2017.03.09.00.19.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 00:19:22 -0800 (PST) From: james woodyatt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Message-Id: <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> Date: Thu, 9 Mar 2017 00:19:21 -0800 To: 6man WG X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 08:19:26 -0000 Hi Everyone, This message includes my proposal to provide further clarity in the = successor to RFC 4291 on recent questions related to the length of = interface identifiers and consequently to the length of subnet prefixes = and their relationship to the validity of on-link prefix determination. I see two possible alternatives for consideration. 1. In the =E2=80=9Cconservative=E2=80=9D alternative, interface = identifiers are required to have a standard length according to the type = of link, and 64 bits is the recommended length for use in future = standards, citing RFC 7421. I believe this to be consistent with what = RFC 4291 says today, but also at variance with what many participants = would prefer and not fully consistent with what some people also say is = the letter and spirit of RFC 4861 and RFC 4862 (including the authors of = those documents). 2. In the =E2=80=9Cliberal=E2=80=9D alternative, the length of interface = identifiers is unspecified, and 64 bits is the RECOMMENDED length, = citing RFC 7421. I believe this to be a significant technical change to = the current requirements set by RFC 4291, with additional complications = that need to be described and understood, but it would be more in = keeping with the letter and spirit of RFC 4861 (but not entirely with = RFC 4862) and I believe more preferable to the participants who object = to the current draft (and likely my conservative alternative too). 3. In both alternatives, I=E2=80=99ve proposed a new subsection to = describe briefly the concept of neighbor discovery, to discuss the = distinction (from RFC 5942) between subnet prefixes and on-link prefixes = and their relationships to interface identifiers. I think this will help = clear up the ambiguity that I discussed previously at length in a recent = message to the working group. For the record, I=E2=80=99m still very much in favor of my proposed = =E2=80=9Cconservative" alternative, but I provide the =E2=80=9Cliberal" = alternative as well in the hope of offering some constructive = improvement over the current draft despite my reservations about = choosing that alternative. Here are both sets of my proposed changes. =E2=80=94 Update to =C2=A72.1 Addressing Model Current: > Currently, IPv6 continues the IPv4 model in that a subnet prefix is = associated with one link. Multiple subnet prefixes may be assigned to = the same link. Proposed (liberal and conservative): > The relationship between links and IPv6 subnet prefixes is not the = same as in the IPv4 model. As explained in The IPv6 Subnet Model = [RFC5942], the most important differences are that multiple subnet = prefixes may be assigned to the same link, and that unicast addresses = are not automatically associated with an on-link prefix. Reasoning: RFC 5942 is Proposed Standard and without errata. Its = abstract explicitly says that IPv6 diverges from the IPv4 subnet model = rather than continuing it. This correction reflects the truth of that. = This change would also add an informative reference to RFC 5942. =E2=80=94 Update to =C2=A72.2.2 Text Representation of Address Prefixes Current: > When writing both a node address and a prefix of that node address = (e.g., the node's subnet prefix), the two can be combined as follows: >=20 > the node address 2001:0db8:0:cd30:123:4567:89ab:cdef > and its subnet number 2001:0db8:0:cd30::/60 Proposed (liberal and conservative): > When writing both a node address and a prefix of that node address, = the two can be combined as follows: >=20 > the node address 2001:0db8:0:cd30:123:4567:89ab:cdef > and its prefix 2001:0db8:0:cd30::/60 Reasoning: eliding the example of =E2=80=9Csubnet prefix=E2=80=9D here = avoids the suggestion that link types have already been defined (at the = time of publication) for which 68 bits is a valid length for interface = identifiers. =E2=80=94 Update to =C2=A72.4 Unicast Addresses Current: > IPv6 unicast routing is based on prefixes of any valid length up to = 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on = inter-router point-to-point links. However, the Interface ID of all = unicast addresses, except those that start with the binary value 000, is = required to be 64 bits long. The rationale for the 64 bit boundary in = IPv6 addresses can be found in [RFC7421] Proposed (liberal and conservative): > IPv6 unicast routing is based on prefixes of any valid length up to = 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on = inter-router point-to-point links. Reasoning: In the current text, the sentence beginning with = =E2=80=9CHowever,=E2=80=9D uses the phrase =E2=80=9CInterface ID=E2=80=9D = before it is adequately defined (along with the concept of the subnet = prefix) in the subsequent text. (See below, where the elided language in = this paragraph is restored in the conservative alternative.) Current: > A slightly sophisticated host (but still rather simple) may = additionally be aware of subnet prefix(es) for the link(s) it is = attached to, where different addresses may have different values for n: >=20 > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+ Proposed (conservative): > A slightly sophisticated node (e.g. one capable of neighbor discovery) = may additionally be aware of subnet prefix(es) for the link(s) to which = it attaches, where the length (n) of the interface ID field may vary = with different types of link: >=20 > | 128-n bits | n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+ >=20 > Note: according to the reasoning presented in Analysis of the 64-bit = Boundary in IPv6 Addressing [RFC7421], the length of the Interface ID = field in all unicast IPv6 addresses is 64 bits, except for addresses = beginning with binary value 000 and except in cases where otherwise = specified in future IETF standard actions. Reasoning: this (conservative) change clarifies that interface = identifiers have a length that is a function of the link type, which = defines the length of the interface identifier, which is a constant for = all links of that type. And it cites RFC 7421 to explain why 64 bits is = required for most interface identifiers. And it replaces =E2=80=9Chost=E2=80= =9D with =E2=80=9Cnode=E2=80=9D in one case where that=E2=80=99s more = accurate. Proposed (liberal): > A slightly sophisticated node (e.g. capable of neighbor discovery) may = additionally be aware of subnet prefix(es) for the link(s) to which it = attaches, where the length (n) of the interface ID field may vary for = each subnet prefix: >=20 > | 128-n bits | n bits | > +-------------------------------+---------------------------------+ > | subnet prefix | interface ID | > +-------------------------------+---------------------------------+ >=20 > Note: according to the reasoning presented in Analysis of the 64-bit = Boundary in IPv6 Addressing [RFC7421], interface identifiers are = recommended to be 64 bits in length. Reasoning: this (liberal) change relaxes the requirement that interface = identifiers have any fixed length, citing RFC 7421 to recommend 64 bits = (but not require it). And it replaces =E2=80=9Chost=E2=80=9D with = =E2=80=9Cnode=E2=80=9D in one case where that=E2=80=99s more accurate. =E2=80=94 Update to =C2=A72.4.1 Interface Identifiers Current: > Interface identifiers in IPv6 unicast addresses are used to identify = interfaces on a link. They are required to be unique within a subnet = prefix. It is recommended that the same interface identifier not be = assigned to different nodes on a link. They may also be unique over a = broader scope. The same interface identifier may be used on multiple = interfaces on a single node, as long as they are attached to different = subnets. Proposed (conservative): > Interface identifiers in IPv6 unicast addresses are used to identify = interfaces on a link. They are required to be of a standard length for = the type of the link and unique among all the nodes on the link using = the same subnet prefix. It is recommended that the same interface = identifier not be assigned to different nodes on the same link. They may = also be unique over a broader scope. The same interface identifier may = be used on multiple interfaces on a single node, as long as they are = used with different subnet prefixes. Reasoning: this (conservative) change improves clarity by ensuring the = term =E2=80=9Csubnet=E2=80=9D is always used in the phrase =E2=80=9Csubnet= prefix=E2=80=9D and not as a shorthand for a subset of the nodes on a = link using addresses that share the same subnet prefix. It also = clarifies that standards dictate the valid length(s) of interface = identifiers for each link type. Proposed (liberal): > Interface identifiers in IPv6 unicast addresses are used to identify = interfaces on a link. They are required to be unique among all the nodes = on the link using the same subnet prefix. It is recommended that the = same interface identifier not be assigned to different nodes on a link. = They may also be unique over a broader scope. The same interface = identifier may be used on multiple interfaces on a single node, as long = as they are used with different subnet prefixes. Reasoning: this (liberal) change only improves clarity by ensuring the = term =E2=80=9Csubnet=E2=80=9D is always used in the phrase =E2=80=9Csubnet= prefix=E2=80=9D and not as a shorthand for a subset of the nodes on a = link using addresses that share the same subnet prefix. It leaves open = the variable length of interface identifiers. =E2=80=94 Update to =C2=A72.4.4 Global Unicast Addresses Current: > The general format for IPv6 Global Unicast addresses is as follows: >=20 > | n bits | m bits | 128-n-m bits | > +------------------------+-----------+----------------------------+ > | global routing prefix | subnet ID | interface ID | > +------------------------+-----------+----------------------------+ >=20 > where the global routing prefix is a (typically = hierarchically-structured) value assigned to a site (a cluster of = subnets/links), the subnet ID is an identifier of a link within the = site, and the interface ID is as defined in Section 2.4.1. >=20 > As noted in Section 2.4, all Global Unicast addresses other than those = that start with binary 000 have a 64-bit interface ID field (i.e., n + m = =3D 64), formatted as described in Section 2.4.1. Global Unicast = addresses that start with binary 000 have no such constraint on the size = or structure of the interface ID field. >=20 > Examples of Global Unicast addresses that start with binary 000 are = the IPv6 address with embedded IPv4 addresses described in Section = 2.4.5. An example of global addresses starting with a binary value other = than 000 (and therefore having a 64-bit interface ID field) can be found = in [RFC3587]. Proposed (conservative): > The general format for IPv6 Global Unicast addresses is as follows: >=20 > | 128-n-m bits | m bits | n bits | > +------------------------+-----------+----------------------------+ > | global routing prefix | subnet ID | interface ID | > +------------------------+-----------+----------------------------+ >=20 > where the global routing prefix is a (typically = hierarchically-structured) value assigned to a site (a cluster of subnet = prefixes assigned to links), the subnet ID is an identifier of a link = within the site, and the interface ID is as defined in Section 2.4.1. >=20 > As noted in Section 2.4, all Global Unicast addresses other than those = that start with binary 000 have a 64-bit interface ID field (i.e., n =3D = 64), formatted as described in Section 2.4.1. Global Unicast addresses = that start with binary 000 have no such constraint on the size or = structure of the interface ID field. >=20 > Examples of Global Unicast addresses that start with binary 000 are = the IPv6 address with embedded IPv4 addresses described in Section = 2.4.5. An example of global addresses starting with a binary value other = than 000 (and therefore having a 64-bit interface ID field) can be found = in [RFC3587]. Reasoning: the only changes here are to make the field headings in the = structure diagram consistent with those proposed for the similar diagram = in =C2=A72.4, to use =E2=80=9Csubnet=E2=80=9D only in the phrase = =E2=80=9Csubnet prefix=E2=80=9D and not as cognate of link, and to = update the explanatory parenthetical in the second paragraph, =E2=80=9C(i.= e. n =3D 64)=E2=80=9D, to reflect it accordingly.=20 Proposed (liberal): > The general format for IPv6 Global Unicast addresses is as follows: >=20 > | 128-n-m bits | m bits | n bits | > +------------------------+-----------+----------------------------+ > | global routing prefix | subnet ID | interface ID | > +------------------------+-----------+----------------------------+ >=20 > where the global routing prefix is a (typically = hierarchically-structured) value assigned to a site (a cluster of subnet = prefixes assigned to links), the subnet ID is an identifier of a link = within the site, and the interface ID is as defined in Section 2.4.1. Reasoning: the field headings in the structure diagram are made = consistent with those for the similar diagram in =C2=A72.4, and the two = final paragraphs about addresses that start with binary 000 are elided = in accordance with the proposed (liberal) change to =C2=A72.4. Also, the = word =E2=80=9Csubnet=E2=80=9D is used properly in the phrase =E2=80=9Csubn= et prefix=E2=80=9D where it is more clearly defined. =E2=80=94 Insertion of =C2=A72.4.8 Neighbor Discovery Proposed (conservative): > Nodes can send packets directly to other nodes with interfaces on the = same link, without forwarding by a router, when they can identify the = link-layer addresses associated with the unicast IPv6 addresses that = share on-link subnet prefixes assigned to the interface. Neighbor = discovery is conceptually the process of resolving such associations as = necessary. >=20 > Nodes may be configured manually with on-link subnet prefixes for each = of their interfaces. Also, routers may inform hosts automatically of the = set of on-link subnet prefixes by a process related to neighbor = discovery. Nodes sending packets to unicast addresses with subnet = prefixes that are not on-link must direct those packets to a router for = forwarding to their destination. >=20 > Every on-link prefix is a subnet prefix, and subnet prefixes for all = global unicast addresses beginning with a binary value other than 000 = are required according to Section 2.4 to be 64 bits in length. Reasoning: this text provides clarification that on-link prefixes are = subnet prefixes for which neighbor discovery can be used by nodes to = communicate directly without forwarding packets through a router. It = also repeats the requirement that all subnet prefixes other than those = beginning with 0b000 are 64 bits long. Proposed (liberal): > Nodes can send packets directly to other nodes with interfaces on the = same link, without forwarding by a router, when they can identify the = link-layer addresses associated with the unicast IPv6 addresses that = share on-link prefixes assigned to the interface. Neighbor discovery is = conceptually the process of resolving such associations as necessary. >=20 > Nodes may be configured manually with on-link prefixes for each of = their interfaces. Also, routers may inform hosts automatically of the = set of on-link prefixes by a process related to neighbor discovery. = Nodes sending packets to unicast addresses without an on-link prefix = must direct those packets to a router for forwarding to their = destination. >=20 > An important distinction is made between subnet prefixes, which are = defined in Section 2.4 as the part of a unicast address that precedes = the interface identifier, and on-link prefixes which do not necessarily = have structure in the part of unicast addresses that follows them. In = particular, an on-link prefix may be shorter than the one or more subnet = prefixes that share it, in which case the part that follows the on-link = prefix consists of some additional bits that precede the interface = identifier. Likewise, an on-link prefix may be longer than a subnet = prefix it shares with one or more other on-link prefixes, in which case = the part that follows the on-link prefix is only a portion of an = interface identifier and hence may not itself necessarily have all the = properties of an interface identifier as defined in Section 2.4.1, = therefore it must not be used alone, in that case, to identify an = interface on a link. Reasoning: this text is similar to the text in the conservative = alternative except that it does not assert that every on-link prefix is = a subnet prefix or specify any requirement for the length of either = on-link or subnet prefixes. However, it does include an additional = paragraph that discusses the necessary distinction between on-link and = subnet prefixes in substantial detail, and it forbids the use of the = part of a unicast address following an on-link prefix as identification = for an interface on a link unless it is sufficiently long to meet the = requirements of =C2=A72.4. =E2=80=94 Update to =C2=A72.5 Anycast Addresses Current: > Some other possible uses are to identify the set of routers attached = to a particular subnet, or the set of routers providing entry into a = particular routing domain. Proposed (liberal and conservative): > Some other possible uses are to identify the set of routers attached = to a link for use by nodes at addresses sharing a particular subnet = prefix, or to identify the set of routers providing entry into a = particular routing domain. Reasoning: this change improves clarity by ensuring the term = =E2=80=9Csubnet=E2=80=9D is always used in the phrase =E2=80=9Csubnet = prefix=E2=80=9D and not as a shorthand for a subset of the nodes on a = link using addresses that share the same subnet prefix. =E2=80=94 Update to =C2=A72.5.1 Required Anycast Address Current: > 2.5.1. Required Anycast Address >=20 > The Subnet-Router anycast address is predefined. Its format is as = follows: >=20 > | n bits | 128-n bits | > +------------------------------------------------+----------------+ > | subnet prefix | 00000000000000 | > +------------------------------------------------+----------------+ >=20 > The "subnet prefix" in an anycast address is the prefix that = identifies a specific link. This anycast address is syntactically the = same as a unicast address for an interface on the link with the = interface identifier set to zero. >=20 > Packets sent to the Subnet-Router anycast address will be delivered to = one router on the subnet. All routers are required to support the = Subnet-Router anycast addresses for the subnets to which they have = interfaces. Proposed (liberal and conservative): > 2.5.1. Subnet-Router Anycast Address >=20 > The Subnet-Router anycast address is predefined for each subnet = prefix. Its structure, as shown below, is the same as a unicast address = with the same subnet prefix and with zero for the interface identifier. >=20 > | 128-n bits | n bits | > +------------------------------------------------+----------------+ > | subnet prefix | 00000000000000 | > +------------------------------------------------+----------------+ >=20 > Packets sent to the Subnet-Router anycast address are destined for any = router on the link that is assigned a unicast address with the = corresponding subnet prefix. All routers are required to assign = Subnet-Router anycast addresses to their interfaces for each subnet = prefix used on the link. Reasoning: this change (which is essentially a complete rewrite of = =C2=A72.5.1) improves clarity by making the field headers in the = structure diagram consistent with =C2=A72.4, and by ensuring the term = =E2=80=9Csubnet=E2=80=9D is always used in the phrase =E2=80=9Csubnet = prefix=E2=80=9D and not as a shorthand for a subset of the nodes on a = link using addresses that share the same subnet prefix. Commentary: it=E2=80=99s not clear to me what is the real purpose of the = Subnet-Router anycast address, even in the conservative case, but = especially so in the liberal case where on-link prefixes are not = required to have the same length as subnet prefixes. It seems okay that = a single Subnet-Router anycast address should be defined as the = destination for any router with an address where more than one on-link = prefix has a shorter subnet prefix in common. It seems much less okay = that multiple Subnet-Router anycast addresses should be defined as = destinations for any router with addresses having more than one subnet = prefix sharing a common on-link prefix. Still, I don=E2=80=99t see how = it breaks anything important, so I'm saying: let's try not to do any = further damage. =E2=80=94=E2=80=94 In summary, I believe when publishing the successor to RFC 4291 it may = be possible for IETF to further clarify the IPv6 address architecture so = that controversies over the validity of on-link prefixes used in = neighbor discovery do not arise, either A) in the conservative case, = because all on-link prefixes are also subnet prefixes and subnet = prefixes are constrained to standard size(s) for each link type and to = 64 bits for all prefixes beginning with 0b000, or B) in the liberal = case, because neither on-link prefixes nor subnet prefixes are = constrained to any standard size nor even required to be the same = length. I hope this proposal will be seen correctly as my sincere attempt to = provide a constructive basis for resolving this ongoing controversy into = a rough consensus. --james woodyatt From nobody Thu Mar 9 03:17:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0876712950A for ; Thu, 9 Mar 2017 03:17: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 autolearn_force=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 dDA4319zbxxv for ; Thu, 9 Mar 2017 03:17:02 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id C0BCF129468 for ; Thu, 9 Mar 2017 03:17:01 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1clw44-0000I4C; Thu, 9 Mar 2017 12:17:00 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com In-reply-to: Your message of "Thu, 9 Mar 2017 00:19:21 -0800 ." <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> Date: Thu, 09 Mar 2017 12:16:59 +0100 Archived-At: Cc: james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:17:03 -0000 > 1. In the conservative alternative, interface identifiers are > required to have a standard length according to the type of link, > and 64 bits is the recommended length for use in future standards, > citing RFC 7421. I believe this to be consistent with what RFC 4291 > says today, but also at variance with what many participants would > prefer and not fully consistent with what some people also say is > the letter and spirit of RFC 4861 and RFC 4862 (including the > authors of those documents). > > 2. In the liberal alternative, the length of interface identifiers > is unspecified, and 64 bits is the RECOMMENDED length, citing RFC > 7421. I believe this to be a significant technical change to the > current requirements set by RFC 4291, with additional complications > that need to be described and understood, but it would be more in > keeping with the letter and spirit of RFC 4861 (but not entirely > with RFC 4862) and I believe more preferable to the participants > who object to the current draft (and likely my conservative > alternative too). It seems to me that RFC 4291 uses the term interface identifier for what are now two separate concepts. The first interface identifier concept is that for any prefix of length n, the length of the interface identifier is 128-n. Let me call this prefix-iid. The second iid concept is in auto configuration of addresses. I'll call this slaac-iid. The way I see it, any slaac-iid that is based on (pseudo)-random number has to be at least 64 bits. I don't see any reason for more than 64 so exactly 64 sounds about right. In theory, a link that has hardware MAC addresses with less than 64 bits could define a slaac-iid that is shorter, however that precludes the use of pseudo-random slaac-iids. So that doesn't make a lot of sense. Though we could leave room for a future IPv6-over-foo document to do just that. Simply put, a slaac-iid should be 64 bits. For prefix-iids the situation is completely different. A /127 on p2p links is standard. Various long prefixes are used in practice. There really is no reason why a node would care about the length of an onlink prefix. So basically, a node just has to support onlink prefixes of any length. Note that onlink prefixes are not tied to a particular link type. From nobody Thu Mar 9 03:40:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF31129559 for ; Thu, 9 Mar 2017 03:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 wqVrbwWQIoJo for ; Thu, 9 Mar 2017 03:40:05 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D2D129437 for ; Thu, 9 Mar 2017 03:40:05 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id v76so6503470ywg.0 for ; Thu, 09 Mar 2017 03:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZaR7Tw1xamWMxFxmrGwDfYhSCsQN2m14wpACWnxnB8c=; b=M8bEmOkOmidwsPIyAsINi5pzH6El/L/tA5PNtQG68vYkFcCSyav9OXSwv+5BifV9rg Q+fdV/jZzLxoLCCy979TyDFzk5Rdc9M1eX7slgl4X+bJolpton76GqSaLPd3t3WSN8H7 EovuqduVN6VW4TRPBCbd5RlEHI/qEpanHij1DbuLs1aNYYHKMDwGFuMvgOPYVqG1AQJ3 8Jad4gNwxF7/lbILnbx8qFvWIip84Jvxn2bCsjSuq3pN7ZbXL3SjrvdhZ9URkfCOEfqS Yn9ZxHdP4SSAe0vvT77jdlvDqCFM6yJ16sdcuaMt8YxHcqHgaTgRcs839UnzoyX2wwVd Neuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZaR7Tw1xamWMxFxmrGwDfYhSCsQN2m14wpACWnxnB8c=; b=hTubbqjjmQC2ZVlN9hqvQ5ZG2tKqlh6nYuU28hH8IvkYbzOvZinXbFZveEo92wvSJh nnR/T12EExiSkF1KbSfzoygg+Aih8ssP+vVjhLMRrd5UWrQLoQ8aXdQ+l0qdYfKq14Bb 9b/xo79w6G2JVdzLR8UwbexcZ1cCZJdGYwYuyU3vm0f7RtamYQU+xLeWpN/XoRg456Uz oES1LXJMuu8i4Pum3IHWWwoBZLkOoivOk4wzuH9+1kjQsMC4FJkH0MiAI36ZzAuRx0uM skcLp262L36imhFK2T+X+E/8qRiL+wwQxotgtIi9ahw7KFijEhci4+KP74BmezLh/rUQ Xxaw== X-Gm-Message-State: AMke39kfYozB3WWazq5Cv9elUlV0IuSTlGstJhdch9wCWiEAW1LDGwjQ54+GMfMfGc4CWa5K8NiK5vQ5ci4gpKlC X-Received: by 10.129.118.18 with SMTP id r18mr3332305ywc.0.1489059603942; Thu, 09 Mar 2017 03:40:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.4 with HTTP; Thu, 9 Mar 2017 03:39:43 -0800 (PST) In-Reply-To: <420E5EB5-2FD8-4CF6-B067-5C51501911CE@employees.org> References: <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> <3397bed0-1ca8-7b62-8215-7561883de4a9@gmail.com> <420E5EB5-2FD8-4CF6-B067-5C51501911CE@employees.org> From: Erik Kline Date: Thu, 9 Mar 2017 20:39:43 +0900 Message-ID: Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - timeline To: Ole Troan Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045f0ba8ca7129054a4ab455" Archived-At: Cc: Alexandre Petrescu , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:40:07 -0000 --f403045f0ba8ca7129054a4ab455 Content-Type: multipart/alternative; boundary=f403045f0ba8be9622054a4ab47e --f403045f0ba8be9622054a4ab47e Content-Type: text/plain; charset=UTF-8 On 9 March 2017 at 17:18, wrote: > Alex, > > > [...] > > > Retrospectively: > > > > At time of that discussion, year 2004, there was no IPv6 on cellular > > links, [I-D]. Since then 3GPP got many recommendations from IETF about > > how to run IPv6. The result is 3GPP User Equipment links only support a > > single 64 today. > > > > My supposition, and many indications converge, is that the 64 > > recommendation from the IPv6 Addressing Architecture RFC led to this > > undesirable situation of a single 64 for an UE. > > That is one speculation. You may reconstruct history differently: > If it wasn't for RFC6177/RFC3177 combined with the 64-bit boundary (and > SLAAC), what you would have had on a UE would be a single IPv6 address. > Precisely. --f403045f0ba8be9622054a4ab47e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


    On 9 March 2017 at 17:18, <otroan@employees.org> wro= te:
    Alex,


    [...]

    > Retrospectively:
    >
    > At time of that discussion, year 2004, there was no IPv6 on cellular > links, [I-D]. Since then 3GPP got many recommendations from IETF about=
    > how to run IPv6. The result is 3GPP User Equipment links only support = a
    > single 64 today.
    >
    > My supposition, and many indications converge, is that the 64
    > recommendation from the IPv6 Addressing Architecture RFC led to this > undesirable situation of a single 64 for an UE.

    That is one speculation. You may reconstruct history differently: If it wasn't for RFC6177/RFC3177 combined with the 64-bit boundary (and= SLAAC), what you would have had on a UE would be a single IPv6 address.

    Precisely.=C2=A0
    --f403045f0ba8be9622054a4ab47e-- --f403045f0ba8ca7129054a4ab455 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg7oR78kfMK6SnvOprDPny5tNlspn71o9L RqICl25uPzUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzA5 MTE0MDA0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAB/xbLPRuQpPhL7rol+RvkNG4dBH1pbThNjbFnGaXgZkoScsgB6M rdYdTZD2zfCrFPNxIhQM+DdU5Ate69GDG9rwqbRYQj37gn9BUpQB/IWofs7FS5bQ5b/NZ1gjdRvj xj0zq5IcPVCE87bRuTzV+0gnk2NGsihmXgXAEU1x0tg64WLTX4lWklWrURceEvohU+yLvBjeGi5u l4pM3hfdKPwe9OMOUFNCwb7ovW9UFmc2apqZBlfJRj5GmOY/nX8kZhfAaf8k+Qm0yNuqGQQZu8SC g/AoiyQ9kne7MkL1WjcAsM6mSuyytFuC8QIuJTQsd0xLt8Gdy/+iLttTlf48Geo= --f403045f0ba8ca7129054a4ab455-- From nobody Thu Mar 9 04:52:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9352112957B for ; Thu, 9 Mar 2017 04:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 T04I7Q6psZDM for ; Thu, 9 Mar 2017 04:52:04 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F13B129571 for ; Thu, 9 Mar 2017 04:52:03 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v29Cpxmt018337; Thu, 9 Mar 2017 13:51:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 50FE2206DD9; Thu, 9 Mar 2017 13:51:59 +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 443E7203801; Thu, 9 Mar 2017 13:51:59 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v29CpxIg022314; Thu, 9 Mar 2017 13:51:59 +0100 Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - timeline To: otroan@employees.org References: <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> <3397bed0-1ca8-7b62-8215-7561883de4a9@gmail.com> <420E5EB5-2FD8-4CF6-B067-5C51501911CE@employees.org> From: Alexandre Petrescu Message-ID: <3d534946-7432-ba92-0acc-68a43e3e5469@gmail.com> Date: Thu, 9 Mar 2017 13:51:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <420E5EB5-2FD8-4CF6-B067-5C51501911CE@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:52:05 -0000 Le 09/03/2017 à 09:18, otroan@employees.org a écrit : > Alex, > > > [...] > >> Retrospectively: >> >> At time of that discussion, year 2004, there was no IPv6 on >> cellular links, [I-D]. Since then 3GPP got many recommendations >> from IETF about how to run IPv6. The result is 3GPP User Equipment >> links only support a single 64 today. >> >> My supposition, and many indications converge, is that the 64 >> recommendation from the IPv6 Addressing Architecture RFC led to >> this undesirable situation of a single 64 for an UE. > > That is one speculation. You may reconstruct history differently: If > it wasn't for RFC6177/RFC3177 combined with the 64-bit boundary (and > SLAAC), what you would have had on a UE would be a single IPv6 > address. :-) I can agree :-( But I cant continue that way... Alex From nobody Thu Mar 9 06:02:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D51129630 for ; Thu, 9 Mar 2017 06:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 WPvnsv-bdT1q for ; Thu, 9 Mar 2017 06:02:44 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56C9129606 for ; Thu, 9 Mar 2017 06:02:43 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v29E2eT6009543 for ; Thu, 9 Mar 2017 15:02:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 96506202CDB for ; Thu, 9 Mar 2017 15:02:40 +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 8D6632029A7 for ; Thu, 9 Mar 2017 15:02:40 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v29E2dEh018353 for ; Thu, 9 Mar 2017 15:02:39 +0100 Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis - subnet To: ipv6@ietf.org References: <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> From: Alexandre Petrescu Message-ID: Date: Thu, 9 Mar 2017 15:02:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:02:46 -0000 Hi, I will read in detail the proposal later, but for now I would like to point out one thing in particular that pops up every time I read this 4291 text. Le 09/03/2017 à 09:19, james woodyatt a écrit : [...] > Proposed (conservative): >> A slightly sophisticated node (e.g. one capable of neighbor discovery) may additionally be aware of subnet prefix(es) for the link(s) to which it attaches, where the length (n) of the interface ID field may vary with different types of link: >> >> | 128-n bits | n bits | >> +-------------------------------+---------------------------------+ >> | subnet prefix | interface ID | >> +-------------------------------+---------------------------------+ >> >> Note: according to the reasoning presented in Analysis of the 64-bit Boundary in IPv6 Addressing [RFC7421], the length of the Interface ID field in all unicast IPv6 addresses is 64 bits, except for addresses beginning with binary value 000 and except in cases where otherwise specified in future IETF standard actions. That 'subnet prefix' looks very much like a 64bit-or-so subnet. [...] >> | n bits | m bits | 128-n-m bits | >> +------------------------+-----------+----------------------------+ >> | global routing prefix | subnet ID | interface ID | >> +------------------------+-----------+----------------------------+ >> >> where the global routing prefix is a (typically hierarchically-structured) value assigned to a site (a cluster of subnets/links), the subnet ID is an identifier of a link within the site, and the interface ID is as defined in Section 2.4.1. This 'subnet ID' looks like something shorter than a 64bit-or-so length. I think we should be consistent in the use of this subnet word. Alex [...] From nobody Thu Mar 9 06:27:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE82E12964D for ; Thu, 9 Mar 2017 06:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 x7-2J2vrc93W for ; Thu, 9 Mar 2017 06:27:22 -0800 (PST) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF48129661 for ; Thu, 9 Mar 2017 06:27:19 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 18BE19D9 for ; Thu, 9 Mar 2017 14:27:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJqwdHcXU3OI for ; Thu, 9 Mar 2017 08:27:18 -0600 (CST) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 5022F5EC for ; Thu, 9 Mar 2017 08:27:18 -0600 (CST) Received: by mail-ua0-f198.google.com with SMTP id 62so84731283uas.1 for ; Thu, 09 Mar 2017 06:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MWoWcTTLg+kw8d2KQZwG1MRdW9zcKCL97IZQHxKOX6w=; b=BX46VPli/WmLZXU7ZsSlbTKc5FIUbMt3nHCJtW8HmmlNRE4ZnM3PAfCU6cIcIyddWw EBHGfLeKUyN5bpdUs/XVOKq4lDM7L7cN9vtnW8wQkSnKFHDcWUTfVZBi7BqBQGXY3d1v eIz00s+hNX9+yLo+DSJFNzK62rz+UTEj0bSKxgCEwaz0vJZHfyUucFVqKdPBT+7kSkm8 k0XqlZbGvqo2JtPVJpUTMskF6ANfensEjCU1ip0VottiYF6p+kl1eJFHuouZrvTOMy0/ pA7BzSQFKSRNbhmKDvzS+XCrwOXV+NOXqyCP8c4jkts8xyHMCZyi36JOQsVejQt511Sz cyNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MWoWcTTLg+kw8d2KQZwG1MRdW9zcKCL97IZQHxKOX6w=; b=MuF0P9Q4j2xIKfshZhm6p/UMlsq5QQt4JF0crSfFAXzOPVGvxeoGM6W79dCvoMSeCy Pha3oqD1yTTQa8Avz6Y9IhRGo8KY80mbqtvbtV4O877CtHM7qgPKWeWFtDktg5MMlnMY 81XegHxvq1NG0w/EelNztAkBOFQsLuC/Pxf4dnHX66M/XRngGU93DPNrXiV8nAAkkgeK WMWvcLVLqIupG+ERHgfQOYr/8G26pgWGjSCKAGx20yrle+KkwVtoTVQO8+oO47y8i9iT NvuXC444VxMdP9A3ZuSif6bKuU1N5Ke4d7Pn+TRhOxn36bOHbL1ig7eMfHpODOGas4OD EgEg== X-Gm-Message-State: AMke39m7UdLIqOxDMGW42nMj6sqiVlex6KpwyLJtYoFA9PHOnWWfhwAJGVyCJM5f3bfyy6D+XZZnH42JD09QLXjpQDafY1TXCU52CuIHOMqEQY/nkULmmLlwXhdOkFv3RzDPlsBPH2PFxu5t/jU= X-Received: by 10.31.49.81 with SMTP id x78mr6963397vkx.82.1489069636945; Thu, 09 Mar 2017 06:27:16 -0800 (PST) X-Received: by 10.31.49.81 with SMTP id x78mr6963373vkx.82.1489069636296; Thu, 09 Mar 2017 06:27:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.134.129 with HTTP; Thu, 9 Mar 2017 06:27:15 -0800 (PST) In-Reply-To: <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> References: <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> From: David Farmer Date: Thu, 9 Mar 2017 08:27:15 -0600 Message-ID: Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis To: james woodyatt Content-Type: multipart/alternative; boundary=001a114388b0b7cd25054a4d0aad Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:27:26 -0000 --001a114388b0b7cd25054a4d0aad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable James, I think both versions of the proposal significantly clarify RFC4291bis. Thank you. They both include a reference to RFC6164, however the conservative version seem to go on to deny the possibility of a /127 on-link prefix. Whereas, the liberal version seems to go on to explain that when following RFC6164 you have a 64bit IID and a /127 on-link prefix, which seems consistent with the details of RFC6164. In fact I would like to recommend that a /127 point-to-point ethernet type link be used to as an example to help clarify your on-link prefix and ND discussion in the liberal version of =C2=A72.4.8= . I think the liberal version should also clearly recommend the use of /64 on-link prefixes, while permitting on-link prefixes of any length, as it does already. I'd even go as far as saying on-link prefixes are normally /64. I feel on-link prefixes other than /64 are special cases, that have to be allowed, but are not to be used lightly and are probably not for general purpose use. So, I'd be fine with strong caveats on the use of on-link prefixes other than /64, especially with links that have nodes using SLAAC. I'd even be open to a compromise between the conservative and liberal versions, such that SLAAC, ("A" flag set in an RA) requires /64 on-link prefixes. The conservative version of the proposal at least needs to be adjusted to allow for RFC6164 /127 point-to-point router links as an exception to on-link prefixes always being /64, there seems to be a conflict here in the conservative version. I suspect it comes as no surprise, I like the liberal version of the proposal. It seems to be consistent with both /64 for SLAAC and allowing manual configuration of any on-link prefix length. It's mute on the issue of DHCPv6, I'm fine with that. But it clearly implies that DHCPv6 would use the on-link prefixes from the provided RAs. Further, the liberal version provides real meaning to the statement "IPv6 unicast routing is based on prefixes of any valid length up to 128 [BCP198]." in that on-link prefixes are allow to be any length. Where as the conservative version, still seems to be classful, at lest to me. While the liberal proposal, maybe with tweaks I suggest above, seems to successfully deal with the primary issues of controversy, at least in my opinion, there are also a few secondary issues that have come up in the discussion that I'd like to also see resolved too; 1. I think a statement about and a reference to RFC7934/BCP204 should be added to =C2=A72.1, this would be a strong addition supporting and clarifyi= ng the architectural intent of multiple addresses in IPv6. 2. I think =C2=A72.4.4 needs a more direct reference to RFC6177/BCP157, rig= ht now you get there indirectly via RFC3587 to RFC3177 which is obsoleted by 6177. The concept that a site is more than one link or subnet, and therefore a site usually need more than one /64, is an important architectural concept to convey. Especially, if you think subnet and on-link prefixes are always /64. 3. I think adding the concept that sites are not just fixed locations, but could be mobile, is also an important architectural clarification. This is extremely important in the world of 2017. This seem to best fit in =C2=A72.= 4.4 where a site is defined. 4. RFC4291bis, seem to imply the primary purpose of the exception to 64-bit IIDs for addresses that begin with binary 000 is primarily related to IPv6 address with embedded IPv4 addresses, and historically NSAP, IPX, etc... So, therefore it seems there should be a similar exception when using RFC6052, and its IPv6 addresses with IPv4 addresses embedded anywhere in global unicast, at least for the /96 option in [RFC6052]. 5. Further it seems that =C2=A72.4.5 should have a pointer to [RFC6052] as additional IPv6 addresses with embedded IPv4 addresses. Again, thank you. On Thu, Mar 9, 2017 at 2:19 AM, james woodyatt wrote: > Hi Everyone, > > This message includes my proposal to provide further clarity in the > successor to RFC 4291 on recent questions related to the length of > interface identifiers and consequently to the length of subnet prefixes a= nd > their relationship to the validity of on-link prefix determination. > > I see two possible alternatives for consideration. > > 1. In the =E2=80=9Cconservative=E2=80=9D alternative, interface identifie= rs are required > to have a standard length according to the type of link, and 64 bits is t= he > recommended length for use in future standards, citing RFC 7421. I believ= e > this to be consistent with what RFC 4291 says today, but also at variance > with what many participants would prefer and not fully consistent with wh= at > some people also say is the letter and spirit of RFC 4861 and RFC 4862 > (including the authors of those documents). > > 2. In the =E2=80=9Cliberal=E2=80=9D alternative, the length of interface = identifiers is > unspecified, and 64 bits is the RECOMMENDED length, citing RFC 7421. I > believe this to be a significant technical change to the current > requirements set by RFC 4291, with additional complications that need to = be > described and understood, but it would be more in keeping with the letter > and spirit of RFC 4861 (but not entirely with RFC 4862) and I believe mor= e > preferable to the participants who object to the current draft (and likel= y > my conservative alternative too). > > 3. In both alternatives, I=E2=80=99ve proposed a new subsection to descri= be > briefly the concept of neighbor discovery, to discuss the distinction (fr= om > RFC 5942) between subnet prefixes and on-link prefixes and their > relationships to interface identifiers. I think this will help clear up t= he > ambiguity that I discussed previously at length in a recent message to th= e > working group. > > For the record, I=E2=80=99m still very much in favor of my proposed =E2= =80=9Cconservative" > alternative, but I provide the =E2=80=9Cliberal" alternative as well in t= he hope of > offering some constructive improvement over the current draft despite my > reservations about choosing that alternative. > > Here are both sets of my proposed changes. > > =E2=80=94 Update to =C2=A72.1 Addressing Model > > Current: > > Currently, IPv6 continues the IPv4 model in that a subnet prefix is > associated with one link. Multiple subnet prefixes may be assigned to the > same link. > > Proposed (liberal and conservative): > > The relationship between links and IPv6 subnet prefixes is not the same > as in the IPv4 model. As explained in The IPv6 Subnet Model [RFC5942], th= e > most important differences are that multiple subnet prefixes may be > assigned to the same link, and that unicast addresses are not automatical= ly > associated with an on-link prefix. > > > Reasoning: RFC 5942 is Proposed Standard and without errata. Its abstract > explicitly says that IPv6 diverges from the IPv4 subnet model rather than > continuing it. This correction reflects the truth of that. This change > would also add an informative reference to RFC 5942. > > =E2=80=94 Update to =C2=A72.2.2 Text Representation of Address Prefixes > > Current: > > When writing both a node address and a prefix of that node address > (e.g., the node's subnet prefix), the two can be combined as follows: > > > > the node address 2001:0db8:0:cd30:123:4567:89ab:cdef > > and its subnet number 2001:0db8:0:cd30::/60 > > Proposed (liberal and conservative): > > When writing both a node address and a prefix of that node address, the > two can be combined as follows: > > > > the node address 2001:0db8:0:cd30:123:4567:89ab:cdef > > and its prefix 2001:0db8:0:cd30::/60 > > Reasoning: eliding the example of =E2=80=9Csubnet prefix=E2=80=9D here av= oids the > suggestion that link types have already been defined (at the time of > publication) for which 68 bits is a valid length for interface identifier= s. > > =E2=80=94 Update to =C2=A72.4 Unicast Addresses > > Current: > > IPv6 unicast routing is based on prefixes of any valid length up to 128 > [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on > inter-router point-to-point links. However, the Interface ID of all unica= st > addresses, except those that start with the binary value 000, is required > to be 64 bits long. The rationale for the 64 bit boundary in IPv6 > addresses can be found in [RFC7421] > > Proposed (liberal and conservative): > > IPv6 unicast routing is based on prefixes of any valid length up to 128 > [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on > inter-router point-to-point links. > > Reasoning: In the current text, the sentence beginning with =E2=80=9CHowe= ver,=E2=80=9D > uses the phrase =E2=80=9CInterface ID=E2=80=9D before it is adequately de= fined (along with > the concept of the subnet prefix) in the subsequent text. (See below, whe= re > the elided language in this paragraph is restored in the conservative > alternative.) > > Current: > > A slightly sophisticated host (but still rather simple) may additionall= y > be aware of subnet prefix(es) for the link(s) it is attached to, where > different addresses may have different values for n: > > > > | n bits | 128-n bits | > > +-------------------------------+---------------------------------+ > > | subnet prefix | interface ID | > > +-------------------------------+---------------------------------+ > > Proposed (conservative): > > A slightly sophisticated node (e.g. one capable of neighbor discovery) > may additionally be aware of subnet prefix(es) for the link(s) to which i= t > attaches, where the length (n) of the interface ID field may vary with > different types of link: > > > > | 128-n bits | n bits | > > +-------------------------------+---------------------------------+ > > | subnet prefix | interface ID | > > +-------------------------------+---------------------------------+ > > > > Note: according to the reasoning presented in Analysis of the 64-bit > Boundary in IPv6 Addressing [RFC7421], the length of the Interface ID fie= ld > in all unicast IPv6 addresses is 64 bits, except for addresses beginning > with binary value 000 and except in cases where otherwise specified in > future IETF standard actions. > > Reasoning: this (conservative) change clarifies that interface identifier= s > have a length that is a function of the link type, which defines the leng= th > of the interface identifier, which is a constant for all links of that > type. And it cites RFC 7421 to explain why 64 bits is required for most > interface identifiers. And it replaces =E2=80=9Chost=E2=80=9D with =E2=80= =9Cnode=E2=80=9D in one case where > that=E2=80=99s more accurate. > > Proposed (liberal): > > A slightly sophisticated node (e.g. capable of neighbor discovery) may > additionally be aware of subnet prefix(es) for the link(s) to which it > attaches, where the length (n) of the interface ID field may vary for eac= h > subnet prefix: > > > > | 128-n bits | n bits | > > +-------------------------------+---------------------------------+ > > | subnet prefix | interface ID | > > +-------------------------------+---------------------------------+ > > > > Note: according to the reasoning presented in Analysis of the 64-bit > Boundary in IPv6 Addressing [RFC7421], interface identifiers are > recommended to be 64 bits in length. > > Reasoning: this (liberal) change relaxes the requirement that interface > identifiers have any fixed length, citing RFC 7421 to recommend 64 bits > (but not require it). And it replaces =E2=80=9Chost=E2=80=9D with =E2=80= =9Cnode=E2=80=9D in one case where > that=E2=80=99s more accurate. > > =E2=80=94 Update to =C2=A72.4.1 Interface Identifiers > > Current: > > Interface identifiers in IPv6 unicast addresses are used to identify > interfaces on a link. They are required to be unique within a subnet > prefix. It is recommended that the same interface identifier not be > assigned to different nodes on a link. They may also be unique over a > broader scope. The same interface identifier may be used on multiple > interfaces on a single node, as long as they are attached to different > subnets. > > Proposed (conservative): > > Interface identifiers in IPv6 unicast addresses are used to identify > interfaces on a link. They are required to be of a standard length for th= e > type of the link and unique among all the nodes on the link using the sam= e > subnet prefix. It is recommended that the same interface identifier not b= e > assigned to different nodes on the same link. They may also be unique ove= r > a broader scope. The same interface identifier may be used on multiple > interfaces on a single node, as long as they are used with different subn= et > prefixes. > > Reasoning: this (conservative) change improves clarity by ensuring the > term =E2=80=9Csubnet=E2=80=9D is always used in the phrase =E2=80=9Csubne= t prefix=E2=80=9D and not as a > shorthand for a subset of the nodes on a link using addresses that share > the same subnet prefix. It also clarifies that standards dictate the vali= d > length(s) of interface identifiers for each link type. > > Proposed (liberal): > > Interface identifiers in IPv6 unicast addresses are used to identify > interfaces on a link. They are required to be unique among all the nodes = on > the link using the same subnet prefix. It is recommended that the same > interface identifier not be assigned to different nodes on a link. They m= ay > also be unique over a broader scope. The same interface identifier may be > used on multiple interfaces on a single node, as long as they are used wi= th > different subnet prefixes. > > Reasoning: this (liberal) change only improves clarity by ensuring the > term =E2=80=9Csubnet=E2=80=9D is always used in the phrase =E2=80=9Csubne= t prefix=E2=80=9D and not as a > shorthand for a subset of the nodes on a link using addresses that share > the same subnet prefix. It leaves open the variable length of interface > identifiers. > > =E2=80=94 Update to =C2=A72.4.4 Global Unicast Addresses > > Current: > > The general format for IPv6 Global Unicast addresses is as follows: > > > > | n bits | m bits | 128-n-m bits | > > +------------------------+-----------+----------------------------+ > > | global routing prefix | subnet ID | interface ID | > > +------------------------+-----------+----------------------------+ > > > > where the global routing prefix is a (typically > hierarchically-structured) value assigned to a site (a cluster of > subnets/links), the subnet ID is an identifier of a link within the site, > and the interface ID is as defined in Section 2.4.1. > > > > As noted in Section 2.4, all Global Unicast addresses other than those > that start with binary 000 have a 64-bit interface ID field (i.e., n + m = =3D > 64), formatted as described in Section 2.4.1. Global Unicast addresses th= at > start with binary 000 have no such constraint on the size or structure of > the interface ID field. > > > > Examples of Global Unicast addresses that start with binary 000 are the > IPv6 address with embedded IPv4 addresses described in Section 2.4.5. An > example of global addresses starting with a binary value other than 000 > (and therefore having a 64-bit interface ID field) can be found in > [RFC3587]. > > Proposed (conservative): > > The general format for IPv6 Global Unicast addresses is as follows: > > > > | 128-n-m bits | m bits | n bits | > > +------------------------+-----------+----------------------------+ > > | global routing prefix | subnet ID | interface ID | > > +------------------------+-----------+----------------------------+ > > > > where the global routing prefix is a (typically > hierarchically-structured) value assigned to a site (a cluster of subnet > prefixes assigned to links), the subnet ID is an identifier of a link > within the site, and the interface ID is as defined in Section 2.4.1. > > > > As noted in Section 2.4, all Global Unicast addresses other than those > that start with binary 000 have a 64-bit interface ID field (i.e., n =3D = 64), > formatted as described in Section 2.4.1. Global Unicast addresses that > start with binary 000 have no such constraint on the size or structure of > the interface ID field. > > > > Examples of Global Unicast addresses that start with binary 000 are the > IPv6 address with embedded IPv4 addresses described in Section 2.4.5. An > example of global addresses starting with a binary value other than 000 > (and therefore having a 64-bit interface ID field) can be found in > [RFC3587]. > > Reasoning: the only changes here are to make the field headings in the > structure diagram consistent with those proposed for the similar diagram = in > =C2=A72.4, to use =E2=80=9Csubnet=E2=80=9D only in the phrase =E2=80=9Csu= bnet prefix=E2=80=9D and not as cognate > of link, and to update the explanatory parenthetical in the second > paragraph, =E2=80=9C(i.e. n =3D 64)=E2=80=9D, to reflect it accordingly. > > Proposed (liberal): > > The general format for IPv6 Global Unicast addresses is as follows: > > > > | 128-n-m bits | m bits | n bits | > > +------------------------+-----------+----------------------------+ > > | global routing prefix | subnet ID | interface ID | > > +------------------------+-----------+----------------------------+ > > > > where the global routing prefix is a (typically > hierarchically-structured) value assigned to a site (a cluster of subnet > prefixes assigned to links), the subnet ID is an identifier of a link > within the site, and the interface ID is as defined in Section 2.4.1. > > Reasoning: the field headings in the structure diagram are made consisten= t > with those for the similar diagram in =C2=A72.4, and the two final paragr= aphs > about addresses that start with binary 000 are elided in accordance with > the proposed (liberal) change to =C2=A72.4. Also, the word =E2=80=9Csubne= t=E2=80=9D is used > properly in the phrase =E2=80=9Csubnet prefix=E2=80=9D where it is more c= learly defined. > > =E2=80=94 Insertion of =C2=A72.4.8 Neighbor Discovery > > Proposed (conservative): > > Nodes can send packets directly to other nodes with interfaces on the > same link, without forwarding by a router, when they can identify the > link-layer addresses associated with the unicast IPv6 addresses that shar= e > on-link subnet prefixes assigned to the interface. Neighbor discovery is > conceptually the process of resolving such associations as necessary. > > > > Nodes may be configured manually with on-link subnet prefixes for each > of their interfaces. Also, routers may inform hosts automatically of the > set of on-link subnet prefixes by a process related to neighbor discovery= . > Nodes sending packets to unicast addresses with subnet prefixes that are > not on-link must direct those packets to a router for forwarding to their > destination. > > > > Every on-link prefix is a subnet prefix, and subnet prefixes for all > global unicast addresses beginning with a binary value other than 000 are > required according to Section 2.4 to be 64 bits in length. > > > Reasoning: this text provides clarification that on-link prefixes are > subnet prefixes for which neighbor discovery can be used by nodes to > communicate directly without forwarding packets through a router. It also > repeats the requirement that all subnet prefixes other than those beginni= ng > with 0b000 are 64 bits long. > > Proposed (liberal): > > Nodes can send packets directly to other nodes with interfaces on the > same link, without forwarding by a router, when they can identify the > link-layer addresses associated with the unicast IPv6 addresses that shar= e > on-link prefixes assigned to the interface. Neighbor discovery is > conceptually the process of resolving such associations as necessary. > > > > > Nodes may be configured manually with on-link prefixes for each of thei= r > interfaces. Also, routers may inform hosts automatically of the set of > on-link prefixes by a process related to neighbor discovery. Nodes sendin= g > packets to unicast addresses without an on-link prefix must direct those > packets to a router for forwarding to their destination. > > > > An important distinction is made between subnet prefixes, which are > defined in Section 2.4 as the part of a unicast address that precedes the > interface identifier, and on-link prefixes which do not necessarily have > structure in the part of unicast addresses that follows them. In > particular, an on-link prefix may be shorter than the one or more subnet > prefixes that share it, in which case the part that follows the on-link > prefix consists of some additional bits that precede the interface > identifier. Likewise, an on-link prefix may be longer than a subnet prefi= x > it shares with one or more other on-link prefixes, in which case the part > that follows the on-link prefix is only a portion of an interface > identifier and hence may not itself necessarily have all the properties o= f > an interface identifier as defined in Section 2.4.1, therefore it must no= t > be used alone, in that case, to identify an interface on a link. > > Reasoning: this text is similar to the text in the conservative > alternative except that it does not assert that every on-link prefix is a > subnet prefix or specify any requirement for the length of either on-link > or subnet prefixes. However, it does include an additional paragraph that > discusses the necessary distinction between on-link and subnet prefixes i= n > substantial detail, and it forbids the use of the part of a unicast addre= ss > following an on-link prefix as identification for an interface on a link > unless it is sufficiently long to meet the requirements of =C2=A72.4. > > =E2=80=94 Update to =C2=A72.5 Anycast Addresses > > Current: > > Some other possible uses are to identify the set of routers attached to > a particular subnet, or the set of routers providing entry into a > particular routing domain. > > Proposed (liberal and conservative): > > Some other possible uses are to identify the set of routers attached to > a link for use by nodes at addresses sharing a particular subnet prefix, = or > to identify the set of routers providing entry into a particular routing > domain. > > Reasoning: this change improves clarity by ensuring the term =E2=80=9Csub= net=E2=80=9D is > always used in the phrase =E2=80=9Csubnet prefix=E2=80=9D and not as a sh= orthand for a > subset of the nodes on a link using addresses that share the same subnet > prefix. > > =E2=80=94 Update to =C2=A72.5.1 Required Anycast Address > > Current: > > 2.5.1. Required Anycast Address > > > > > The Subnet-Router anycast address is predefined. Its format is as > follows: > > > > | n bits | 128-n bits | > > +------------------------------------------------+----------------+ > > | subnet prefix | 00000000000000 | > > +------------------------------------------------+----------------+ > > > > The "subnet prefix" in an anycast address is the prefix that identifies > a specific link. This anycast address is syntactically the same as a > unicast address for an interface on the link with the interface identifie= r > set to zero. > > > > Packets sent to the Subnet-Router anycast address will be delivered to > one router on the subnet. All routers are required to support the > Subnet-Router anycast addresses for the subnets to which they have > interfaces. > > Proposed (liberal and conservative): > > 2.5.1. Subnet-Router Anycast Address > > > > The Subnet-Router anycast address is predefined for each subnet prefix. > Its structure, as shown below, is the same as a unicast address with the > same subnet prefix and with zero for the interface identifier. > > > > | 128-n bits | n bits | > > +------------------------------------------------+----------------+ > > | subnet prefix | 00000000000000 | > > +------------------------------------------------+----------------+ > > > > Packets sent to the Subnet-Router anycast address are destined for any > router on the link that is assigned a unicast address with the > corresponding subnet prefix. All routers are required to assign > Subnet-Router anycast addresses to their interfaces for each subnet prefi= x > used on the link. > > Reasoning: this change (which is essentially a complete rewrite of =C2=A7= 2.5.1) > improves clarity by making the field headers in the structure diagram > consistent with =C2=A72.4, and by ensuring the term =E2=80=9Csubnet=E2=80= =9D is always used in > the phrase =E2=80=9Csubnet prefix=E2=80=9D and not as a shorthand for a s= ubset of the nodes > on a link using addresses that share the same subnet prefix. > > Commentary: it=E2=80=99s not clear to me what is the real purpose of the > Subnet-Router anycast address, even in the conservative case, but > especially so in the liberal case where on-link prefixes are not required > to have the same length as subnet prefixes. It seems okay that a single > Subnet-Router anycast address should be defined as the destination for an= y > router with an address where more than one on-link prefix has a shorter > subnet prefix in common. It seems much less okay that multiple > Subnet-Router anycast addresses should be defined as destinations for any > router with addresses having more than one subnet prefix sharing a common > on-link prefix. Still, I don=E2=80=99t see how it breaks anything importa= nt, so I'm > saying: let's try not to do any further damage. > > =E2=80=94=E2=80=94 > > In summary, I believe when publishing the successor to RFC 4291 it may be > possible for IETF to further clarify the IPv6 address architecture so tha= t > controversies over the validity of on-link prefixes used in neighbor > discovery do not arise, either A) in the conservative case, because all > on-link prefixes are also subnet prefixes and subnet prefixes are > constrained to standard size(s) for each link type and to 64 bits for all > prefixes beginning with 0b000, or B) in the liberal case, because neither > on-link prefixes nor subnet prefixes are constrained to any standard size > nor even required to be the same length. > > I hope this proposal will be seen correctly as my sincere attempt to > provide a constructive basis for resolving this ongoing controversy into = a > rough consensus. > > > --james woodyatt > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114388b0b7cd25054a4d0aad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    James,

    I think both versions of the pro= posal significantly clarify RFC4291bis.=C2=A0 Thank you.

    They both include a reference to RFC6164, however the=C2=A0conservative version seem to go on to deny the poss= ibility of a /127 on-link prefix.=C2=A0 Whereas, the liberal version seems = to go on to explain that when following=C2=A0RFC6164 you have a 64bi= t IID and a /127 on-link prefix, which seems consistent with the details of= RFC6164.=C2=A0 In fact I would like to recommend that a /127 point-to-poin= t ethernet type link=C2=A0be used to as an= example to help clarify your on-link prefix and ND discussion=C2=A0in the = liberal version of =C2=A72.4.8.=C2=A0

    I thi= nk the liberal version should also clearly recommend the use of /64 on-link= prefixes, while permitting on-link prefixes of any length, as it does=C2= =A0already. I'd even go as far as saying on-link prefixes are normally = /64. I feel on-link prefixes other than /64 are special cases, that have to= be allowed, but are not to be used lightly and are probably not for genera= l purpose use.=C2=A0 So, I'd be fine with strong caveats on the use of = on-link prefixes other than /64, especially with links that have nodes usin= g SLAAC. I'd even be open to a compromise between the conservative and = liberal versions, such that SLAAC, ("A" flag set in an RA) requir= es /64 on-link prefixes.

    The=C2=A0conservative version of the proposal at least needs to be = adjusted to allow for=C2=A0RFC6164 /127 point-to-point router links = as an exception to on-link prefixes always being /64, there seems to be a c= onflict here in the conservative version.<= /span>

    I suspect it comes as no surprise, I like t= he liberal version of the proposal.=C2=A0 It seems to be consistent with bo= th /64 for SLAAC and allowing manual configuration of any on-link prefix le= ngth.=C2=A0 It's mute on the issue of DHCPv6, I'm fine with that.= =C2=A0 But it clearly implies that DHCPv6 would use the on-link prefixes fr= om the provided RAs. Further, the liberal version provides real meaning to = the statement "IPv6 unicast routing i= s based on prefixes of any valid length up to 128 [BCP198]."=C2= =A0in that on-link prefixes are allow to be any length.=C2=A0 Where as the = conservative version, still seems to be classful, at lest to me.
    =
    While the liberal proposal, maybe with tweaks I suggest abov= e, seems to successfully deal with the primary issues of controversy, at le= ast in my opinion, there are also a few secondary issues that have come up = in the discussion that I'd like to also see resolved too;
    1. I think a statement about and a reference to RFC7934/BCP204 = should be added to=C2=A0=C2=A72.1, this wo= uld be a strong=C2=A0addition supporting and clarifying the architectural i= ntent of multiple addresses in IPv6.=C2=A0=C2=A0=C2=A0

    2. I think=C2=A0=C2=A72.4.4 needs a more direct reference=C2=A0to= RFC6177/BCP157, right now you get there indirectly via RFC3587 to RFC3177 = which is obsoleted by 6177.=C2=A0 The concept that a site is more than one = link or subnet, and therefore=C2=A0a site usually=C2=A0need more than one /= 64, is an important architectural=C2=A0concept to convey.=C2=A0 Especially,= if you think subnet and on-link prefixes are always /64.=C2=A0

    3. I think adding the concept that sites are not just fi= xed locations, but could be mobile, is also an important=C2=A0architectural= clarification. This is extremely important in the world of 2017. This seem= to best fit in=C2=A0=C2=A72.4.4=C2=A0where a site is defined.<= /div>

    4. RFC4291bis, seem to imply the primary purpose of = the exception to 64-bit IIDs for addresses=C2=A0that begin with binary 000 = is primarily related to=C2=A0IPv6 address with embedded IPv4 addresses, and histori= cally NSAP, IPX, etc...=C2=A0 So, therefore it seems there should be a simi= lar exception=C2=A0when using RFC6052, and its IPv6 addresses with IPv4 add= resses=C2=A0embedded anywhere in global unicast, at least for the /96 option in [RF= C6052].

    5. Further it seems that =C2=A72.4.5 should have a pointer to=C2=A0[RFC6052] as additional IPv6 addre= sses with=C2=A0embedded IPv4 addresses.

    =C2=A0Again, thank you.


    On Thu, = Mar 9, 2017 at 2:19 AM, james woodyatt <jhw@google.com> wrote:<= br>
    Hi Everyone,

    This message includes my proposal to provide further clarity in the success= or to RFC 4291 on recent questions related to the length of interface ident= ifiers and consequently to the length of subnet prefixes and their relation= ship to the validity of on-link prefix determination.

    I see two possible alternatives for consideration.

    1. In the =E2=80=9Cconservative=E2=80=9D alternative, interface identifiers= are required to have a standard length according to the type of link, and = 64 bits is the recommended length for use in future standards, citing RFC 7= 421. I believe this to be consistent with what RFC 4291 says today, but als= o at variance with what many participants would prefer and not fully consis= tent with what some people also say is the letter and spirit of RFC 4861 an= d RFC 4862 (including the authors of those documents).

    2. In the =E2=80=9Cliberal=E2=80=9D alternative, the length of interface id= entifiers is unspecified, and 64 bits is the RECOMMENDED length, citing RFC= 7421. I believe this to be a significant technical change to the current r= equirements set by RFC 4291, with additional complications that need to be = described and understood, but it would be more in keeping with the letter a= nd spirit of RFC 4861 (but not entirely with RFC 4862) and I believe more p= referable to the participants who object to the current draft (and likely m= y conservative alternative too).

    3. In both alternatives, I=E2=80=99ve proposed a new subsection to describe= briefly the concept of neighbor discovery, to discuss the distinction (fro= m RFC 5942) between subnet prefixes and on-link prefixes and their relation= ships to interface identifiers. I think this will help clear up the ambigui= ty that I discussed previously at length in a recent message to the working= group.

    For the record, I=E2=80=99m still very much in favor of my proposed =E2=80= =9Cconservative" alternative, but I provide the =E2=80=9Cliberal"= alternative as well in the hope of offering some constructive improvement = over the current draft despite my reservations about choosing that alternat= ive.

    Here are both sets of my proposed changes.

    =E2=80=94 Update to =C2=A72.1 Addressing Model

    Current:
    > Currently, IPv6 continues the IPv4 model in that a subnet prefix is as= sociated with one link. Multiple subnet prefixes may be assigned to the sam= e link.

    Proposed (liberal and conservative):
    > The relationship between links and IPv6 subnet prefixes is not the sam= e as in the IPv4 model. As explained in The IPv6 Subnet Model [RFC5942], th= e most important differences are that multiple subnet prefixes may be assig= ned to the same link, and that unicast addresses are not automatically asso= ciated with an on-link prefix.


    Reasoning: RFC 5942 is Proposed Standard and without errata. Its abstract e= xplicitly says that IPv6 diverges from the IPv4 subnet model rather than co= ntinuing it. This correction reflects the truth of that. This change would = also add an informative reference to RFC 5942.

    =E2=80=94 Update to =C2=A72.2.2 Text Representation of Address Prefixes

    Current:
    > When writing both a node address and a prefix of that node address (e.= g., the node's subnet prefix), the two can be combined as follows:
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0the node address=C2=A0 =C2=A0 =C2=A0 =C2=A0 = 2001:0db8:0:cd30:123:4567:89ab:cdef
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0and its subnet number=C2=A0 =C2=A02001:0db8:= 0:cd30::/60

    Proposed (liberal and conservative):
    > When writing both a node address and a prefix of that node address, th= e two can be combined as follows:
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0the node address=C2=A0 =C2=A0 =C2=A0 =C2=A0 = 2001:0db8:0:cd30:123:4567:89ab:cdef
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0and its prefix=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 2001:0db8:0:cd30::/60

    Reasoning: eliding the example of =E2=80=9Csubnet prefix=E2=80=9D here avoi= ds the suggestion that link types have already been defined (at the time of= publication) for which 68 bits is a valid length for interface identifiers= .

    =E2=80=94 Update to =C2=A72.4 Unicast Addresses

    Current:
    > IPv6 unicast routing is based on prefixes of any valid length up to 12= 8 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on inter-r= outer point-to-point links. However, the Interface ID of all unicast addres= ses, except those that start with the binary value 000, is required to be 6= 4 bits long.=C2=A0 The rationale for the 64 bit boundary in IPv6 addresses = can be found in [RFC7421]

    Proposed (liberal and conservative):
    > IPv6 unicast routing is based on prefixes of any valid length up to 12= 8 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on inter-r= outer point-to-point links.

    Reasoning: In the current text, the sentence beginning with =E2=80=9CHoweve= r,=E2=80=9D uses the phrase =E2=80=9CInterface ID=E2=80=9D before it is ade= quately defined (along with the concept of the subnet prefix) in the subseq= uent text. (See below, where the elided language in this paragraph is resto= red in the conservative alternative.)

    Current:
    > A slightly sophisticated host (but still rather simple) may additional= ly be aware of subnet prefix(es) for the link(s) it is attached to, where d= ifferent addresses may have different values for n:
    >
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n bits=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0128-n bits=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    >=C2=A0 =C2=A0 +-------------------------------+-------------------= --------------+
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0subnet prefix=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interf= ace ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    >=C2=A0 =C2=A0 +-------------------------------+-------------------= --------------+

    Proposed (conservative):
    > A slightly sophisticated node (e.g. one capable of neighbor discovery)= may additionally be aware of subnet prefix(es) for the link(s) to which it= attaches, where the length (n) of the interface ID field may vary with dif= ferent types of link:
    >
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0128-n bits=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n= bits=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    >=C2=A0 =C2=A0 +-------------------------------+-------------------= --------------+
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0subnet prefix=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interf= ace ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    >=C2=A0 =C2=A0 +-------------------------------+-------------------= --------------+
    >
    > Note: according to the reasoning presented in Analysis of the 64-bit B= oundary in IPv6 Addressing [RFC7421], the length of the Interface ID field = in all unicast IPv6 addresses is 64 bits, except for addresses beginning wi= th binary value 000 and except in cases where otherwise specified in future= IETF standard actions.

    Reasoning: this (conservative) change clarifies that interface identifiers = have a length that is a function of the link type, which defines the length= of the interface identifier, which is a constant for all links of that typ= e. And it cites RFC 7421 to explain why 64 bits is required for most interf= ace identifiers. And it replaces =E2=80=9Chost=E2=80=9D with =E2=80=9Cnode= =E2=80=9D in one case where that=E2=80=99s more accurate.

    Proposed (liberal):
    > A slightly sophisticated node (e.g. capable of neighbor discovery) may= additionally be aware of subnet prefix(es) for the link(s) to which it att= aches, where the length (n) of the interface ID field may vary for each sub= net prefix:
    >
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0128-n bits=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n= bits=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    >=C2=A0 =C2=A0 +-------------------------------+-------------------= --------------+
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0subnet prefix=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interf= ace ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    >=C2=A0 =C2=A0 +-------------------------------+-------------------= --------------+
    >
    > Note: according to the reasoning presented in Analysis of the 64-bit B= oundary in IPv6 Addressing [RFC7421], interface identifiers are recommended= to be 64 bits in length.

    Reasoning: this (liberal) change relaxes the requirement that interface ide= ntifiers have any fixed length, citing RFC 7421 to recommend 64 bits (but n= ot require it). And it replaces =E2=80=9Chost=E2=80=9D with =E2=80=9Cnode= =E2=80=9D in one case where that=E2=80=99s more accurate.

    =E2=80=94 Update to =C2=A72.4.1 Interface Identifiers

    Current:
    > Interface identifiers in IPv6 unicast addresses are used to identify i= nterfaces on a link. They are required to be unique within a subnet prefix.= It is recommended that the same interface identifier not be assigned to di= fferent nodes on a link. They may also be unique over a broader scope. The = same interface identifier may be used on multiple interfaces on a single no= de, as long as they are attached to different subnets.

    Proposed (conservative):
    > Interface identifiers in IPv6 unicast addresses are used to identify i= nterfaces on a link. They are required to be of a standard length for the t= ype of the link and unique among all the nodes on the link using the same s= ubnet prefix. It is recommended that the same interface identifier not be a= ssigned to different nodes on the same link. They may also be unique over a= broader scope. The same interface identifier may be used on multiple inter= faces on a single node, as long as they are used with different subnet pref= ixes.

    Reasoning: this (conservative) change improves clarity by ensuring the term= =E2=80=9Csubnet=E2=80=9D is always used in the phrase =E2=80=9Csubnet pref= ix=E2=80=9D and not as a shorthand for a subset of the nodes on a link usin= g addresses that share the same subnet prefix. It also clarifies that stand= ards dictate the valid length(s) of interface identifiers for each link typ= e.

    Proposed (liberal):
    > Interface identifiers in IPv6 unicast addresses are used to identify i= nterfaces on a link. They are required to be unique among all the nodes on = the link using the same subnet prefix. It is recommended that the same inte= rface identifier not be assigned to different nodes on a link. They may als= o be unique over a broader scope. The same interface identifier may be used= on multiple interfaces on a single node, as long as they are used with dif= ferent subnet prefixes.

    Reasoning: this (liberal) change only improves clarity by ensuring the term= =E2=80=9Csubnet=E2=80=9D is always used in the phrase =E2=80=9Csubnet pref= ix=E2=80=9D and not as a shorthand for a subset of the nodes on a link usin= g addresses that share the same subnet prefix. It leaves open the variable = length of interface identifiers.

    =E2=80=94 Update to =C2=A72.4.4 Global Unicast Addresses

    Current:
    > The general format for IPv6 Global Unicast addresses is as follows: >
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n bits=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0m bits=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= 128-n-m bits=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    >=C2=A0 =C2=A0 +------------------------+-----------+--------------= --------------+
    >=C2=A0 =C2=A0 | global routing prefix=C2=A0 | subnet ID |=C2=A0 =C2=A0 = =C2=A0 =C2=A0interface ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    >=C2=A0 =C2=A0 +------------------------+-----------+--------------= --------------+
    >
    > where the global routing prefix is a (typically hierarchically-structu= red) value assigned to a site (a cluster of subnets/links), the subnet ID i= s an identifier of a link within the site, and the interface ID is as defin= ed in Section 2.4.1.
    >
    > As noted in Section 2.4, all Global Unicast addresses other than those= that start with binary 000 have a 64-bit interface ID field (i.e., n + m = =3D 64), formatted as described in Section 2.4.1. Global Unicast addresses = that start with binary 000 have no such constraint on the size or structure= of the interface ID field.
    >
    > Examples of Global Unicast addresses that start with binary 000 are th= e IPv6 address with embedded IPv4 addresses described in Section 2.4.5. An = example of global addresses starting with a binary value other than 000 (an= d therefore having a 64-bit interface ID field) can be found in [RFC3587].<= br>
    Proposed (conservative):
    > The general format for IPv6 Global Unicast addresses is as follows: >
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0128-n-m bits=C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0m bits=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0n bits=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    >=C2=A0 =C2=A0 +------------------------+-----------+--------------= --------------+
    >=C2=A0 =C2=A0 | global routing prefix=C2=A0 | subnet ID |=C2=A0 =C2=A0 = =C2=A0 =C2=A0interface ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    >=C2=A0 =C2=A0 +------------------------+-----------+--------------= --------------+
    >
    > where the global routing prefix is a (typically hierarchically-structu= red) value assigned to a site (a cluster of subnet prefixes assigned to lin= ks), the subnet ID is an identifier of a link within the site, and the inte= rface ID is as defined in Section 2.4.1.
    >
    > As noted in Section 2.4, all Global Unicast addresses other than those= that start with binary 000 have a 64-bit interface ID field (i.e., n =3D 6= 4), formatted as described in Section 2.4.1. Global Unicast addresses that = start with binary 000 have no such constraint on the size or structure of t= he interface ID field.
    >
    > Examples of Global Unicast addresses that start with binary 000 are th= e IPv6 address with embedded IPv4 addresses described in Section 2.4.5. An = example of global addresses starting with a binary value other than 000 (an= d therefore having a 64-bit interface ID field) can be found in [RFC3587].<= br>
    Reasoning: the only changes here are to make the field headings in the stru= cture diagram consistent with those proposed for the similar diagram in =C2= =A72.4, to use =E2=80=9Csubnet=E2=80=9D only in the phrase =E2=80=9Csubnet = prefix=E2=80=9D and not as cognate of link, and to update the explanatory p= arenthetical in the second paragraph, =E2=80=9C(i.e. n =3D 64)=E2=80=9D, to= reflect it accordingly.

    Proposed (liberal):
    > The general format for IPv6 Global Unicast addresses is as follows: >
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0128-n-m bits=C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0m bits=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0n bits=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    >=C2=A0 =C2=A0 +------------------------+-----------+--------------= --------------+
    >=C2=A0 =C2=A0 | global routing prefix=C2=A0 | subnet ID |=C2=A0 =C2=A0 = =C2=A0 =C2=A0interface ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    >=C2=A0 =C2=A0 +------------------------+-----------+--------------= --------------+
    >
    > where the global routing prefix is a (typically hierarchically-structu= red) value assigned to a site (a cluster of subnet prefixes assigned to lin= ks), the subnet ID is an identifier of a link within the site, and the inte= rface ID is as defined in Section 2.4.1.

    Reasoning: the field headings in the structure diagram are made consistent = with those for the similar diagram in =C2=A72.4, and the two final paragrap= hs about addresses that start with binary 000 are elided in accordance with= the proposed (liberal) change to =C2=A72.4. Also, the word =E2=80=9Csubnet= =E2=80=9D is used properly in the phrase =E2=80=9Csubnet prefix=E2=80=9D wh= ere it is more clearly defined.

    =E2=80=94 Insertion of =C2=A72.4.8 Neighbor Discovery

    Proposed (conservative):
    > Nodes can send packets directly to other nodes with interfaces on the = same link, without forwarding by a router, when they can identify the link-= layer addresses associated with the unicast IPv6 addresses that share on-li= nk subnet prefixes assigned to the interface. Neighbor discovery is concept= ually the process of resolving such associations as necessary.
    >
    > Nodes may be configured manually with on-link subnet prefixes for each= of their interfaces. Also, routers may inform hosts automatically of the s= et of on-link subnet prefixes by a process related to neighbor discovery. N= odes sending packets to unicast addresses with subnet prefixes that are not= on-link must direct those packets to a router for forwarding to their dest= ination.
    >
    > Every on-link prefix is a subnet prefix, and subnet prefixes for all g= lobal unicast addresses beginning with a binary value other than 000 are re= quired according to Section 2.4 to be 64 bits in length.


    Reasoning: this text provides clarification that on-link prefixes are subne= t prefixes for which neighbor discovery can be used by nodes to communicate= directly without forwarding packets through a router. It also repeats the = requirement that all subnet prefixes other than those beginning with 0b000 = are 64 bits long.

    Proposed (liberal):
    > Nodes can send packets directly to other nodes with interfaces on the = same link, without forwarding by a router, when they can identify the link-= layer addresses associated with the unicast IPv6 addresses that share on-li= nk prefixes assigned to the interface. Neighbor discovery is conceptually t= he process of resolving such associations as necessary.

    >
    > Nodes may be configured manually with on-link prefixes for each of the= ir interfaces. Also, routers may inform hosts automatically of the set of o= n-link prefixes by a process related to neighbor discovery. Nodes sending p= ackets to unicast addresses without an on-link prefix must direct those pac= kets to a router for forwarding to their destination.
    >
    > An important distinction is made between subnet prefixes, which are de= fined in Section 2.4 as the part of a unicast address that precedes the int= erface identifier, and on-link prefixes which do not necessarily have struc= ture in the part of unicast addresses that follows them. In particular, an = on-link prefix may be shorter than the one or more subnet prefixes that sha= re it, in which case the part that follows the on-link prefix consists of s= ome additional bits that precede the interface identifier. Likewise, an on-= link prefix may be longer than a subnet prefix it shares with one or more o= ther on-link prefixes, in which case the part that follows the on-link pref= ix is only a portion of an interface identifier and hence may not itself ne= cessarily have all the properties of an interface identifier as defined in = Section 2.4.1, therefore it must not be used alone, in that case, to identi= fy an interface on a link.

    Reasoning: this text is similar to the text in the conservative alternative= except that it does not assert that every on-link prefix is a subnet prefi= x or specify any requirement for the length of either on-link or subnet pre= fixes. However, it does include an additional paragraph that discusses the = necessary distinction between on-link and subnet prefixes in substantial de= tail, and it forbids the use of the part of a unicast address following an = on-link prefix as identification for an interface on a link unless it is su= fficiently long to meet the requirements of =C2=A72.4.

    =E2=80=94 Update to =C2=A72.5 Anycast Addresses

    Current:
    > Some other possible uses are to identify the set of routers attached t= o a particular subnet, or the set of routers providing entry into a particu= lar routing domain.

    Proposed (liberal and conservative):
    > Some other possible uses are to identify the set of routers attached t= o a link for use by nodes at addresses sharing a particular subnet prefix, = or to identify the set of routers providing entry into a particular routing= domain.

    Reasoning: this change improves clarity by ensuring the term =E2=80=9Csubne= t=E2=80=9D is always used in the phrase =E2=80=9Csubnet prefix=E2=80=9D and= not as a shorthand for a subset of the nodes on a link using addresses tha= t share the same subnet prefix.

    =E2=80=94 Update to =C2=A72.5.1 Required Anycast Address

    Current:
    > 2.5.1.=C2=A0 Required Anycast Address
    >

    > The Subnet-Router anycast address is predefined. Its format is as foll= ows:
    >
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n bits=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0128-n bits=C2=A0 =C2=A0|
    >=C2=A0 =C2=A0 +------------------------------------------------+--= --------------+
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0subnet prefix=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | 00000000000000 |
    >=C2=A0 =C2=A0 +------------------------------------------------+--= --------------+
    >
    > The "subnet prefix" in an anycast address is the prefix that= identifies a specific link. This anycast address is syntactically the same= as a unicast address for an interface on the link with the interface ident= ifier set to zero.
    >
    > Packets sent to the Subnet-Router anycast address will be delivered to= one router on the subnet. All routers are required to support the Subnet-R= outer anycast addresses for the subnets to which they have interfaces.

    Proposed (liberal and conservative):
    > 2.5.1.=C2=A0 Subnet-Router Anycast Address
    >
    > The Subnet-Router anycast address is predefined for each subnet prefix= . Its structure, as shown below, is the same as a unicast address with the = same subnet prefix and with zero for the interface identifier.
    >
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 128-n bits=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0n bits=C2=A0 =C2=A0 =C2=A0 =C2=A0|
    >=C2=A0 =C2=A0 +------------------------------------------------+--= --------------+
    >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0subnet prefix=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | 00000000000000 |
    >=C2=A0 =C2=A0 +------------------------------------------------+--= --------------+
    >
    > Packets sent to the Subnet-Router anycast address are destined for any= router on the link that is assigned a unicast address with the correspondi= ng subnet prefix. All routers are required to assign Subnet-Router anycast = addresses to their interfaces for each subnet prefix used on the link.

    Reasoning: this change (which is essentially a complete rewrite of =C2=A72.= 5.1) improves clarity by making the field headers in the structure diagram = consistent with =C2=A72.4, and by ensuring the term =E2=80=9Csubnet=E2=80= =9D is always used in the phrase =E2=80=9Csubnet prefix=E2=80=9D and not as= a shorthand for a subset of the nodes on a link using addresses that share= the same subnet prefix.

    Commentary: it=E2=80=99s not clear to me what is the real purpose of the Su= bnet-Router anycast address, even in the conservative case, but especially = so in the liberal case where on-link prefixes are not required to have the = same length as subnet prefixes. It seems okay that a single Subnet-Router a= nycast address should be defined as the destination for any router with an = address where more than one on-link prefix has a shorter subnet prefix in c= ommon. It seems much less okay that multiple Subnet-Router anycast addresse= s should be defined as destinations for any router with addresses having mo= re than one subnet prefix sharing a common on-link prefix. Still, I don=E2= =80=99t see how it breaks anything important, so I'm saying: let's = try not to do any further damage.

    =E2=80=94=E2=80=94

    In summary, I believe when publishing the successor to RFC 4291 it may be p= ossible for IETF to further clarify the IPv6 address architecture so that c= ontroversies over the validity of on-link prefixes used in neighbor discove= ry do not arise, either A) in the conservative case, because all on-link pr= efixes are also subnet prefixes and subnet prefixes are constrained to stan= dard size(s) for each link type and to 64 bits for all prefixes beginning w= ith 0b000, or B) in the liberal case, because neither on-link prefixes nor = subnet prefixes are constrained to any standard size nor even required to b= e the same length.

    I hope this proposal will be seen correctly as my sincere attempt to provid= e a constructive basis for resolving this ongoing controversy into a rough = consensus.


    --james woodyatt <jhw@google.com&g= t;



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



    --
    =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
    Networking & = Telecommunication Services
    Office of Information Technology
    Universit= y of Minnesota=C2=A0=C2=A0
    2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
    Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: = 612-812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
    --001a114388b0b7cd25054a4d0aad-- From nobody Thu Mar 9 08:26:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EDC1296A7 for ; Thu, 9 Mar 2017 08:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 2I-0grViaHlt for ; Thu, 9 Mar 2017 08:26:42 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF4212966C for ; Thu, 9 Mar 2017 08:26:42 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id j5so30570643pfb.2 for ; Thu, 09 Mar 2017 08:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=58GLHXGGybtvtVs03YN/upl9g795k8PnwMt+Z2/WP34=; b=a2uEPeyBIP+xVU5/TP5Fg3p57K4+Fec66K+CoAzS84IjtriL0VtJvx/8dc/9ZuzDNL dMJCQ/0xS02vRERxcZcmOrt62GgNJYhjZ7CN/NI9X8DM+2hCy/QvQX/Snf/CAm13i2zq HidTpJcZSXI/Rto1uuLngCSPmcws80WlTCO+4MgnxUsJcT9+Mo1VX12UEOocNXxPZgjU eUKxR9QvBySw66XGzkDpRYx7NRdgaDxbduBUithG3uk4g9KCPTeJQhnrFzReAUnuPaQp mQLR/jnxrnOjI4g70Yx+GvSbYikTSift+ET3yEXarZReBjfR5tsF6QzMSYk5sdHzu9+k /Teg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=58GLHXGGybtvtVs03YN/upl9g795k8PnwMt+Z2/WP34=; b=YnqmbyUC3CQk9bHGjXuAUPrwNhMpNQlyvh4FD2YiwSXKXU3g7hmhhxyQhpye7cntSC zUqEFVUSTNcjVCu8zJUAVa3EwrDfNu8B1I5PvcV6t4Xp9Pk/2dJt3CClFUgHQTYRxF18 fRjXoCNhKuJbLgBWZxLsw6O+zAwG8NE2M+PLGksoU1Ip8txxb1t6AXyzlRYcm4qhHpFp b8c5whT3H38gwYtXEpOL5jvobZ62/hlM6bQ9zxgeHDPr7R37Fe/MZfS2T9VKIL3FoC08 Sw6W+UGzRnsFKHvVRAr9bBLzGfSK8+XVVLu9nYuqFq6LxccKhTC7MN4sQdYYyZpFUnih uO0Q== X-Gm-Message-State: AMke39lbKzYwRJSvVyTZTo3SY8u7Cc1pEuMTO/hmY4LK4CPpMALzcv/Zqu89YIg84eas06f2 X-Received: by 10.98.192.217 with SMTP id g86mr14918905pfk.170.1489076802165; Thu, 09 Mar 2017 08:26:42 -0800 (PST) Received: from ?IPv6:2001:5a8:4:2290:61:8955:a321:5690? ([2001:5a8:4:2290:61:8955:a321:5690]) by smtp.gmail.com with ESMTPSA id a16sm13540101pgd.62.2017.03.09.08.26.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 08:26:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis From: james woodyatt In-Reply-To: Date: Thu, 9 Mar 2017 08:26:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> To: David Farmer X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:26:44 -0000 Hi David, Thank you very much for giving my proposal a fair hearing. This is just = a quick response to one point you made. I may have more to say about the = rest later. On Mar 9, 2017, at 06:27, David Farmer wrote: >=20 > The conservative version of the proposal at least needs to be adjusted = to allow for RFC6164 /127 point-to-point router links as an exception to = on-link prefixes always being /64, there seems to be a conflict here in = the conservative version. I agree. While RFC 6164 does use the word =E2=80=9Csubnet=E2=80=9D in a = confusing way a few times, it seems reasonable to read it as a standard = exception to the rule that on-link prefixes are always subnet prefixes = (under my =E2=80=9Cconservative=E2=80=9D proposal). Hence, here is my revised proposal (conservative) for =C2=A72.4.8 = Neighbor Discovery. =E2=80=94 Insertion of =C2=A72.4.8 Neighbor Discovery Proposed (conservative): > Nodes can send packets directly to other nodes with interfaces on the = same link, without forwarding by a router, when they can identify the = link-layer addresses associated with the unicast IPv6 addresses that = share on-link subnet prefixes assigned to the interface. Neighbor = discovery is conceptually the process of resolving such associations as = necessary. >=20 > Nodes may be configured manually with on-link subnet prefixes for each = of their interfaces. Also, routers may inform hosts automatically of the = set of on-link subnet prefixes by a process related to neighbor = discovery. Nodes sending packets to unicast addresses with subnet = prefixes that are not on-link must direct those packets to a router for = forwarding to their destination. >=20 > Apart from standard exceptions, every on-link prefix is required to be = a subnet prefix, and subnet prefixes for all global unicast addresses = beginning with a binary value other than 000 are required according to = Section 2.4 to be 64 bits in length. One standard exception to this is = Using 127-Bit IPv6 Prefixes on Inter-Router Links [RFC6164]. Reasoning: this text provides clarification that, apart from standard = exceptions, on-link prefixes are subnet prefixes for which neighbor = discovery can be used by nodes to communicate directly without = forwarding packets through a router. It also repeats the requirement = that all subnet prefixes other than those beginning with 0b000 are 64 = bits long. It provides an explicit reference to RFC6164 as a standard = exception. --james woodyatt From nobody Thu Mar 9 08:42:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EE41296B2 for ; Thu, 9 Mar 2017 08:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 nS11Jqo0-VQq for ; Thu, 9 Mar 2017 08:42:43 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E57B12959C for ; Thu, 9 Mar 2017 08:42:43 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id o126so30747146pfb.3 for ; Thu, 09 Mar 2017 08:42:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MXwhM/ooEdGdzSolpAC5twEb6/Zmzw0xcmhXUkNfC3o=; b=jh1yngQFDUaISXU4oQi08qlvX1QAxlRUyirWr99UouKZ7v0rDwr01TGR1vhjvnjEJY iT3flgJrDBgPoYRBnrp672+39LoA7s524QwsxaLAvzKjfn6pX1ubVnvY8kXXPV7fZUMM mbuur5p0jK9kexqvacRxPRahoxQS194RK0e2Hs+/H/e1xn4Rikx4x6USW1W0eQ7yHByp RwFSpwy/SFYW9rHfpLCSRlxmcBRam0tFdJ9tgb7gLpa2TDNjg0vSrZWvkqWhgnPrXAbW CP1fSglkYubNwTelSlW/Z3KxDELcpEJBRaDq21QwMkPMTl5lzfnGv+ShDpWDxeqG9h78 +8Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MXwhM/ooEdGdzSolpAC5twEb6/Zmzw0xcmhXUkNfC3o=; b=SrI/vUP82XqBNd29DJtBIN0XJzmzbJ5s0HXJ/6/k22akJXAerszZj2r4XMFocKunzv SSkhn24jUV4prHmSmCUhhQCmRvrQ3JuZuqgU+fad4sgBkfDSPgEWIJzctu+7qpDjz2x1 42T4B1NH0zsyRdsMBL2TI2vqnxPW4EEHZS+3I2a4/CQy1z5AjruYmtqao+IrEgRSCSDV V8BS6cElM+QaaAIAi7auR3ZYd2bFSJaah7bY6Wz0Gpn9c0nGfpMyjpnE53g1NYKF+pxc I1388ipo46LEdOc007piQFRj73/xhb2TgsLma40q193lvmMKu6iAVm8QLYPQJQV/Ihlh vuOQ== X-Gm-Message-State: AMke39n8u+swSAtOWd9HVi6bK6zkOhbJI/zmErCV2iuMHLZQtJ85rFsM1twLI1CXUIf5tgWJ X-Received: by 10.99.155.18 with SMTP id r18mr14567007pgd.193.1489077762614; Thu, 09 Mar 2017 08:42:42 -0800 (PST) Received: from ?IPv6:2001:5a8:4:2290:61:8955:a321:5690? ([2001:5a8:4:2290:61:8955:a321:5690]) by smtp.gmail.com with ESMTPSA id e129sm13568021pfe.8.2017.03.09.08.42.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 08:42:42 -0800 (PST) From: james woodyatt Message-Id: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_386D30F5-B37F-416B-8E9B-EA57694A2873" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Date: Thu, 9 Mar 2017 08:42:41 -0800 In-Reply-To: To: Philip Homburg References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:42:46 -0000 --Apple-Mail=_386D30F5-B37F-416B-8E9B-EA57694A2873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 9, 2017, at 03:16, Philip Homburg = wrote: >=20 > It seems to me that RFC 4291 uses the term interface identifier for = what > are now two separate concepts.=20 >=20 > The first interface identifier concept is that for any prefix of = length n, > the length of the interface identifier is 128-n. Let me call this = prefix-iid. >=20 > The second iid concept is in auto configuration of addresses. I'll = call this > slaac-iid. >=20 > The way I see i [=E2=80=A6] I see it differently. Predecessors of I-D.ietf-6man-rfc4192bis going back to RFC 2373 have = provided text in the Interface Identifiers subsection defining the = uniqueness properties of IIDs, and usage of that term has always been = clearly limited to the part of unicast address following a subnet = prefix. The part following any other unicast routing prefix has always = been unnamed and unstructured, and its uniqueness properties are not = those of an IID unless it is long enough to include the whole IID within = it. In my proposed clarification (both liberal and conservative versions), I = preserve the distinction that subnet prefixes precede IIDs, whereas = other routing prefixes, e.g. on-link prefixes, do not. If that doesn=E2=80= =99t seem clear in my proposal for =C2=A72.4.8 Neighbor Discovery, then = I could see adding text to that effect. Right now, it seems clear enough = to me, so I=E2=80=99m holding off. --james woodyatt > --Apple-Mail=_386D30F5-B37F-416B-8E9B-EA57694A2873 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Mar 9, 2017, at 03:16, Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com> wrote:

    It= seems to me that RFC 4291 uses the term interface identifier for = what
    are now two separate concepts.

    The first interface identifier concept is that for any prefix = of length n,
    the length of the interface identifier is = 128-n. Let me call this prefix-iid.

    The = second iid concept is in auto configuration of addresses. I'll call = this
    slaac-iid.

    The way I see = i [=E2=80=A6]

    I see it differently.

    Predecessors of I-D.ietf-6man-rfc4192bis going = back to RFC 2373 have provided text in the Interface Identifiers = subsection defining the uniqueness properties of IIDs, and usage of that = term has always been clearly limited to the part of unicast address = following a subnet prefix. The part following any other unicast routing = prefix has always been unnamed and unstructured, and its uniqueness = properties are not those of an IID unless it is long enough to include = the whole IID within it.

    In my = proposed clarification (both liberal and conservative versions), I = preserve the distinction that subnet prefixes precede IIDs, whereas = other routing prefixes, e.g. on-link prefixes, do not. If that doesn=E2=80= =99t seem clear in my proposal for =C2=A72.4.8 Neighbor Discovery, then = I could see adding text to that effect. Right now, it seems clear enough = to me, so I=E2=80=99m holding off.

    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_386D30F5-B37F-416B-8E9B-EA57694A2873-- From nobody Thu Mar 9 10:30:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BD51296EF for ; Thu, 9 Mar 2017 10:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pAF16YQ0W5lK for ; Thu, 9 Mar 2017 10:30:15 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7E012942F for ; Thu, 9 Mar 2017 10:30:15 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cm2pI-0000FsC; Thu, 9 Mar 2017 19:30:12 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> In-reply-to: Your message of "Thu, 9 Mar 2017 08:42:41 -0800 ." <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> Date: Thu, 09 Mar 2017 19:30:11 +0100 Archived-At: Cc: james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:30:16 -0000 > On Mar 9, 2017, at 03:16, Philip Homburg > <[1]pch-ipv6-ietf-3@u-1.phicoh.com> wrote: > > It seems to me that RFC 4291 uses the term interface identifier > for what are now two separate concepts. The first interface > identifier concept is that for any prefix of length n, the length > of the interface identifier is 128-n. Let me call this prefix-iid. > The second iid concept is in auto configuration of addresses. > I'll call this slaac-iid. The way I see i [] > > I see it differently. > > Predecessors of I-D.ietf-6man-rfc4192bis going back to RFC 2373 > have provided text in the Interface Identifiers subsection > defining the uniqueness properties of IIDs, and usage of that > term has always been clearly limited to the part of unicast > address following a subnet prefix. The part following any other > unicast routing prefix has always been unnamed and unstructured, > and its uniqueness properties are not those of an IID unless it is long enough to include the whole IID within it. If your use of the term 'subnet prefix' only refers to (stateless) address configuration and not to being onlink or not, then I agree about the concept (but not the term). However, where IPv6 clearly separates address configuration from being onlink, calling a prefix that is only used for (stateless) address configuration 'a subnet prefix' is very confusing. At the same time, calling some onlink prefixes 'subnet prefixes' and others 'other unicast routing prefixes' is also very confusing if they are announced using the same L flag in a PIO option in a router advertisement. I.e, whether or not the A flag is set in PIO option, should not have an effect on what we call an onlink prefix. Or on how we describe onlink prefixes and what their properties are. Currently RFC 4291 says (and this is still in rfc4291bis-07): "Interface identifiers in IPv6 unicast addresses are used to identify "interfaces on a link. They are required to be unique within a subnet prefix. It doesn't say anything that the concept of interface identifier is only related to stateless address configuration. Only when we clearly separate address configuration from onlink prefixes is there a chance that a new version of RFC 4291 will have easy to understand concepts. And match the concepts used in the neighbor discovery protocol. So if we want to say that prefixes used for stateless address configuration MUST/SHOULD be 64 bits long, whereas onlink prefixes can be of any length, then we should at least use clear terminology that separates prefixes for stateless address configuration from other uses. Certainly people who are used to the IPv4 use of the word 'subnet' may not realize that in IPv6 addresses can be configured from a prefix but that the prefix may not be onlink. So dropping the word subnet as much of possible and using terms like (stateless) address configuration prefix and onlink prefix would make the text a lot easier to read. From nobody Thu Mar 9 11:28:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09375129515 for ; Thu, 9 Mar 2017 11:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fD-D5tZOUNYw for ; Thu, 9 Mar 2017 11:28:13 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E801293E1 for ; Thu, 9 Mar 2017 11:28:13 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id j5so32252149pfb.2 for ; Thu, 09 Mar 2017 11:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=W/uT8mwSZ6YuljJIJPxkKyZWF+rEM2lEPJSBLIVn984=; b=PlqwBmx3DZirGKNzyNLVz7vZsWskZJtBFIkMBJGt9T+W8pOWTpSF7CmHY7xRvNeg8k jDRrANoRdeGbmlATTrUMSL9wh0pgHm+tDobvQ0TBsvMZTdNV7q5oFI7tUe3kuDh7v4h6 NPGSCkiqtUw0Tqr725KZdG+HqpkhW+x3MS7uDoYIPyNtOMZXYHi5ssqhbPuOrXasR7QE QIP0H8Xa1DdsxG3Sn624CqI+xRnwI0fX4Nd6yyiNOxcaTq1ZxsLOcPEsg+dieDxc7Gem ZAbfTvKr9Op67dCFH+a5GCRAKmAyJMQOFZzrqlnN+uZzycWYnEd0+IbUXRcaFG9ByDe2 se9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=W/uT8mwSZ6YuljJIJPxkKyZWF+rEM2lEPJSBLIVn984=; b=dohAYiOFxhnaZ+st2TgTD9yFDDVagjgfT22Y4DoY5lb34trvRfUF3DrqQoi4qXr2ay 59G4Yy3hxF+MYN+43VqbiJRULb4QxeOVrmDYewPahZxwTtYKJJJ7Us+mUP369mbdG039 c/GqVHLXPAUKlpQWKAZKEu9kC5tEir1DKRkj0Rb1Jyg0zqU7oogo75eOJvbzOCPIdWUz C7JF/cCZraeC/cp9FaxhicXivfFIfcpUuNN6nEMQ/Xz6J9zwdeiPbjB5D6F8PGXzKAUj z+syOL0TeS4bXtg/MHQ6FZJrM1asmWhWsY6dc1Lz5KrpeDJwwtTCnuDhMsI6+OuS9BLb Kh3w== X-Gm-Message-State: AMke39nWsCz2vfz/WBp1x7vREQgLzT91Pa6KhLd1jOGjBFnzlEMjuO14WBROdPWG/drPdg== X-Received: by 10.84.205.70 with SMTP id o6mr19601768plh.176.1489087693290; Thu, 09 Mar 2017 11:28:13 -0800 (PST) Received: from ?IPv6:2406:e007:4e09:1:28cc:dc4c:9703:6781? ([2406:e007:4e09:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s87sm14026720pfa.29.2017.03.09.11.28.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 11:28:12 -0800 (PST) Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis To: ipv6@ietf.org References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <27b9216d-2884-d601-eef6-c4d90837c959@gmail.com> Date: Fri, 10 Mar 2017 08:28:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:28:15 -0000 Isn't it time we all shut up and wait for the document editor to propose text? Regards Brian Carpenter From nobody Thu Mar 9 11:28:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F8F1296B1 for ; Thu, 9 Mar 2017 11:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 98BBosBZe3tb for ; Thu, 9 Mar 2017 11:28:52 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3931293E1 for ; Thu, 9 Mar 2017 11:28:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v29JSoOc051883; Thu, 9 Mar 2017 12:28:51 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v29JSmVV051875 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 9 Mar 2017 12:28:49 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 9 Mar 2017 11:28:48 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Thu, 9 Mar 2017 11:28:48 -0800 From: "Manfredi, Albert E" To: Philip Homburg , "ipv6@ietf.org" Subject: RE: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Thread-Topic: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Thread-Index: AQHSmMa1fYJCK+RzH0+zdQWkR+y1LqGM4iAg Date: Thu, 9 Mar 2017 19:28:48 +0000 Message-ID: <9f6ea52b7ac741ae9f95e9901d1a3bd1@XCH15-06-11.nw.nos.boeing.com> References: Your message of "Thu, 9 Mar 2017 00:19:21 -0800 ." <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:28:53 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg > The first interface identifier concept is that for any prefix of > length n, the length of the interface identifier is 128-n. Let me > call this prefix-iid. > > The second iid concept is in auto configuration of addresses. I'll > call this slaac-iid. > > The way I see it, any slaac-iid that is based on (pseudo)-random > number has to be at least 64 bits. I don't see any reason for more > than 64 so exactly 64 sounds about right. If you want random, a PRNG can create any length of IID. A 48-bit IID would= be just as reasonable, and it could be formed from a randomly changing lin= k layer address. I would stay away, at this point, from any mention of 64 as a constant. We = are (I think) beyond that, even for a particular 2000::/3 subset of globall= y unique unicast addresses. Secondly, RFC 4862 states: Note that a future revision of the address architecture [RFC4291] and a future link-type-specific document, which will still be consistent with each other, could potentially allow for an interface identifier of length other than the value defined in the current documents. Thus, an implementation should not assume a particular constant. Rather, it should expect any lengths of interface identifiers.=20 Which is where we are today, in fact. > In theory, a link that has hardware MAC addresses with less than 64 > bits could define a slaac-iid that is shorter, however that precludes > the use of pseudo-random slaac-iids. I don't think it does. Bert From nobody Thu Mar 9 11:31:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108391293DA for ; Thu, 9 Mar 2017 11:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 tJilRabodXaL for ; Thu, 9 Mar 2017 11:31:32 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA01C126DFB for ; Thu, 9 Mar 2017 11:31:32 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id w189so32285640pfb.0 for ; Thu, 09 Mar 2017 11:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tlukeaZmoWeVO0BnwkHoxGH92uAT2EZxrk5ssy820Mk=; b=mVI84GkIRQtPwWhtw7YVFojGdYEZxJGSemUTg9u4npisE5d6zriNe5jhTdAcQDtiWb 0FYbqJwvDp3pXx0TkHTmRs1EnnOVvyEB3gTdjhlBvt1kAxp8HOok8iow6Hem0y5G6Wp4 N4dSiHh8uMVdzOi26jEedmVEiPo8TpamK+6FWu202XKb1x/rGNa/8U1o8CTpi+rcP9Sb mwO6QOcMeLIWFLWLjM8HJkeTkqklT6pfrhxGHcKnqftmT96Uyfk5wRbKhdLGDmlFiin2 jukN9ytj6ogU8gWEp6jB3FAAXcEkpC4huBdNbHiTbMGrxB+6df1Lrs2PuQc/KBMLQe52 j4lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tlukeaZmoWeVO0BnwkHoxGH92uAT2EZxrk5ssy820Mk=; b=LJfUVakWLoCJtT+fMykYYcH/EC+sk2m5nJlh4YDjAbJLMHpee37qDEb/u3XBd1o+Aq eQRbuDFC4PLhT0VKJaL+PuGCzX5a8Y2uW7SLK6bMWC0C1VAWsqg1sXW7Bc7V7qycpZDJ HrAVLybElzWxss9fagn02k0Jf4KWHlm92Y08bk8jSNW2ZMtu3Lv8r8bMAjTPeChkpevX WPd2ZOPqQ5WQTRF1ngKorEu8sKn/p7oYxODuyV3XOfnf7xhhvCnIGVCh3+7WmqIdyPZs 9NUyje5Cu94smHEHcRSNFxpdk3LicssyhzgJARFPWacAduVZS0IEtug5eeno+5+7LHpE YEMg== X-Gm-Message-State: AMke39nJJcAhl4X0qA4a5jaEV51Fg/zh41ztGJvVTnkuYFQ/FHOFqRZMXDPkuzf9HAJSBuZY X-Received: by 10.98.16.136 with SMTP id 8mr16204294pfq.104.1489087892276; Thu, 09 Mar 2017 11:31:32 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id y6sm14169945pgc.1.2017.03.09.11.31.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 11:31:31 -0800 (PST) From: james woodyatt Message-Id: <60A42A40-994C-4560-BC28-06C365B7A6A0@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6590454D-53C2-4385-9E42-DA1BAAD14576" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Date: Thu, 9 Mar 2017 11:31:30 -0800 In-Reply-To: To: Philip Homburg References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:31:34 -0000 --Apple-Mail=_6590454D-53C2-4385-9E42-DA1BAAD14576 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Philip, This is just a brief response that I believe goes straight to your = argument. On Mar 9, 2017, at 10:30, Philip Homburg = wrote: >=20 > Currently RFC 4291 says (and this is still in rfc4291bis-07): > "Interface identifiers in IPv6 unicast addresses are used to identify > "interfaces on a link. They are required to be unique within a subnet = prefix. >=20 > It doesn't say anything that the concept of interface identifier is = only > related to stateless address configuration. That=E2=80=99s because interface identifiers are not just for stateless = address configuration. They=E2=80=99re for all forms of address = configuration, whether SLAAC, DHCPv6 or manual. In all cases, they are = required by RFC 4291 and predecessors to have the uniqueness properties = first introduced in RFC 2513 and carried forward into = I-D.ietf-6man-rfc4291bis today. The bits following any other form of = routing prefix, including on-link prefixes, are not required to have any = such uniqueness properties, and they never have been. --james woodyatt > --Apple-Mail=_6590454D-53C2-4385-9E42-DA1BAAD14576 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Philip,

    This is just a brief response that I believe goes straight to = your argument.

    On Mar 9, 2017, at 10:30, Philip = Homburg <pch-ipv6-ietf-3@u-1.phicoh.com> = wrote:

    Currently RFC 4291 says (and this is still in = rfc4291bis-07):
    "Interface identifiers in IPv6 unicast = addresses are used to identify
    "interfaces on a link. =  They are required to be unique within a subnet prefix.

    It doesn't say anything that the = concept of interface identifier is only
    related to stateless address = configuration.

    That=E2=80=99s because interface = identifiers are not just for stateless address configuration. They=E2=80=99= re for all forms of address configuration, whether SLAAC, DHCPv6 or = manual. In all cases, they are required by RFC 4291 and predecessors to = have the uniqueness properties first introduced in RFC 2513 and carried = forward into I-D.ietf-6man-rfc4291bis today. The bits following any = other form of routing prefix, including on-link prefixes, are not = required to have any such uniqueness properties, and they never have = been.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_6590454D-53C2-4385-9E42-DA1BAAD14576-- From nobody Thu Mar 9 11:34:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC231294D1 for ; Thu, 9 Mar 2017 11:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 W0iqXxVGqnfb for ; Thu, 9 Mar 2017 11:34:32 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23B1129497 for ; Thu, 9 Mar 2017 11:34:31 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id 77so29725291pgc.1 for ; Thu, 09 Mar 2017 11:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=z7L+LTXdT18LCfQBZJ4PHS+vkPS4i7QcWyCejwY7G9k=; b=cBjy9hsB3ojf/XkpYDRUTMo9Vr6TuStB3VTqFI2duaaeYPwngGgB5gSXml044S9KeV m0ASKgKV5U/x1Vhm8PSrpUzsu+63fgJ+OTunFWpLdHh+ZZPqunXUPbhoCujUpcfMrsE2 vzL53E0sj1B3zmICoLX8l2iGM8SVx0nEboUbKpZhBOwVKOtD3wC60FozpvJvtcH9E0Fg 9MZJ2QZW1Njq92pxf7hNNHv6qNfxsRatLjCul4Uzq1K9yJ/O0syRyOPDcwuNoyv528Rn uZy7sYCY2rf8+ctk6iR1e0AEDxGcaRkT6P0BHsJTpiZtZaBjrh72wg6KZeI/lIZSAqXW Vgew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=z7L+LTXdT18LCfQBZJ4PHS+vkPS4i7QcWyCejwY7G9k=; b=ipom06tRioWpDMwbZUopZ5KZlGetSAWmCDPVrdwk2LQdtuOX7OQNBwdukb0+uL2tbx RnDNKHkIJCyytRc2lOyxG3COK1Y0U3WPndQLLBczIa6BgGxyLAIiN7pRNJsJaajNOblv MgsD7Lu0itY6wPv+Cd/AMTWLeCDGBVcELlIaZL/GDYxb7nfZlCtDIYOevqoCy1jxf+6N +SOiM0FpCOJdglOMftGfIvqjXCHqFaQiEV5lHyDF1m1cRqvfW9yG+Hg0S7QSIdUTolPb R0hzkp2HRRDPr8iViSkxToj18almoz7RC9OMKea4CL3kW/ikZ2XajFTM09NN1rEuZX0F eOvA== X-Gm-Message-State: AMke39nZgiKx36/FRTzwlZktxMUE0cKzoxt+qCC80tLkdjuDTi5US7UPnAD2xFbFUVZDSrQ9 X-Received: by 10.99.122.13 with SMTP id v13mr15905167pgc.31.1489088071432; Thu, 09 Mar 2017 11:34:31 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id c28sm13996362pfj.77.2017.03.09.11.34.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 11:34:30 -0800 (PST) From: james woodyatt Message-Id: <7B808584-97CB-42DE-A8CA-248687915B70@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_18A650BB-C095-489E-9C7F-D9D68CDFD76C" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Date: Thu, 9 Mar 2017 11:34:29 -0800 In-Reply-To: <60A42A40-994C-4560-BC28-06C365B7A6A0@google.com> To: Philip Homburg References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> <60A42A40-994C-4560-BC28-06C365B7A6A0@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:34:33 -0000 --Apple-Mail=_18A650BB-C095-489E-9C7F-D9D68CDFD76C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 9, 2017, at 11:31, james woodyatt wrote: > [=E2=80=A6] the uniqueness properties first introduced in RFC 2513 = [=E2=80=A6] RFC 2373, apologies. --james woodyatt > --Apple-Mail=_18A650BB-C095-489E-9C7F-D9D68CDFD76C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Mar 9, 2017, at 11:31, = james woodyatt <jhw@google.com> wrote:
    [=E2=80=A6]  the uniqueness properties first introduced = in RFC 2513 [=E2=80=A6]

    RFC 2373, apologies.

    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_18A650BB-C095-489E-9C7F-D9D68CDFD76C-- From nobody Thu Mar 9 11:34:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906E81295BC for ; Thu, 9 Mar 2017 11:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VlDH9FDpmDIj for ; Thu, 9 Mar 2017 11:34:38 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D971295B1 for ; Thu, 9 Mar 2017 11:34:38 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id w189so32314013pfb.0 for ; Thu, 09 Mar 2017 11:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GwCd519tT0QkxcUST6NHzx06LRaxZaZcv8GJnF9N7zo=; b=SDmzoPZSiyUf+Qc8me43DeRHZHk0d2QnSiJ6DP/V+f9EaOnVfb+B/uydFm8tLFW/jU o+JMDNKf2YflZJcjJAB56TA7M7nk+3b5tTAOIfhHjyL8+aWnFfIZVkyum7umV9y2khBV VDurIC6NX+87SnA+T84M7jLMTKeeCstX3N16W89P1SIXSr3+OwED+zQvuOO/kccL8gCf S5d0YJz1LYtDC6SLpCmYaTZ1mirby6MQ+i/ssZOjywKpUtHy9W0T8WJ6vvcH8xty1MWi Nl7cM6xhe8Ja4N7aaucSc4dTeNorOSsOpnXhRQDL2mszIPokggvQtQ3pbo98WsnMT0tV UXbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GwCd519tT0QkxcUST6NHzx06LRaxZaZcv8GJnF9N7zo=; b=dcu+C5zi/2sedCYkr6ofuv95IEoUJ9kGBFihkB0MH45uG+lok/vI/cFAlyrQAHcDvA gRuo78o0ATCKxC56N3dJUimnxRkQUTnvTJrRc+CuOEW312lZIxTmdN6seKclaLKIXYfJ E3XeR34AETatLSi85vn/NlNwRYF9vTIhBjQymQuNntfOhRjPSgC/NPFp+MsjeraG/dGs nNu2UFIfmIjOjmIIPCDye65eyq09bXNyfJPRU1jnaxUEDjBwjkqUgvVt/pL2RtVCzR4s QGZJF/LJQlVOoUcl85OcoOArY+GenPyKYSyMH40zCHIi/h0uwFj581OyFivLdCyyYcF2 1chQ== X-Gm-Message-State: AMke39kALdNtrq7qR2U70Pt/EQ1B7Bo/TUzge3e9HM3Sv3sX4aEMq8CQH54FjG11VRj6Ig== X-Received: by 10.98.44.15 with SMTP id s15mr16054005pfs.161.1489088078026; Thu, 09 Mar 2017 11:34:38 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id s4sm13992479pfi.74.2017.03.09.11.34.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 11:34:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis From: Fred Baker In-Reply-To: <27b9216d-2884-d601-eef6-c4d90837c959@gmail.com> Date: Thu, 9 Mar 2017 11:34:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> <27b9216d-2884-d601-eef6-c4d90837c959@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:34:39 -0000 > > Isn't it time we all shut up and wait for the document editor = to propose text? > If I were the document editor, after all this noise, I might wish that = someone would tell me the half-of-a-sentence change that would have made = this discussion unnecessary. = From nobody Thu Mar 9 12:25:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC2112940D for ; Thu, 9 Mar 2017 12:25:09 -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 autolearn_force=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 M0eVhEjcJ1Ko for ; Thu, 9 Mar 2017 12:25:07 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id D7B451294B8 for ; Thu, 9 Mar 2017 12:25:06 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 5E63EE6065; Thu, 9 Mar 2017 21:25:04 +0100 (CET) Date: Thu, 09 Mar 2017 21:25:04 +0100 (CET) Message-Id: <20170309.212504.74699213.sthaug@nethelp.no> To: jhw@google.com Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis From: sthaug@nethelp.no In-Reply-To: <60A42A40-994C-4560-BC28-06C365B7A6A0@google.com> References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> <60A42A40-994C-4560-BC28-06C365B7A6A0@google.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 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 20:25:09 -0000 > > It doesn't say anything that the concept of interface identifier is only > > related to stateless address configuration. > > That's because interface identifiers are not just for stateless > address configuration. They're for all forms of address > configuration, whether SLAAC, DHCPv6 or manual. Well, if IIDs are for all forms of address configuration the document cannot say that IIDs are 64 bit and at the same time reflect reality. You get to choose one or the other, not both. Steinar Haug, AS2116 From nobody Thu Mar 9 13:11:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5841C129549 for ; Thu, 9 Mar 2017 13:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VySZ2596tnPa for ; Thu, 9 Mar 2017 13:11:40 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B1512953E for ; Thu, 9 Mar 2017 13:11:40 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id p64so140398642qke.1 for ; Thu, 09 Mar 2017 13:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cVI5XM9LHxAHXW3gejr/GntRASirPsK04NrXu+459BI=; b=QQ9aja45h6v2mNXVypCO+M9Jb7+SHvL65BYCz5oM/4HVQqsLUNpQX5if9th2M09u+d mpE7WOqSL5m23gln6mNMXT8pzVIfR6LXdgcvaoGkM7PeC9i1TppOkitEp7ZDjcpGM+up 1TpCevCSbXejL6NfhiV+wTxO70dv4t8vcHulvk3U8l9ygtcNk4Rdpc39nfa4pTr1skbn iqLHkARIQVZf0goSDa4j8+1zlkLd9KxwlU8rN6IGgnmuF04zyvssy0odtahqAYrancAK fi14VF+C02cKPf9OpTy2pr2gRZ2eeFuzzqo8EZ1ka96teGBGSGFRruPqbCQmNPYzQjTu 8KPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cVI5XM9LHxAHXW3gejr/GntRASirPsK04NrXu+459BI=; b=uisMmGGbdyw/lPGg2vCV92XXAkdxLnuwgsyXx+IgvRosRjfnc4ingh3UasVDcqfvhK oE/xxcf/aYmQvj/R7+b6etHFvqqfF5oRd4jqFw8xuRqL0Q5f9zQx2MCqtvbWKdhCWSzz kJgiu05PUPEMr7ApGEMk2OnlLh5aG/91IQXoREQILlM/aoGPiHmZ0UhBjSAhkWki9EV4 EX5rU4KsZ2DPs5CV3F39NS9wionWCCyjEzfmjLLrSRAPKk6TQMo3n/6v2AYlj0YhtuG6 l8Ch481ApSUybAbI3aIval8nv62fSg/j+3qhZA6iQWiF8EYlpgHVXUd2HOr6u4JMZh0V pmCA== X-Gm-Message-State: AFeK/H1Bt+fUZQMt05A8WYKrAeEea2RbKRcugabcEF7n3HI7XEnD1MZ71qt0v0svz212FmVAtgJUGfggVs+WWQ== X-Received: by 10.55.104.134 with SMTP id d128mr13131519qkc.86.1489093899531; Thu, 09 Mar 2017 13:11:39 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Thu, 9 Mar 2017 13:11:39 -0800 (PST) In-Reply-To: References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 9 Mar 2017 13:11:39 -0800 X-Google-Sender-Auth: _KRk62mpgecBgJBCofjX8JkV0Ew Message-ID: Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis To: Philip Homburg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: james woodyatt , IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 21:11:42 -0000 At Thu, 09 Mar 2017 19:30:11 +0100, Philip Homburg wrote: > If your use of the term 'subnet prefix' only refers to (stateless) address > configuration and not to being onlink or not, then I agree about the > concept (but not the term). > > However, where IPv6 clearly separates address configuration from being onlink, > calling a prefix that is only used for (stateless) address configuration > 'a subnet prefix' is very confusing. > > At the same time, calling some onlink prefixes 'subnet prefixes' and others > 'other unicast routing prefixes' is also very confusing if they are > announced using the same L flag in a PIO option in a router advertisement. > I.e, whether or not the A flag is set in PIO option, should not have an effect > on what we call an onlink prefix. Or on how we describe onlink prefixes and > what their properties are. [...] > So if we want to say that prefixes used for stateless address configuration > MUST/SHOULD be 64 bits long, whereas onlink prefixes can be of any length, > then we should at least use clear terminology that separates prefixes for > stateless address configuration from other uses. +1. I've also been feeling that one source of seeming confusion in this discussion may be confusion between "subnet prefixes" and prefixes for on-link determination as described in RFC4861. In fact, the latter (I'll use the term "onlink prefix" in this message) has nothing to do with "subnet prefixes" - it simply specifies a set of addresses that should be supposed to be on-link for the corresponding link. Whether or not we adopt "conservative" or "liberal" view of the length of IIDs or "subnet prefix" in the context of addressing architecture, an onlink prefix can be longer or shorter than a subnet prefix even if these two share some leading bits. So, for example: - if we adopt the "conservative" address architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 must be 2001:db8:1:2::/64. - if we adopt the "liberal" address architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 can be 2001::/16, 2001:db8::/32, 2001:db8:1::/48, 2001:db8:1:2::/64, ...2001:db8:1:2:3:4:5:0/120, etc. and, in either case, - onlink prefx in this link advertised via an RA with L=1 can be 2001::/16, 2001:db8::/32, 2001:db8:1::/48, ...2001:db8:1:2:3:4:5:0/120, etc. In particular, the fact that onlink prefix can be of any length doesn't mean it violates the conservative address architecture. Perhaps one source of confusion is the fact or expectation that RA PIO often both sets A and L bits on. So, in the above example, if we have a PIO for 2001:db8:1::/48 or 2001:db8:1:2:3:4:5:0/120 with both L and A bits on, these are valid on link prefix. But they can't be used for SLAAC (assuming its link-layer spec specifies the consistent IID length with the "conservative" address architecture, i.e., 64). That is, for the same PIO, - if we consider it as on-link prefix, it can coexist with any of the address architecture - if we consider it for SLAAC, it can only coexist with the conservative architecture, or liberal one with an exception of requiring 64-bit subnet prefix length specifically for SLAAC BTW while writing this message I saw a warning from Brian: >> Isn't it time we all shut up and wait for the document editor to >> propose text? I don't want to contribute to making this thread even longer, so I promise I'll stop here. But I wanted to make this one remark since I believe it's important to clarify that ("on-link prefix" is irrelevant to the address architecture discussion) and I see why this can be so confusing. Even if this attempt of mine fails, I'll shut up now (maybe I should write a separate draft just focusing on this particular confusion). -- JINMEI, Tatuya From nobody Thu Mar 9 18:37:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21BC1294C3 for ; Thu, 9 Mar 2017 18:37:50 -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 autolearn_force=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 LPt87jUZqoXG for ; Thu, 9 Mar 2017 18:37:48 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13501294E0 for ; Thu, 9 Mar 2017 18:37:42 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3F1413497CB; Thu, 9 Mar 2017 22:40:19 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1AAB4160091; Thu, 9 Mar 2017 22:40:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id ED258160090; Thu, 9 Mar 2017 22:40:18 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tHbmyFY3_1o3; Thu, 9 Mar 2017 22:40:18 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7F80E16008F; Thu, 9 Mar 2017 22:40:18 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7C436665FFBC; Fri, 10 Mar 2017 09:40:14 +1100 (EST) To: Alexandre Petrescu From: Mark Andrews References: <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <36251EE1-309C-44B5-BEAE-591889492547@employees.org> <9B6D49C1-D793-465B-A395-28147BD22FAC@google.com> <3397bed0-1 ca8-7b62-8215-7561883de4a9@gmail.com> Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - timeline In-reply-to: Your message of "Thu, 09 Mar 2017 08:58:38 +0100." <3397bed0-1ca8-7b62-8215-7561883de4a9@gmail.com> Date: Fri, 10 Mar 2017 09:40:14 +1100 Message-Id: <20170309224014.7C436665FFBC@rock.dv.isc.org> Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:37:51 -0000 In message <3397bed0-1ca8-7b62-8215-7561883de4a9@gmail.com>, Alexandre Petrescu writes: > Hi, > > Thanks for the pointers to the earlier discussion. > > Le 08/03/2017 =E0 22:54, Timothy Winters a =E9crit : > > Hi James, > > > > Since this was added in the update from RFC 2461 to 4861 I went to > > go look for why this was added and found the following thread. > > > > Discussion: > > https://mailarchive.ietf.org/arch/search/?email_list=3Dipv6&q=3DRequireme= > nt+for+64bit+I%2FF+ID&so=3Ddate&gbt=3D1&index=3DrJtLf5Krh0X9vg3vYts_xO1oUCw > > > > > > > > > Final Decision: > > https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4 > > I think that decision is that ND should work with arbitrary plens, not > just 64. > > In light of that ND decision, it is strange to see an RFC at the same > time IPv6 Addressing Architecture mandating IIDs 64 (and implicit > mathematical plen 128). > > Retrospectively: > > At time of that discussion, year 2004, there was no IPv6 on cellular > links, [I-D]. Since then 3GPP got many recommendations from IETF about > how to run IPv6. The result is 3GPP User Equipment links only support a > single 64 today. > > My supposition, and many indications converge, is that the 64 > recommendation from the IPv6 Addressing Architecture RFC led to this > undesirable situation of a single 64 for an UE. No. The deliberate decision to ignore DHCP-PD lead to it. It was too new / too late in the process / not enough implementations / not enough experience. > If we were again in 2004, I would tell that decision maker: not only ND > should avoid the 64 limit, but the IPv6 Addressing Archi should too. > > That would have saved us many recent RFCs discussing 64 (the BCP CIDR > IPv6, the multiple-address per Host recommendation, the why64 RFC, and > many others I mistakenly forgot). > > We are now in 2017... > > Alex > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Mar 9 19:57:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFDE129482 for ; Thu, 9 Mar 2017 19:57:15 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Yv0B15Sigg2y for ; Thu, 9 Mar 2017 19:57:14 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD50C129536 for ; Thu, 9 Mar 2017 19:57:13 -0800 (PST) X-AuditID: c6180641-0291898000000a06-68-58c1ddc2468e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id F5.82.02566.2CDD1C85; Thu, 9 Mar 2017 23:57:07 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Thu, 9 Mar 2017 22:57:09 -0500 From: Suresh Krishnan To: Brian E Carpenter Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Thread-Topic: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Thread-Index: AQHSmVJgHkdHqsxn9kaVjE5sZAKung== Date: Fri, 10 Mar 2017 03:57:03 +0000 Message-ID: References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> <27b9216d-2884-d601-eef6-c4d90837c959@gmail.com> In-Reply-To: <27b9216d-2884-d601-eef6-c4d90837c959@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_C3A78EB3-9D27-4D24-BD9D-04184560A567"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyuXRPiO7huwcjDPqP8Vm0XdzHZPHy7Hsm ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSuj5WdBwRzDiq8tYg2MPfpdjJwcEgImEhM7 Wpm6GLk4hATWM0pcXr2ACSQhJLCMUeLXOTcQmw2oaMPOz2BxEQFjicau06wgNrOAtMStJc/B 4sICMRLrPzxj7mLkAKqJlZh5wgiiXE9i6ql9LCA2i4CqxIUbK1hASngF7CVm3K6CWHuIUWJb 9ydmkBpOAVuJ51uOsIPYjAJiEt9PrWGCWCUucevJfCaIm0UkHl48zQZhi0q8fPyPFcJWkvj4 ez47yFBmgSmMEmtfzmEESfAKCEqcnPmEZQKjyCwks2Yhq5uFpA6iSFti2cLXzLOAjmUW0JGY vJARImwq8froRyjbWmLGr4NsELaixJTuh+wLGDlWMXKUFhfk5KYbGW5iBEbUMQk2xx2Me3s9 DzEKcDAq8fBuMD0YIcSaWFZcmXuIUQWo9dGG1RcYpVjy8vNSlUR4zR8DpXlTEiurUovy44tK c1KLDzFKc7AoifNeD7kfLiSQnliSmp2aWpBaBJNl4uCUamCUV3ARmqOqdf/JHqkUuc2q8rtW P5gs0nu/ke+k8IZqltx1sgcPFE6cz71H6CR3sEDq7CUMO5zl+Yyeratp/ap3wG9Bbez+CfKH bpXuqnldc43tyutvM3f39z7fP62A99bCuS13T00Kt+xv9p0rHVFmNmuKdMchgYeyYbvF2b9e LDIKqP8WOWOWEktxRqKhFnNRcSIAez1KlLACAAA= Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 03:57:15 -0000 --Apple-Mail=_C3A78EB3-9D27-4D24-BD9D-04184560A567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 9, 2017, at 2:28 PM, Brian E Carpenter = wrote: >=20 > > Isn't it time we all shut up and wait for the document editor to = propose text? > Thanks Brian. That is the plan. It has been hard to summarize the last = call and the way forward due to the continuing discussion on the 4291bis = document. Expect something in the next day or two. =20 Regards Suresh --Apple-Mail=_C3A78EB3-9D27-4D24-BD9D-04184560A567 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzEwMDM1NzA0WjAjBgkqhkiG9w0B CQQxFgQUaCzhRIkUhrttLNz/b9FFTjT9uIowXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQBZ7R/LfdQUy7IjePaWvySDTrIVdVxdCNNtsn064iC6XyII99OXWMKXCQqRiJT/ qgUbkuighv09z4Bf2LX5ZQITxY4ba2Ptpp/ogY89tyCIPF/XyW6zZVPhrYcDGgfhu5qbisw7iTFJ c38SMjD8VxGguXQVpcq9wUcUGmM6i7XnByS6AP2ATX3aSJhRtl53jXVk46bAwDOB4in10aYGAOkE 5s7LKI4irFIU7NxVEvwHYlx3vIHabZiUj0McUULtEHdj84SVOkWo/2XZv7NFDVybyBAmtErj3gf3 qB6rFApwCwOpbFffYzfCdCJBZ7H3hvZmEr2+v8jyxhk7fyTw3OV0AAAAAAAA --Apple-Mail=_C3A78EB3-9D27-4D24-BD9D-04184560A567-- From nobody Thu Mar 9 20:12:11 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6874C1295B7; Thu, 9 Mar 2017 20:12:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-maxra-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148911912639.5852.17633348656785673120@ietfa.amsl.com> Date: Thu, 09 Mar 2017 20:12:06 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 04:12:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Support for adjustable maximum router lifetimes per-link Authors : Suresh Krishnan Jouni Korhonen Samita Chakrabarti Erik Nordmark Andrew Yourtchenko Filename : draft-ietf-6man-maxra-02.txt Pages : 6 Date : 2017-03-09 Abstract: The neighbor discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by link-layer specific documents. This document allows for overriding these values on a per-link basis. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-maxra-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-maxra-02 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 nobody Thu Mar 9 20:47:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABD412941C for ; Thu, 9 Mar 2017 20:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 RrLy1Hz9rxRp for ; Thu, 9 Mar 2017 20:47:02 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A721E1288B8 for ; Thu, 9 Mar 2017 20:47:02 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id f54so97810866uaa.1 for ; Thu, 09 Mar 2017 20:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0JGArspBlSt0l10lJRAySs/TlAzOmk/WmjFK4EJE/bU=; b=jQMBL8wgoV/z36rN1SHzfZuFeiGtuAlwr2hHmGrWo7lF8QlBFKW/k90kQy41pIi6dI RQ9e9vwrEf/QAwS/BFN21O+3bZIg3ekp1HhdtN6IA5b8D8cOFmBFzi0NRikOsaKlO3uI lQyjxeN2+8+TfoU87sIYz1LX98O+sc8yBCKUYgwqvFSO5CMQxwMMiuv217KuO9X+/huj 3RVGaZuWq6vYEDGIDTz+7pgF1Mt1AxYYIVYQnGHKDzq/J9SYh+3VWy2sV547SbZfx9bc 6mKZCYivlGuEMgy6CmLfhmia4TjIYpBXtqXjqpTe37UwiuDn5/iHuDYxMBNLRpGTXpMY oOeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0JGArspBlSt0l10lJRAySs/TlAzOmk/WmjFK4EJE/bU=; b=nUz6I35N0Bhht2QRLzokQ3AX+9Lirsdqp5LlTFUiwMxKq5XcqIirSRpXp9feFMxuDj 1OE910Ipk4qYjBelFpvzun5lDckWRVpYT9eP2M2nWpcTcK4xQixQcxvPN6WNdblDewb3 HpGTVrSBrKjIdxWqjiyr+n4R/sxJiHgPoqyYAqkf4nz/mKtQiYHnAHazEMZq47i8qxKd MAUt+SqGOJibhgwSwV627WM6++hFSZUPdxsw5tnEzedHFipRsS8RMmPffdFqkqrhEXIT nDExiaJMkLrVqa6CjsvNKyrvDj0iXXxBuJWwIuphxlwhFT34tb+jbdMgXPMNzeHQoH6Y kf5Q== X-Gm-Message-State: AMke39mfe6IzhvcsnBjp4U5TBKFULpAmurzBvPQCE/+cmcUakGHOkQGXLjUrzy71OO4PnyJehS2ouRQUAmaMVddy X-Received: by 10.176.1.5 with SMTP id 5mr7934004uak.30.1489121221639; Thu, 09 Mar 2017 20:47:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 9 Mar 2017 20:46:41 -0800 (PST) In-Reply-To: <148911912639.5852.17633348656785673120@ietfa.amsl.com> References: <148911912639.5852.17633348656785673120@ietfa.amsl.com> From: Lorenzo Colitti Date: Fri, 10 Mar 2017 13:46:41 +0900 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-maxra-02.txt To: internet-drafts Content-Type: multipart/alternative; boundary=001a113d058c71cbca054a590daf Archived-At: Cc: IETF IPv6 Mailing List , i-d-announce@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 04:47:05 -0000 --001a113d058c71cbca054a590daf Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 1:12 PM, wrote: > The neighbor discovery protocol specifies the maximum time allowed > between sending unsolicited multicast Router Advertisements from a > router interface as well as the maximum router lifetime. It also > allows the limits to be overridden by link-layer specific documents. > This document allows for overriding these values on a per-link basis. > The changes proposed by this draft are fine, but I have concerns about the stated rationale. Rationale: it makes no sense to say that we should be able to extend the maximum RA timer above 9000 seconds because multicast is inefficient on some links, and then cite a draft that says that multicast is not efficient on 802.11 networks. On 802.11 networks, multicast is not as reliable as unicast, but it's certainly not the case that one packet every 9000 seconds is a problem. Maybe instead of citing 802.11, remove all mention of 802.11 and focus only on the 3GPP use case? Or, in addition to that, say that for some power-constrained nodes, one packet every 9000 seconds might still be too much. Also: since we continue to see implementers do bad things such as set maxinterval to 4s and router lifetime 12s on a wifi network, I would add to the end of section 4: As explained in Section 3, the relationship between MaxRtrAdvInterval and AdvDefaultLifetime must be chosen to take into account the probability of packet loss. --001a113d058c71cbca054a590daf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On F= ri, Mar 10, 2017 at 1:12 PM, <internet-drafts@ietf.org> wrote:
    =C2=A0 =C2= =A0The neighbor discovery protocol specifies the maximum time allowed
    =C2=A0 =C2=A0between sending unsolicited multicast Router Advertisements fr= om a
    =C2=A0 =C2=A0router interface as well as the maximum router lifetime.=C2=A0= It also
    =C2=A0 =C2=A0allows the limits to be overridden by link-layer specific docu= ments.
    =C2=A0 =C2=A0This document allows for overriding these values on a per-link= basis.

    The changes proposed by this dr= aft are fine, but I have concerns about the stated rationale.
    Rationale: it makes no sense to say that we should be able to e= xtend the maximum RA timer above 9000 seconds because multicast is ineffici= ent on some links, and then cite a draft that says that multicast is not ef= ficient on 802.11 networks. On 802.11 networks, multicast is not as reliabl= e as unicast, but it's certainly not the case that one packet every 900= 0 seconds is a problem. Maybe instead of citing 802.11, remove all mention = of 802.11 and focus only on the 3GPP use case? Or, in addition to that, say= that for some power-constrained nodes, one packet every 9000 seconds might= still be too much.

    Also: since we continue to see= implementers do bad things such as set maxinterval to 4s and router lifeti= me 12s on a wifi network, I would add to the end of section 4:
    As explained in Section 3, the relationship between MaxRtrAdvI= nterval and AdvDefaultLifetime must be chosen to take into account the prob= ability of packet loss.
    --001a113d058c71cbca054a590daf-- From nobody Thu Mar 9 22:06:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69D41295C6; Thu, 9 Mar 2017 22:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IVP7VzIOp516; Thu, 9 Mar 2017 22:06:25 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136C4127A90; Thu, 9 Mar 2017 22:06:25 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id w189so37902629pfb.0; Thu, 09 Mar 2017 22:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=N6KfpuVNNI9grgqye1Nh10elM9h8ThBKvkJr3hMScdk=; b=UyT7MFfxvnIYlmicYv5jLykWjCSLiJ07D73XoOk3xIYK1MUwGSSpHShe4BTns+dGxQ MhW6S9vOIMcRPL7ZKVren9wuR3GABi7wwwp7woKvw0gTNKt1nV9C1YmMO0h1sNIYwUjI sHtdEZiMCuJsmuR1yPljQA4GLC3/4rJChsvVTSvkIpK7X+L2MWymGxQ8LVhiqPj+DiKr /9jtL57Gdgx5C7YrmRd15j3o3c9yFbxMat1XYJr8CZf+jGRg4hhQeg9fa5MW2ajUqyPA u2/1F+OfmeDliUc21BU1SwhZafMVunRuyPARl9i7lXB17PKIfA03p4o5tgNc++GdmWZ/ ciPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=N6KfpuVNNI9grgqye1Nh10elM9h8ThBKvkJr3hMScdk=; b=AcRdxDiE4K5MksLTjFAvhnrg4VhDZ1TaYboNT1eAr0TsTPQFF+XQf8VHe6FA6EvXUa gvb4OLROF859yebgyScKo0j/CTZJ44WA22+OnsS1EDugSXhBrRhc5+I9zykK3R3pkqvc ZYpjsauNd6HKD92UzyI/jn94vXPg7RqX3Gl+RCXc8ZoozySOoueDh/mnnFrll6MySPTI AhP/jqOH2OYTOMXBtvHcrYy+gFZse4WuLo7iaBtQBGJqO4gMVZnKPRZZBdRX78wiKGdK 6DMCGI7/2eMnPnDzD0kWLDrqlgloOs3XBIOWN4XD6bVdQio71MRM3DZVqbw40ukViKIV srEg== X-Gm-Message-State: AMke39l8ZGJpFOJrPVBZgK4Fanf02RE0gimJRaUC5/eS0aeBpnpWGrpvYQ1TdgUggW/1BCIOW43NfC5vjAqa7A== X-Received: by 10.98.220.200 with SMTP id c69mr18858910pfl.60.1489125984563; Thu, 09 Mar 2017 22:06:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.151.1 with HTTP; Thu, 9 Mar 2017 22:06:04 -0800 (PST) From: Naveen Kottapalli Date: Fri, 10 Mar 2017 11:36:04 +0530 Message-ID: Subject: DHCPv6 subscriber learning default gateway To: v6ops list , 6man WG Content-Type: multipart/alternative; boundary=f403045cc42e55f87a054a5a2953 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 06:06:26 -0000 --f403045cc42e55f87a054a5a2953 Content-Type: text/plain; charset=UTF-8 Hello, Can anyone tell how will a DHCPv6 subscriber learn about the default gateway it has to contact for the subscriber traffic? Yours, Naveen. --f403045cc42e55f87a054a5a2953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello,

    Can anyone tell how will a DHCPv= 6 subscriber learn about the default gateway it has to contact for the subs= criber traffic?

    Yours,
    Naveen.
    --f403045cc42e55f87a054a5a2953-- From nobody Thu Mar 9 23:03:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD009129400; Thu, 9 Mar 2017 23:03:36 -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 autolearn_force=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 f6D_jjVspIzA; Thu, 9 Mar 2017 23:03:35 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id CAA35127078; Thu, 9 Mar 2017 23:03:34 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id B44F3E6065; Fri, 10 Mar 2017 08:03:31 +0100 (CET) Date: Fri, 10 Mar 2017 08:03:31 +0100 (CET) Message-Id: <20170310.080331.41692443.sthaug@nethelp.no> To: naveen.sarma@gmail.com Subject: Re: DHCPv6 subscriber learning default gateway From: sthaug@nethelp.no In-Reply-To: References: 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 Archived-At: Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 07:03:37 -0000 > Can anyone tell how will a DHCPv6 subscriber learn about the default > gateway it has to contact for the subscriber traffic? A DHCPv6 subscriber is supposed to learn about default gateway from Router Advertisement. Steinar Haug, AS2116 From nobody Thu Mar 9 23:43:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5352512961F; Thu, 9 Mar 2017 23:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cHH8Sa1ouzrU; Thu, 9 Mar 2017 23:43:27 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC2212961B; Thu, 9 Mar 2017 23:43:27 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id j5so38898472pfb.2; Thu, 09 Mar 2017 23:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dSe1iG9vU1NhaXegJTvvIAyw+ZgmGRPSm/QjkA8iprE=; b=tbvNoy2z4o/7KXqTipp63x8pguD8wcVrRuoD/J/tuB5PiumoVrvfFCIfQVrbl80q56 zaWIQ9vS6lPbPmCaeSbR/Sd8ppT7KxlatA1K+aJImI7g1oZRd9gRKBiE6gaLYjbK3TfS VIv8x/8FIH6fhyTJ9lAGRT2PQDYW0Yn/ctvkWif/Rbuzsp4/WJLxepRvnlxEFPoiHce6 T940FZmuxkRD2cH7DykffZrwqj7dhjdMnEUpRI+P27znhzPL9STH76mGIaN9vSlU45lC aq3XmpjUQUSxdwNcAR38YclmVVKyunxqFPN03NO1/xKOO9Xx/DB9yEeaTIjSVlyf5l2a ZXkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dSe1iG9vU1NhaXegJTvvIAyw+ZgmGRPSm/QjkA8iprE=; b=IZy/5c6QqdbELmy4aORcr5FDAbapxQsykYh0sB4klljO8KufFyEa2bZp0jkv+7Rz2/ AvoJetpNiZKVTFSSPBCeKCP3acZedKT8Uu9/RIoWPvrPwDJ/E8BAy4tAnVTr9/47RRde C31XEm3KNnQRlDhwLEc8di4cNJpJCALk+bUJ5x3IxxU6F/AToqjrIWtTVRaDrx0tnK/f 6XamV1eC0YroTK0/6DTrBA0fOyS9w8Tppnh4e3R019h9ptcde1diKvhGzNZYSLW/GOmR JuvaRFGKXKoHw4oN7luSL3xVCo0M9wd0gEVd9Ed3Djt4ef3EEnr8ab8SMFEl4jJBIUQn L6Ig== X-Gm-Message-State: AMke39lWLQUY62fUTpHOickOhA0shEXxAMNPTOQ7PJ9hNDGxWDdIiIlfMxhNXciQdhYtr79issWuulEFi9nDqg== X-Received: by 10.98.160.84 with SMTP id r81mr19495409pfe.71.1489131806886; Thu, 09 Mar 2017 23:43:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.151.1 with HTTP; Thu, 9 Mar 2017 23:43:06 -0800 (PST) In-Reply-To: References: <20170310.080331.41692443.sthaug@nethelp.no> From: Naveen Kottapalli Date: Fri, 10 Mar 2017 13:13:06 +0530 Message-ID: Subject: Re: DHCPv6 subscriber learning default gateway To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=001a1144023e5f925a054a5b840a Archived-At: Cc: v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 07:43:28 -0000 --001a1144023e5f925a054a5b840a Content-Type: text/plain; charset=UTF-8 +v6ops, 6man Yours, Naveen. On 10 March 2017 at 12:41, Naveen Kottapalli wrote: > Okay. Can you tell which parameters of RA will convey the default gateway > address? Also, can you point me to the document where it is mentioned that > a DHCPv6 subscriber has to use RS-RA for resolving gateway address? > > Yours, > Naveen. > > On 10 March 2017 at 12:33, wrote: > >> > Can anyone tell how will a DHCPv6 subscriber learn about the default >> > gateway it has to contact for the subscriber traffic? >> >> A DHCPv6 subscriber is supposed to learn about default gateway from >> Router Advertisement. >> >> Steinar Haug, AS2116 >> > > --001a1144023e5f925a054a5b840a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    +v6ops, 6man

    Yours,
    Naveen.

    On 10 March 2017 at 12:41, Naveen Kottapalli= <naveen.sarma@gmail.com> wrote:
    Okay.=C2=A0 Can you tell which parameters of= RA will convey the default gateway address?=C2=A0 Also, can you point me t= o the document where it is mentioned that a DHCPv6 subscriber has to use RS= -RA for resolving gateway address?

    Yours,
    Naveen.

    On 10 March 2017 at 12:33, <sthaug@nethelp= .no> wrote:
    > Can = anyone tell how will a DHCPv6 subscriber learn about the default
    > gateway it has to contact for the subscriber traffic?

    A DHCPv6 subscriber is supposed to learn about default gateway from<= br> Router Advertisement.

    Steinar Haug, AS2116


    --001a1144023e5f925a054a5b840a-- From nobody Fri Mar 10 09:49:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA8B1294C7 for ; Fri, 10 Mar 2017 09:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 r81bTmvt3Dh1 for ; Fri, 10 Mar 2017 09:49:19 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F81A129453 for <6man@ietf.org>; Fri, 10 Mar 2017 09:49:19 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id n11so839698wma.0 for <6man@ietf.org>; Fri, 10 Mar 2017 09:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=k8a+bKNK69+MyfNKRMyiIlmsISgLwkF/LDdoDWCfU2o=; b=NVGlCxlrj2QOB5X8RLQucPthyIJHKMLJJnQrDGT1KFReEBhf8yf5VgaAPcUc6ZIloc bSt/q3FO88+vW1GmYQAkJ/NyfpaLpg4JPVsN7prcbpeob9Txsr99CGzxHaabNQ7nqS8D klpN/+iziBgYDYap8LCBgM0Ir3q4xSi7sl4+iCct/m9L+XGxLFvPVb8j176bGd9qkhIb D8rngOdREhRFu3qri0B+FGTTquI8Gucn93FxO3m/bUcYDi9K2aVNy8XCDRnWjXk0uWP0 /iRmBggwh+VhfdwKqQ9aXlgfp/tAKYSeGxosAtvlkqw6TX3jN1lm6sAqVk48DWot14TM 2Jcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc; bh=k8a+bKNK69+MyfNKRMyiIlmsISgLwkF/LDdoDWCfU2o=; b=R/r98iFBV7MJlGXjiujhPPiOcpelYsi7J7j8e4lJ904MgIL49r2Nik5MbN5x9l3Lmq 4OzvV4MkBxwUIfQ4dNQfwf60KWGU6A3YMgJR0XvmXdoMNy33wJpiFKGo98MsJuzKXbbf CaZzxcnYXK5N3XaQGGqSukZUGPo8LR/yObQzqchIUn8P/8ve2LHLBSkhVFs+g9wC7Ss1 6F5orp+BrAQp+gx0yQptam6brWmP2fBPm/t0gZwGd5Y86Cujz1JP0XvOtvSGuiu4Mpux oLkNSWWQdfEdq9tsGXn2Z9LkhXJxiZ24YMqNuzy8I36AZLcQK4Qzu8xFKnX26UfC1dWn YTMQ== X-Gm-Message-State: AFeK/H2Pa6ZcdmF+o8TrbMMBP2xrdH86qHDySOs2Emr526rF+xaLCWut7yF9yW4lS6+n6lK+wIeK2u7xDr1XHw== X-Received: by 10.28.194.7 with SMTP id s7mr178310wmf.34.1489168157915; Fri, 10 Mar 2017 09:49:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.130.19 with HTTP; Fri, 10 Mar 2017 09:49:17 -0800 (PST) From: Behcet Sarikaya Date: Fri, 10 Mar 2017 11:49:17 -0600 Message-ID: Subject: SADR Overview Document To: "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:49:21 -0000 Dear all, Our SADR Overview document has been published as RFC 8043, https://www.ietf.org/mail-archive/web/ietf-announce/current/msg16209.html The authors would like to acknowledge comments from Mikael and Philip whose comments have been incorporated but names could not be mentioned in the Acknowledgements. Regards, Behcet From nobody Fri Mar 10 11:31:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7531F129554; Fri, 10 Mar 2017 11:31:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UHmClWkrAm7E; Fri, 10 Mar 2017 11:31:06 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635E11296F5; Fri, 10 Mar 2017 11:31:06 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id 77so42096883pgc.1; Fri, 10 Mar 2017 11:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=U/keh6CNDXu7D2uULFdmBpwHGeTsZ1RmZwbLGCiLpxI=; b=AGlAh6bxwv6bRkbYkEOhBuFQqRtxwm4Ag3oxrvHGMEALj8YmeuxakppmB7lEO5gcUR fK4hRF1brhqiUhjYYYTi6glwZMzZW52cUHH34nBXwxV17y8FxZKnxM1aMVu3/lHg9XiR w7OjVYf5ZAC88k/pEx/1WAxsM6382t0Rh6l9TP7WuwQ4HYE7c7wfYKIp4yncYlL7vJQ/ 5YBV+ccYrAsb+m4zHNbIvGTkIRMZAqsy8MMQ+IpjvAInTW4foEDWh5hjq1aWpNZ2RyDg E9TiYdSvdd5rfIfEkH52ZyoLirJVOtGytfgZp1CFuZcU2xJzPDl7siCehUdpKe9fHKvu sepQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=U/keh6CNDXu7D2uULFdmBpwHGeTsZ1RmZwbLGCiLpxI=; b=ulE/yXSy1NcpJMlbZg434XWAcMqwWqhyH+XhKTQsvQt5xCI9UjLcW3VehjkIt6kR3Q H2uf9jZ0fIA5kjxP261YBl/8Wx8Vw4c3u6KGP7HOL965FyWV5S04jbkRl47OCspPpziM BlyrAYQfNhINi2H+hzXkAmkIeB04qs6/Q/J9frgVe1NHOkiRoqFaE2vnFe0SiRpR8mri x/kjHWt0wLBqKcb5oGMCd/Ka6817Q+rSDNyv43XQcDM/k+6llbTrE2VMMTTFlbqNNHMV euR5zRhJHFtcI2nl9ka9CV0gX6hMY4b1bFujZzcm5ZbGR+HftK3YeSI7SNyI8WhZ6+tp UL7Q== X-Gm-Message-State: AMke39kxd/7OKhOD3WQmymzfhwdKfdiZ++LqmJKADAXZ24rRozwRYIV97cDjQCo4H5ePuA== X-Received: by 10.84.224.11 with SMTP id r11mr28371736plj.130.1489174265972; Fri, 10 Mar 2017 11:31:05 -0800 (PST) Received: from [192.168.178.26] ([118.149.108.74]) by smtp.gmail.com with ESMTPSA id 80sm20215851pgd.39.2017.03.10.11.31.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 11:31:05 -0800 (PST) Subject: Re: DHCPv6 subscriber learning default gateway To: Naveen Kottapalli , sthaug@nethelp.no References: <20170310.080331.41692443.sthaug@nethelp.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: <268482ea-d5c1-ba1c-4c89-e0abdc709c96@gmail.com> Date: Sat, 11 Mar 2017 08:31:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 19:31:07 -0000 On 10/03/2017 20:43, Naveen Kottapalli wrote: > +v6ops, 6man > > Yours, > Naveen. > > On 10 March 2017 at 12:41, Naveen Kottapalli wrote: > >> Okay. Can you tell which parameters of RA will convey the default gateway >> address? You need to read RFC4861 to understand the relevant details of RA. >> Also, can you point me to the document where it is mentioned that >> a DHCPv6 subscriber has to use RS-RA for resolving gateway address? Section 7.2.2 of RFC6434 explains this (but the wording could be clearer, perhaps). The basic point is that RFC4861 is effectively mandatory and DHCPv6 is optional. You are not the only person who thinks this is a gap in DHCPv6. Brian From nobody Fri Mar 10 11:48:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BEB1299A8; Fri, 10 Mar 2017 11:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 YwL3GjG7Z4a4; Fri, 10 Mar 2017 11:48:04 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2137D129998; Fri, 10 Mar 2017 11:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1968; q=dns/txt; s=iport; t=1489175284; x=1490384884; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gzUWss6CE5URYu4szaCvcIT1Yt/K4iysMScRsb4NDwg=; b=g8MutaxHEmPejWfyr0X/KUHyGs3dmupdROdGS1z1801QW4aFz0sp1+YW TMFt2x6+vHl3ql7pKH8l3uVdmc1wr8hkqaHpw0YgDc0G4JUo1wzMe/Ruy QPQGKWDy+Ft33zM7O7CZTqCh6zpZ29U53OBg4o8IBUHFicx5QoyFAAaT0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAgAUAsNY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDpExH4gNjSuCDh8LhXgCGoInPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEhETkBCwULAgEIGAICJgICAh8GCxUQAgQBDQWJaAMNCA6xb?= =?us-ascii?q?YImhzgNgyMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELh0gIgmKCUYIDF4JvLoI?= =?us-ascii?q?xAQScAjoBjgyEK4F7iHmGMIpUiGsBHziBA1cVPxEBhkN1AYkMgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,142,1486425600"; d="scan'208";a="396474646" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2017 19:48:03 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v2AJm3LH023328 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Mar 2017 19:48:03 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Mar 2017 13:48:02 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Fri, 10 Mar 2017 13:48:02 -0600 From: "Bernie Volz (volz)" To: Brian E Carpenter , Naveen Kottapalli , "sthaug@nethelp.no" Subject: Re: [v6ops] DHCPv6 subscriber learning default gateway Thread-Topic: [v6ops] DHCPv6 subscriber learning default gateway Thread-Index: AQHSmWR8wotauR0xoEuRbV4A/hR6rqGOCqaA//+mxQiAASoggP//sOMA Date: Fri, 10 Mar 2017 19:48:02 +0000 Message-ID: References: <20170310.080331.41692443.sthaug@nethelp.no> <268482ea-d5c1-ba1c-4c89-e0abdc709c96@gmail.com> In-Reply-To: <268482ea-d5c1-ba1c-4c89-e0abdc709c96@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.196] Content-Type: text/plain; charset="utf-8" Content-ID: <867912100F86EC459B6564F51FC5F34C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dhcwg@ietf.org" , v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 19:48:05 -0000 PiAgICBZb3UgYXJlIG5vdCB0aGUgb25seSBwZXJzb24gd2hvIHRoaW5rcyB0aGlzIGlzIGEgZ2Fw IGluIERIQ1B2Ni4NCg0KQXMgYSBESEMgV0cgY28tY2hhaXIsIGlmIHY2b3BzIGFuZCA2bWFuIGJl bGlldmUgdGhpcyBJUyBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkIGluIHRoZSBE SENQdjYgcHJvdG9jb2wsIHdlIGNhbiBjZXJ0YWluIGRpc2N1c3Mgd2l0aCBvdXIgQUQgdG8gdGFr ZSBpdCBvbi4gSW4gdGhlIHBhc3QsIGl0IHNlZW1lZCB0aGUgdmlldyBmcm9tIHRoZXNlIFdHcyAo cGVyaGFwcyBtb3N0bHkgNm1hbikgd2FzIHRvIGxlYXZlIGl0IGZvciBSQSB0byBjb252ZXkgdGhl IGRlZmF1bHQgZ2F0ZXdheS4NCg0KLSBCZXJuaWUNCg0KT24gMy8xMC8xNywgMjozMSBQTSwgIkJy aWFuIEUgQ2FycGVudGVyIiA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCg0K ICAgIE9uIDEwLzAzLzIwMTcgMjA6NDMsIE5hdmVlbiBLb3R0YXBhbGxpIHdyb3RlOg0KICAgID4g K3Y2b3BzLCA2bWFuDQogICAgPiANCiAgICA+IFlvdXJzLA0KICAgID4gTmF2ZWVuLg0KICAgID4g DQogICAgPiBPbiAxMCBNYXJjaCAyMDE3IGF0IDEyOjQxLCBOYXZlZW4gS290dGFwYWxsaSA8bmF2 ZWVuLnNhcm1hQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+PiBPa2F5LiAgQ2FuIHlv dSB0ZWxsIHdoaWNoIHBhcmFtZXRlcnMgb2YgUkEgd2lsbCBjb252ZXkgdGhlIGRlZmF1bHQgZ2F0 ZXdheQ0KICAgID4+IGFkZHJlc3M/ICANCiAgICANCiAgICBZb3UgbmVlZCB0byByZWFkIFJGQzQ4 NjEgdG8gdW5kZXJzdGFuZCB0aGUgcmVsZXZhbnQgZGV0YWlscyBvZiBSQS4NCiAgICANCiAgICA+ PiBBbHNvLCBjYW4geW91IHBvaW50IG1lIHRvIHRoZSBkb2N1bWVudCB3aGVyZSBpdCBpcyBtZW50 aW9uZWQgdGhhdA0KICAgID4+IGEgREhDUHY2IHN1YnNjcmliZXIgaGFzIHRvIHVzZSBSUy1SQSBm b3IgcmVzb2x2aW5nIGdhdGV3YXkgYWRkcmVzcz8NCiAgICANCiAgICBTZWN0aW9uIDcuMi4yIG9m IFJGQzY0MzQgZXhwbGFpbnMgdGhpcyAoYnV0IHRoZSB3b3JkaW5nIGNvdWxkIGJlIGNsZWFyZXIs IHBlcmhhcHMpLg0KICAgIFRoZSBiYXNpYyBwb2ludCBpcyB0aGF0IFJGQzQ4NjEgaXMgZWZmZWN0 aXZlbHkgbWFuZGF0b3J5IGFuZCBESENQdjYgaXMgb3B0aW9uYWwuDQogICAgDQogICAgWW91IGFy ZSBub3QgdGhlIG9ubHkgcGVyc29uIHdobyB0aGlua3MgdGhpcyBpcyBhIGdhcCBpbiBESENQdjYu DQogICAgDQogICAgICAgQnJpYW4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KICAgIHY2b3Bz QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0KICAgIA0KDQo= From nobody Fri Mar 10 13:11:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402BF1293F3; Fri, 10 Mar 2017 13:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 IvTqChB2-6SL; Fri, 10 Mar 2017 13:11:31 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 17F7A120725; Fri, 10 Mar 2017 13:11:31 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 10 Mar 2017 21:11:29 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 86A53D788A; Fri, 10 Mar 2017 13:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=bAlVRitQbnu/eQ79+C/1laNCg94=; b= N8+xPrz0Ad70jCsNyNGNVOVxLjGHjFh/QOoL3ESIvf/beDVzZdjrYl9ck0+FdxN9 p5vxSR7+DLHV5u0NCNCmNF7fPMTywtk4Yg4cmYxbsmWJbCT1lzd3g8StiDcJ+cVp Xt1wSnv5QGITPtf+Sq24UwlS0yTYOOdr8xmlqvUkXYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=a8UCjgNnldQGh8mZrnJWX2K gYic/2qIDyfqE7bmemTrWWDvrCMaXKIjAGkw5BarUKGTnhl22+ix4CE42qYmHyNo L5OzYhzE5qGmXyCBlBY9loA5X1tdnUr1jOZk1PzB61kbqxU/XCAQop0Qgp8wpBfl ziwyk0KKqBYiwWhGzCsA= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 5AF2ED788D; Fri, 10 Mar 2017 13:11:29 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E3E669B1928C; Fri, 10 Mar 2017 22:11:27 +0100 (CET) From: otroan@employees.org Message-Id: <3F64E796-5126-4405-8A81-AD9BAB6B7838@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F94854D2-09AA-43B9-82C0-6A1D6CE5B608"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] DHCPv6 subscriber learning default gateway Date: Fri, 10 Mar 2017 22:11:27 +0100 In-Reply-To: To: "Bernie Volz (volz)" References: <20170310.080331.41692443.sthaug@nethelp.no> <268482ea-d5c1-ba1c-4c89-e0abdc709c96@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops list , 6man WG , "dhcwg@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 21:11:32 -0000 --Apple-Mail=_F94854D2-09AA-43B9-82C0-6A1D6CE5B608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> You are not the only person who thinks this is a gap in DHCPv6. >=20 > As a DHC WG co-chair, if v6ops and 6man believe this IS something that = should be addressed in the DHCPv6 protocol, we can certain discuss with = our AD to take it on. In the past, it seemed the view from these WGs = (perhaps mostly 6man) was to leave it for RA to convey the default = gateway. if the only tool you have is a hammer... stop beating a dead horse. it hurts. Ole --Apple-Mail=_F94854D2-09AA-43B9-82C0-6A1D6CE5B608 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwxZ/AAoJEL7aWKiYQt9222AP/AqLQWnD2pFlPhc8X/jbE3/E ovYm/QHVvgZNRQUB47IMP1Xj2q1jsVVTrXCO+KpEZ3iyzUpa+cfyphGJ4CDBL3hf 7jzEl+tZu8TqOSJQ7dmjIr29NAlfJxcni/vtZ47qB+NXIEHgsp8RVGXCXHhYdPlW 7bGk//aokbyxE8rSYzdkJD6j5W6EqhZe65/9YQvwiu2P2SZt79BkB79ea7irj0Sa Qhd+xJdjg+geRTEaPAQq8eD7BE31c8/dcrSsDt8g3SZFrBVn+oRz/Jlv0hf+sRLR gPeDtF6pGYjVjkxmWFTIZ2hxtMFtQCUI29gM7wKDc8PwMV+yhIPZmfZ5MYOHgfTJ jfhgeTaApnSGK1V+Ee9zgdtOkJYA5heTbhf73QtK0/L2pI1aWj04AmNLC7yNUuQI k+Fjv0AdjkLVZTibOtI3laBIgUD9swdOnhyc3GbKzSnozp/oVkxgBxkbtmbsXX1J gX9Y+M3YILIaXs27RqXNlWmtgni6KMWNIi09T0K8bp87wjdqIQlmxHpI9IilSOZR 7gJ6bY5wyuf9QBmsdT/ectgBlTrQjZaV0ds2Muqn2Qgjiqb3kuuLfixMeM5kv5Xt WgViSP1K2dFkUwiwjdr1X85kjxrh7fMaXK1+LzVW2RsiblWd0PkTFLgDqB4zsGTg 7bkVd14txlUsl3EY2PJ+ =UTOM -----END PGP SIGNATURE----- --Apple-Mail=_F94854D2-09AA-43B9-82C0-6A1D6CE5B608-- From nobody Fri Mar 10 19:25:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EF012944B for ; Fri, 10 Mar 2017 19:25:00 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9trNTWUUfk56 for ; Fri, 10 Mar 2017 19:24:59 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B7E126BF7 for ; Fri, 10 Mar 2017 19:24:59 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id u30so132370493uau.0 for ; Fri, 10 Mar 2017 19:24:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f+brqecB75pAqwn0K856u1jLDXKqNPsIYuwz37/Eqj4=; b=hFwWxsgujxiDbbOgFSybXrFsa14xNEY+vNVFoWBd0D9YhHaoQCwyw70m5WXwgVIWV/ 9yPB6w+UdYBlShGbXyzmZ8oAszd8JYWv49mdL0qM0KgpfQyaXUX+SzJOi7l+pkhzE5iI z3pgHmrw7CR70bpr2KNB4fHm8LcAKtMWtrnjDB+RgvrpASjRP+rOwx1WhEFQzawU0gtf rsV9yqXzJV6DXqyi0KGnBKDJnwGRF/CkWrkoaTLjvLHq4u3cddmkYAVxhtMra1b9U+N7 pW6wH2lQp9HkusCWcBPSsHcLS9UbMFEARZFuMnMOEFISrp7uNpJ/b5nI1j+HdxeOtd7n 34gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f+brqecB75pAqwn0K856u1jLDXKqNPsIYuwz37/Eqj4=; b=CpWozojyGu4uUOoD1auCOKUFdhv/y8O3zsx2hI0DbRx0aPD8YwgWW+faBOr2lixYEG EL5dVueGskZRASryX6cGjCgaLQgQmwK3QKysY8Ffx1sjgeTq/XZAtjuT2V6ldffTWO3u XdFD0xyEo8/u6Z8i+tnp/EcvaFO3xWooiZTDBVTHSE8YXWtwtCk3We88McQxvCcjkpUe 7CjiYVbxn+HDDJHTwEL9gG+BGcWMHlmWVmlD/sYykz2yeOhGkrPXvU2EQrRKcPaQSYhn cz/WUICJYGl0NgUW3Oy+vx3ilVRt+kQckdLealtlHrYtN0Z6yIK3ADcFFKCwIrJA7Any 6cAQ== X-Gm-Message-State: AMke39mRX2TjYORzC+BKKvGQyqO2c6X7NFA6vmn0y4IAruiBe6C1S5mpLklozZW9vUgsxzcyHG5WeqfkyXf5iw== X-Received: by 10.176.0.87 with SMTP id 81mr11494316uai.97.1489202698763; Fri, 10 Mar 2017 19:24:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.144 with HTTP; Fri, 10 Mar 2017 19:24:28 -0800 (PST) In-Reply-To: References: From: Mark Smith Date: Sat, 11 Mar 2017 14:24:28 +1100 Message-ID: Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07 To: David Farmer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Alexandre Petrescu , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 03:25:01 -0000 Hi David, On 9 March 2017 at 03:41, David Farmer wrote: > > > On Wed, Mar 8, 2017 at 6:13 AM, Mark Smith wrote: >> >> On 7 Mar. 2017 7:47 am, "Alexandre Petrescu" >> wrote: >> > >> >> Imagine the situation of buying a car, and not being able to drive it, >> because none of its tunable parameters had been set to reasonable >> defaults. Mechanics wouldn't have a problem, and may enjoy the >> experience of setting all the parameters to make the car work. The >> rest of wouldn't find buying a car an easy experience at all. >> Mechanics would lobby against making cars (literally) turn-key, >> because they would be making money from setting all the parameters. > > > Following that analogy, I'd agree that most cars have default parameters and > they should, but almost all car actually have parameters, sometime thos > parameters are exposed to the most naive users, not just expert users. > (e.g. many cars have a Sport/Econo button on the dashboard, and then almost > all cars have tunable parameters under the hood). > In my analogy, I'm describing a car that literally will not work (i.e., not start) because none of the parameters have been set to default reasonable values, they've all been left as zero by the factory. So after you've paid the car dealer, the first thing you then have to pay is a car mechanic to then come and set the parameters so that you can drive the car e.g., the mechanic would have to be engaged to set the spark plug timing and the fuel injector sequence because the ECU would not have working defaults for those and many other similar parameters. It seemed that the argument Alex was making (by suggesting the RIRs should pick) and I think others are making against 64 bit IIDS is that "some people don't agree with that value, so the IETF shouldn't be providing a default value." By that argument, there are also many other IETF parameters that shouldn't have default values e.g., OSPF hello intervals, TCP timeouts etc. There would probably be close to 100 that need to be set to a working set of hosts talking across a working network. The sport/economy car parameter you used as an example is overriding a default, and it is entirely optional to change it. Making it mandatory to set, every time you started the car, because there was no default, would not be very car user friendly. I think the only parameters that should be exposed to end-users of computers are ones that take very little and ideally no technical expertise to understand, and are entirely optional to change. Even then it is good to hide them away if possible to reduce UI complexity and confusion. I like the Arthur C. Clarke quote - "Any sufficiently advanced technology is indistinguishable from magic." We should be trying to make our technology magic as possible, and reasonable, power-on defaults is a very good way to do that. > Lorenzo seems to be arguing that all cars must not have any tunable > parameters, at least none that are exposed on the dashboard. And I have to > disagree. > I think it is a good goal, as it means that the user of the device doesn't have to make decisions about the operation of the device and therefore learn enough to make those decisions. I do think there can be exceptions though - I commonly run my Android phone down to 15%,when battery saver mode kicks in. Usually I'm not far away from being able to charge it, and want to be able to continue to use it at full speed, so I override the battery saver mode. Similar to your sport/economy example, it's an optional override, and doesn't require much technical understanding to make the correct choice. Regards, Mark. From nobody Sat Mar 11 00:57:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40221279EB for ; Sat, 11 Mar 2017 00:57:19 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 FBw50vKYWEAm for ; Sat, 11 Mar 2017 00:57:15 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3B126D73 for ; Sat, 11 Mar 2017 00:57:15 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 11 Mar 2017 08:57:14 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 755F4D788B; Sat, 11 Mar 2017 00:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=ETh3qLU1U6kiV1bkquZJg+0WSmY=; b= n+bNmYW247NOKe1thadnM/LAUus+2Ul/ztPlQHxaErN7WRHtdL95g3wurXBjh3TB ZpsHLySTfNpYSwItfcwArguS7/6kGu/QkvVhSDi//IJO6LPsiv4+zaH/edVXdOIx YXB1HCVJ6YNiVYsr1tOxTs1/r8URXGUJBiEj4Nm2nwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=jCsfKL+5HGiKu2Pc7uRPKRX JJYcvH/XF1bdnDgUbKI4geVRExRwaV7p7f+Uc2lsoyZpMEtS7aSl/zAhtSJs7tv5 zhbWL5baQ1iFGyv1hKEhGUUJ/asNpNMwoC1HC15VKymteU8NOYpbT/kM8XEgp3Gt DOmAwFyXzDfq5FOnwFhQ= Received: from h.hanazo.no (77.16.46.37.tmi.telenormobil.no [77.16.46.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 8E39DD788A; Sat, 11 Mar 2017 00:57:13 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0BBCF9B8161D; Sat, 11 Mar 2017 09:57:08 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_13BA574D-0299-452B-8DD2-EB79C833DA1D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Date: Sat, 11 Mar 2017 09:57:07 +0100 In-Reply-To: To: =?utf-8?B?56We5piO6YGU5ZOJ?= References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: james woodyatt , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 08:57:19 -0000 --Apple-Mail=_13BA574D-0299-452B-8DD2-EB79C833DA1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jinmei, Is there anything here that isn't covered by 5942? And creating an artificial separation of prefixes used for address = assignment (SLAAC) and prefixes used for on-link determination seems = fraught with dangers. E.g. from a router perspective you need a = connected route aka an onlink prefix for the prefix used for address = assignment, otherwise you have no reachability. O. > On 9 Mar 2017, at 22:11, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Thu, 09 Mar 2017 19:30:11 +0100, > Philip Homburg wrote: >=20 >> If your use of the term 'subnet prefix' only refers to (stateless) = address >> configuration and not to being onlink or not, then I agree about the >> concept (but not the term). >>=20 >> However, where IPv6 clearly separates address configuration from = being onlink, >> calling a prefix that is only used for (stateless) address = configuration >> 'a subnet prefix' is very confusing. >>=20 >> At the same time, calling some onlink prefixes 'subnet prefixes' and = others >> 'other unicast routing prefixes' is also very confusing if they are >> announced using the same L flag in a PIO option in a router = advertisement. >> I.e, whether or not the A flag is set in PIO option, should not have = an effect >> on what we call an onlink prefix. Or on how we describe onlink = prefixes and >> what their properties are. > [...] >> So if we want to say that prefixes used for stateless address = configuration >> MUST/SHOULD be 64 bits long, whereas onlink prefixes can be of any = length, >> then we should at least use clear terminology that separates prefixes = for >> stateless address configuration from other uses. >=20 > +1. I've also been feeling that one source of seeming confusion in > this discussion may be confusion between "subnet prefixes" and > prefixes for on-link determination as described in RFC4861. In fact, > the latter (I'll use the term "onlink prefix" in this message) has > nothing to do with "subnet prefixes" - it simply specifies a set of > addresses that should be supposed to be on-link for the corresponding > link. Whether or not we adopt "conservative" or "liberal" view of the > length of IIDs or "subnet prefix" in the context of addressing > architecture, an onlink prefix can be longer or shorter than a > subnet prefix even if these two share some leading bits. >=20 > So, for example: > - if we adopt the "conservative" address architecture, > The subnet prefix for 2001:db8:1:2:3:4:5:6 must be 2001:db8:1:2::/64. > - if we adopt the "liberal" address architecture, > The subnet prefix for 2001:db8:1:2:3:4:5:6 can be 2001::/16, > 2001:db8::/32, 2001:db8:1::/48, 2001:db8:1:2::/64, > ...2001:db8:1:2:3:4:5:0/120, etc. > and, in either case, > - onlink prefx in this link advertised via an RA with L=3D1 can be > 2001::/16, 2001:db8::/32, 2001:db8:1::/48, = ...2001:db8:1:2:3:4:5:0/120, etc. >=20 > In particular, the fact that onlink prefix can be of any length > doesn't mean it violates the conservative address architecture. >=20 > Perhaps one source of confusion is the fact or expectation that RA PIO > often both sets A and L bits on. So, in the above example, if we have > a PIO for 2001:db8:1::/48 or 2001:db8:1:2:3:4:5:0/120 with both L and > A bits on, these are valid on link prefix. But they can't be used for > SLAAC (assuming its link-layer spec specifies the consistent IID = length > with the "conservative" address architecture, i.e., 64). That is, for > the same PIO, > - if we consider it as on-link prefix, it can coexist with any of the > address architecture > - if we consider it for SLAAC, it can only coexist with the > conservative architecture, or liberal one with an exception of > requiring 64-bit subnet prefix length specifically for SLAAC >=20 > BTW while writing this message I saw a warning from Brian: >=20 >>> Isn't it time we all shut up and wait for the document editor to >>> propose text? >=20 > I don't want to contribute to making this thread even longer, so I > promise I'll stop here. But I wanted to make this one remark since > I believe it's important to clarify that ("on-link prefix" is > irrelevant to the address architecture discussion) and I see why this > can be so confusing. Even if this attempt of mine fails, I'll shut up > now (maybe I should write a separate draft just focusing on this > particular confusion). >=20 > -- > JINMEI, Tatuya >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_13BA574D-0299-452B-8DD2-EB79C833DA1D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYw7vjAAoJEL7aWKiYQt92zwQP/0bwAqrBeti4kw4jiddntUBZ U8pXzy0JMjH2i5Xkq67mR4Dde2WxMLKBkk6F7JGeJT+csOWcjzGESxY6gct5ojlC vQpIzGESWeeqCWNXx6Ksf0c6Riu+s8q6Z66WitfT5/me7rcUyUlA6YwnfkW0DJfF DRdCCgJNUXVSTcNpcgNwJc0yv4aDdDUhBYX71Kj35dWOlTRutMQySxb0DkVgUI5x pd07f32etNk/A9wRGJQTSZQQbbqu2q/AIWN8YzQvV1eKLNykUw1cFs1OAhCP0SIe JCbqazZEo7Ay4+JxfiN4ZL7VgyOIOyH2780166aQHx+vAnRf3ajvjbpdtK5R3GWa 9HzfQTfizA+5UVNKtRUi+Xdgqx9UPIVVqaAaP8kw7kU/AuE4wi5FkqMtOVhfuLQN c75pLx2zaBgWaalDsvRYcNxcBmPPLwhd+871ECcRNL4CD1PF+lUK1En6y+5crhAt cbMhThb1MGNjgd4s95nqz7RyQs2Cg/XOO32+cvnBa5hwTjfHRLXV+drbuwElI8t+ o3DcEiCDom72aw4MF4JL+WgsdSQt/Rs0hGSce+lzonftkf9Gnn4rDMS1Er9SfMYM ID5ne4Y51bbNyL/KSXGtxajfxa1PCc9/smO9hrrriH/NLb0uQR7rDwlyoVdY88wx EbPAcrGPp6kD8YWyA+Fe =/pCx -----END PGP SIGNATURE----- --Apple-Mail=_13BA574D-0299-452B-8DD2-EB79C833DA1D-- From nobody Sat Mar 11 03:49:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1F51204D9 for ; Sat, 11 Mar 2017 03:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 tpRtuCRwKVia for ; Sat, 11 Mar 2017 03:49:30 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A50C3129418 for ; Sat, 11 Mar 2017 03:49:28 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cmfWW-0000HaC; Sat, 11 Mar 2017 12:49:24 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> In-reply-to: Your message of "Sat, 11 Mar 2017 09:57:07 +0100 ." Date: Sat, 11 Mar 2017 12:49:23 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 11:49:31 -0000 > Is there anything here that isn't covered by 5942? > > And creating an artificial separation of prefixes used for address > assignment (SLAAC) and prefixes used for on-link determination > seems fraught with dangers. E.g. from a router perspective you need > a connected route aka an onlink prefix for the prefix used for > address assignment, otherwise you have no reachability. It seems to me that RFC 5942 doesn't say a lot about stateless address configuration. So if we want to say something like 'the IID used for SLAAC should be 64 bits' then RFC 5942 is not of help. The classical example where a prefix is not onlink is NBMA networks. But I can imagine that once IPv4 is out of the way, people will find more creative uses where it helps if a prefix that is used for SLAAC is not onlink. Note that in the context of ND, onlink prefixes is mostly about host behavior, because routers are (in practice) not using them to configure what is onlink or not. Also note that hosts may consider a prefix not onlink whereas the router considers the prefix onlink. ND can handle that. From nobody Sat Mar 11 04:10:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEC91294A4 for ; Sat, 11 Mar 2017 04:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.026 X-Spam-Level: ** X-Spam-Status: No, score=2.026 tagged_above=-999 required=5 tests=[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.626, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xMtqTzPRCBij for ; Sat, 11 Mar 2017 04:10:55 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF88129422 for ; Sat, 11 Mar 2017 04:10:55 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 72so133266292uaf.3 for ; Sat, 11 Mar 2017 04:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gxYGFbHkYbTmQjDaSV0+60tCF7dQpyif9C66iW0LdEw=; b=WytxCaGPlfq3LoJCwQaBv5dTa7PoT4655IwqtPdB8a12DEdQQMKCAic8ajsApqWbN1 B4B0zwvSaTum9RMxOtokv+TwwHHm0howEHascyCS7BxI3LeUhk8PGl8YoiuNSouNcvtI wkw2Sq525nEm1V+7jW/LqbWphxXCRpdSK+GeVUmPvrKzLyeI75zMU849jJLxwWXrlS9X CwEo+B7gbZxY6iOgnrn7IYfvyxsLEecxXpU/sQjWX/5TVXnzv2x2icXCWP8T5ynVkpER 1QKBrc3gtqulltvOCUwThPsTm8nKw8A1oOTZRSRMsIgHYyMxy8N0Fenrm1NQ05d3/4sL kLIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gxYGFbHkYbTmQjDaSV0+60tCF7dQpyif9C66iW0LdEw=; b=BUiiKsf7lEKW7odxACMoX+jxIovLeMeIvRGXHEUV8nr4qu0a4qBElyAXoi42xzBiVd 2rCgepkUhVhJCoOJNj5Qo3Zlp7TzK+B7He0mpijhXgUoE1jqac3x7ePWmlxpOcQX4dsj xtn3xgcdaxoXSWgMH8LAKxE304fHH80XvdvUHshkxKGA0RGpyzeRYZunPqGCY9tfP3lO 7tASO+3AMZIGi81vaixMlr5ZFFsQ2PTGRIYLYOqLRB1LEvfXoIdnfD1LJbGueiMC9K5C I3nChFpC9GTGqAewJ2l1ngHv/zFXlK1YupvsFxyEbB6fCjWhfdY/o0eEMHUtOkXK4HR4 QLCA== X-Gm-Message-State: AMke39lDj2UYtBdlAA+hB7QZBHqilhEkHWanpytJ2Cv4BXOurjRRN+5sqwz93wMSshFi5giVkzOl2Zz3Y9IodQ== X-Received: by 10.176.83.79 with SMTP id y15mr10284982uay.141.1489234254290; Sat, 11 Mar 2017 04:10:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.144 with HTTP; Sat, 11 Mar 2017 04:10:23 -0800 (PST) In-Reply-To: References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> From: Mark Smith Date: Sat, 11 Mar 2017 23:10:23 +1100 Message-ID: Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis To: Philip Homburg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 12:10:56 -0000 On 11 March 2017 at 22:49, Philip Homburg wrote: >> Is there anything here that isn't covered by 5942? >> >> And creating an artificial separation of prefixes used for address >> assignment (SLAAC) and prefixes used for on-link determination >> seems fraught with dangers. E.g. from a router perspective you need >> a connected route aka an onlink prefix for the prefix used for >> address assignment, otherwise you have no reachability. > > It seems to me that RFC 5942 doesn't say a lot about stateless > address configuration. So if we want to say something like 'the IID used > for SLAAC should be 64 bits' then RFC 5942 is not of help. > > The classical example where a prefix is not onlink is NBMA networks. > But I can imagine that once IPv4 is out of the way, people will find > more creative uses where it helps if a prefix that is used for SLAAC is not > onlink. See slide 18 onwards. https://www.slideshare.net/MarkSmith214/ipv6-ras-mostly-necessary > > Note that in the context of ND, onlink prefixes is mostly about host > behavior, because routers are (in practice) not using them to configure > what is onlink or not. Also note that hosts may consider a prefix not onlink > whereas the router considers the prefix onlink. ND can handle that. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Mar 11 04:18:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7B4129418 for ; Sat, 11 Mar 2017 04:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham autolearn_force=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 ewKoMJacD4OG for ; Sat, 11 Mar 2017 04:18:03 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 54B271293D9 for ; Sat, 11 Mar 2017 04:18:03 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cmfyA-0000IFC; Sat, 11 Mar 2017 13:17:58 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: Your message of "Thu, 9 Mar 2017 00:19:21 -0800 ." <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> <9f6ea52b7ac741ae9f95e9901d1a3bd1@XCH15-06-11.nw.nos.boeing.com> In-reply-to: Your message of "Thu, 9 Mar 2017 19:28:48 +0000 ." <9f6ea52b7ac741ae9f95e9901d1a3bd1@XCH15-06-11.nw.nos.boeing.com> Date: Sat, 11 Mar 2017 13:17:55 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 12:18:04 -0000 > If you want random, a PRNG can create any length of IID. A 48-bit > IID would be just as reasonable, and it could be formed from a > randomly changing link layer address. The way I see it is that for pseudo-random IIDs we should set the minimum length such that statistically a collision between addresses never happens. Obviously collossions will happend due to implementation errors, but I think the abstract model should have an extremely low chance of collossions, ever. It is easy enough to argue that 64 bits is enough. It is also easy enough to argue that 32 bits is not enough. Would 48 bits work? That's a matter of estimating how big the IPv6 network will grow. Another way of looking at this, why would we need IIDs that are less than 64 bits? The current IPv6 address architecture has no problems supporting 64 bit IIDs. There doesn't seem to be any technical reason to risk a higher chance of collissions by lowering the number of bits. Instead, the argument used for those is that some operators did something stupid and assign only a single /64 to a collection of links. This, despite all efforts initially to make sure that /48s were assigned. So it is reasonable to assume that if we would fully support /80 prefixes in SLAAC, that some operators would again not read/understand our address architecture and just assign a single /80 and we a back to square one. So modifying hosts to generate IIDs smaller than 64 bits would have benefits in the short run, but it the long run trades an increase in risk of collission for no benefit at all. From nobody Sat Mar 11 04:52:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DE81294E3 for ; Sat, 11 Mar 2017 04:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.026 X-Spam-Level: ** X-Spam-Status: No, score=2.026 tagged_above=-999 required=5 tests=[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.626, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zvIFU_3EeaAP for ; Sat, 11 Mar 2017 04:52:20 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A3D127071 for ; Sat, 11 Mar 2017 04:52:20 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id f54so128909189uaa.1 for ; Sat, 11 Mar 2017 04:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q3k+bZRn4e26YSWKNr3h1uQUzjFzvO7VtAnTb7O6+As=; b=s8f6g15ynfry7fAYWBqpxcXeQSzDOiNzpzJoQDZH3z4jClfoRHToHwpHY8Mo0mYaRX ZbRBGGYm5M2t3J4QRLOtrDPUZYvYaBokFdvcwm01GRramCWVkdLZMKJmx1givLVI5sMr RIehFKNXm/Nv+z9883Xx5c9WZg4o25Pp/MQqGQUWzab4pjqyZHGxawYDTfopYIw71D5v vXJPpINH9XIe144YKd4qE/Rr87sDFh6fZSOat+lok517lSBQ6AEp5P3IoWOzgICQXLHG V2j4RD5/h6Q8PUwsbbDA2dVfQuwqhxvGHVJXue3f1ObN3yLTWudRjJBz22E9aEGpFOsh AlPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q3k+bZRn4e26YSWKNr3h1uQUzjFzvO7VtAnTb7O6+As=; b=mysVLgJqHDAcb0qbUVPf4YdVXb6IPSCK32lQRUJvNdHDezXdF1I8yVOa2nGZh8F9JG Idd86R31swGNifLay97oxrJ9cGu3utpbpVmMSYv7jauHFkL/a1vdlpeYZK/8ZdSDjewp wrysLGQnod8w4PTtOvYjg4ckxOabcGeeEZy/xXmQ9HcR4kbrNAGfUVV/cGd7ytGsNhNO 3YkOcbcXZ1Qw0atpN8ihWuclDoPJ5b9KUSC2sZ6pUoNxdHT5ehLD04h303exIF05PdHI LwNMegcT1zpnnq57zSzx8j2QRrOGTRgXjzRzdOTN+T5Gp7J1qXn5lfnpt5zlDO7+d+Sn WT3g== X-Gm-Message-State: AMke39kBFm0LqepHvHQQi5mVwJcdBldp9dFEspOUZCarxr7UOU9dTwdiL4+pmVXbrl9g76GSpUh6XL2oUkCXCA== X-Received: by 10.159.48.193 with SMTP id k1mr10346458uab.49.1489236739805; Sat, 11 Mar 2017 04:52:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.144 with HTTP; Sat, 11 Mar 2017 04:51:49 -0800 (PST) In-Reply-To: <9f6ea52b7ac741ae9f95e9901d1a3bd1@XCH15-06-11.nw.nos.boeing.com> References: <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> <9f6ea52b7ac741ae9f95e9901d1a3bd1@XCH15-06-11.nw.nos.boeing.com> From: Mark Smith Date: Sat, 11 Mar 2017 23:51:49 +1100 Message-ID: Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis To: "Manfredi, Albert E" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 12:52:21 -0000 On 10 March 2017 at 06:28, Manfredi, Albert E wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg > >> The first interface identifier concept is that for any prefix of >> length n, the length of the interface identifier is 128-n. Let me >> call this prefix-iid. >> >> The second iid concept is in auto configuration of addresses. I'll >> call this slaac-iid. >> >> The way I see it, any slaac-iid that is based on (pseudo)-random >> number has to be at least 64 bits. I don't see any reason for more >> than 64 so exactly 64 sounds about right. > > If you want random, a PRNG can create any length of IID. A 48-bit IID would be just as reasonable, and it could be formed from a randomly changing link layer address. > You two have read "Analysis of the 64-bit Boundary in IPv6 Addressing" https://tools.ietf.org/html/rfc7421 haven't you? 48 bit IIDs were given up between RFC1883 and RFC2373. Regards, Mark. From nobody Sat Mar 11 08:49:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0A129541 for ; Sat, 11 Mar 2017 08:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.175 X-Spam-Level: ** X-Spam-Status: No, score=2.175 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 0n3tgwYGLl7I for ; Sat, 11 Mar 2017 08:49:39 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB8412953F for ; Sat, 11 Mar 2017 08:49:38 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2BGnaA2009377 for ; Sat, 11 Mar 2017 17:49:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B6395207AF2 for ; Sat, 11 Mar 2017 17:49: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 AC44C207704 for ; Sat, 11 Mar 2017 17:49:36 +0100 (CET) Received: from [132.166.84.23] ([132.166.84.23]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2BGnZWG013303 for ; Sat, 11 Mar 2017 17:49:36 +0100 Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis To: ipv6@ietf.org References: <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> From: Alexandre Petrescu Message-ID: <4bff6311-1b9b-a861-bb11-b8a5b4d44cb8@gmail.com> Date: Sat, 11 Mar 2017 17:49:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 16:49:40 -0000 Le 11/03/2017 à 09:57, otroan@employees.org a écrit : > Jinmei, > > Is there anything here that isn't covered by 5942? > > And creating an artificial separation of prefixes used for address > assignment (SLAAC) and prefixes used for on-link determination seems > fraught with dangers. E.g. from a router perspective you need a > connected route aka an onlink prefix for the prefix used for address > assignment, otherwise you have no reachability. Further, I disagree that a distinction between on-link prefix and SLAAC prefix favors continuation of the 64bit IID, and of the 64bit limit for that matter. A situation can be created where a SLAAC prefix is /64 and a distinct on-link prefix is of plen /65 on that same link. But this situation is not desirable. Because a Host that configures itself an address within the /64 may in some cases not be visible to the ND of another Host on that same link; that other Host used on-link determination with a /65 to find out whether it is on link or not. This problem of visibility is very clear especially if a default router is absent on that link (subnets isolated from the Internet). If a default router is present, then this visibility problem may not be that obvious. This is why the distinction between the plens of an on-link prefix and of a SLAAC prefix on same link is not something good. These two plens should be the same. And when they are the same (the prefix for on-link determination, and the prefix for SLAAC), they must have the same plen. And that plen can be anything from 1 to 128. Finally, yes, it is possible to have multiple prefixes on same link. But these prefixes should be paired: on-link prefix1 and SLAAC prefix1, onlink prefix2 and SLAAC prefix2, and so on. Alex > > O. > >> On 9 Mar 2017, at 22:11, 神明é”哉 wrote: >> >> At Thu, 09 Mar 2017 19:30:11 +0100, Philip Homburg >> wrote: >> >>> If your use of the term 'subnet prefix' only refers to >>> (stateless) address configuration and not to being onlink or >>> not, then I agree about the concept (but not the term). >>> >>> However, where IPv6 clearly separates address configuration from >>> being onlink, calling a prefix that is only used for (stateless) >>> address configuration 'a subnet prefix' is very confusing. >>> >>> At the same time, calling some onlink prefixes 'subnet prefixes' >>> and others 'other unicast routing prefixes' is also very >>> confusing if they are announced using the same L flag in a PIO >>> option in a router advertisement. I.e, whether or not the A flag >>> is set in PIO option, should not have an effect on what we call >>> an onlink prefix. Or on how we describe onlink prefixes and what >>> their properties are. >> [...] >>> So if we want to say that prefixes used for stateless address >>> configuration MUST/SHOULD be 64 bits long, whereas onlink >>> prefixes can be of any length, then we should at least use clear >>> terminology that separates prefixes for stateless address >>> configuration from other uses. >> >> +1. I've also been feeling that one source of seeming confusion in >> this discussion may be confusion between "subnet prefixes" and >> prefixes for on-link determination as described in RFC4861. In >> fact, the latter (I'll use the term "onlink prefix" in this >> message) has nothing to do with "subnet prefixes" - it simply >> specifies a set of addresses that should be supposed to be on-link >> for the corresponding link. Whether or not we adopt >> "conservative" or "liberal" view of the length of IIDs or "subnet >> prefix" in the context of addressing architecture, an onlink prefix >> can be longer or shorter than a subnet prefix even if these two >> share some leading bits. >> >> So, for example: - if we adopt the "conservative" address >> architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 must be >> 2001:db8:1:2::/64. - if we adopt the "liberal" address >> architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 can be >> 2001::/16, 2001:db8::/32, 2001:db8:1::/48, 2001:db8:1:2::/64, >> ...2001:db8:1:2:3:4:5:0/120, etc. and, in either case, - onlink >> prefx in this link advertised via an RA with L=1 can be 2001::/16, >> 2001:db8::/32, 2001:db8:1::/48, ...2001:db8:1:2:3:4:5:0/120, etc. >> >> In particular, the fact that onlink prefix can be of any length >> doesn't mean it violates the conservative address architecture. >> >> Perhaps one source of confusion is the fact or expectation that RA >> PIO often both sets A and L bits on. So, in the above example, if >> we have a PIO for 2001:db8:1::/48 or 2001:db8:1:2:3:4:5:0/120 with >> both L and A bits on, these are valid on link prefix. But they >> can't be used for SLAAC (assuming its link-layer spec specifies >> the consistent IID length with the "conservative" address >> architecture, i.e., 64). That is, for the same PIO, - if we >> consider it as on-link prefix, it can coexist with any of the >> address architecture - if we consider it for SLAAC, it can only >> coexist with the conservative architecture, or liberal one with an >> exception of requiring 64-bit subnet prefix length specifically >> for SLAAC >> >> BTW while writing this message I saw a warning from Brian: >> >>>> Isn't it time we all shut up and wait for the document editor >>>> to propose text? >> >> I don't want to contribute to making this thread even longer, so I >> promise I'll stop here. But I wanted to make this one remark >> since I believe it's important to clarify that ("on-link prefix" is >> irrelevant to the address architecture discussion) and I see why >> this can be so confusing. Even if this attempt of mine fails, >> I'll shut up now (maybe I should write a separate draft just >> focusing on this particular confusion). >> >> -- JINMEI, Tatuya >> >> -------------------------------------------------------------------- >> >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Mar 11 08:52:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6770129539 for ; Sat, 11 Mar 2017 08:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 D5vquZ11p0ul for ; Sat, 11 Mar 2017 08:52:05 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E55129534 for ; Sat, 11 Mar 2017 08:52:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v2BGq2rh030380 for ; Sat, 11 Mar 2017 17:52:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 82E8E207B98 for ; Sat, 11 Mar 2017 17:52:02 +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 78DFB2077FD for ; Sat, 11 Mar 2017 17:52:02 +0100 (CET) Received: from [132.166.84.23] ([132.166.84.23]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2BGq1M9014100 for ; Sat, 11 Mar 2017 17:52:01 +0100 Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis To: ipv6@ietf.org References: <0ED54B2A-AF35-4510-9F04-EA2E213634C4@google.com> <9f6ea52b7ac741ae9f95e9901d1a3bd1@XCH15-06-11.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <3154cb7c-cf10-2882-4abb-258819c00381@gmail.com> Date: Sat, 11 Mar 2017 17:51:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 16:52:06 -0000 Le 11/03/2017 à 13:17, Philip Homburg a écrit : >> If you want random, a PRNG can create any length of IID. A 48-bit >> IID would be just as reasonable, and it could be formed from a >> randomly changing link layer address. > > The way I see it is that for pseudo-random IIDs we should set the > minimum length such that statistically a collision between addresses > never happens. Obviously collossions will happend due to > implementation errors, but I think the abstract model should have an > extremely low chance of collossions, ever. > > It is easy enough to argue that 64 bits is enough. It is also easy > enough to argue that 32 bits is not enough. Would 48 bits work? > That's a matter of estimating how big the IPv6 network will grow. > > Another way of looking at this, why would we need IIDs that are less > than 64 bits? In order to run SLAAC on links on which a /63 is routed to. Alex > The current IPv6 address architecture has no problems supporting 64 > bit IIDs. There doesn't seem to be any technical reason to risk a > higher chance of collissions by lowering the number of bits. > > Instead, the argument used for those is that some operators did > something stupid and assign only a single /64 to a collection of > links. This, despite all efforts initially to make sure that /48s > were assigned. > > So it is reasonable to assume that if we would fully support /80 > prefixes in SLAAC, that some operators would again not > read/understand our address architecture and just assign a single /80 > and we a back to square one. > > So modifying hosts to generate IIDs smaller than 64 bits would have > benefits in the short run, but it the long run trades an increase in > risk of collission for no benefit at all. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Mar 13 03:04:28 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D698C129568; Mon, 13 Mar 2017 03:04:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-segment-routing-header-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148939945585.16850.1089102827781150521@ietfa.amsl.com> Date: Mon, 13 Mar 2017 03:04:15 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 10:04:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : IPv6 Segment Routing Header (SRH) Authors : Stefano Previdi Clarence Filsfils Kamran Raza John Leddy Brian Field Daniel Voyer Daniel Bernier Satoru Matsushima Ida Leung Jen Linkova Ebben Aries Tomoya Kosugi Eric Vyncke David Lebrun Dirk Steinberg Robert Raszuk Filename : draft-ietf-6man-segment-routing-header-06.txt Pages : 35 Date : 2017-03-13 Abstract: Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending an SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any path (topological, or application/service based) while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the IPv6 data plane with the addition of a new type of Routing Extension Header. This draft describes the Segment Routing Extension Header Type and how it is used by SR capable nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-segment-routing-header-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 nobody Mon Mar 13 11:24:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5941299F4 for ; Mon, 13 Mar 2017 11:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TSAVGvSxgxCu for ; Mon, 13 Mar 2017 11:24:21 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168AA129A00 for ; Mon, 13 Mar 2017 11:24:21 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id f84so88460392ioj.0 for ; Mon, 13 Mar 2017 11:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mWgZghy5IGUtb0VJEO2yA9f5xfETr4hMR26QNwwtfDc=; b=oncuSgJvfDNZ5n6M+z3hj1ZuPtUll8ewx6yYBQgRgZy1EeaUyy6gn7FDH7ixAVbBRH 6uRv53eGFz5yHfhCF6fJfQyYnA/uXtKYzLct5DgmFiGl8IFypT//j3SVGTdycl4s3k72 iNEngM88S8dGlf/QtMpLpMo2PTQCnZeSurLPHCCv7+NFFODQfeVzw1XWUVqGAKNN2xy6 XazxJp9cJb03gNN986F6VQUHRLCNfXkVSgDK1eoGcQ8qdybhGt6qeFz5nBF34sx5xJS/ oiFPLM2RcetC8nHeuZwpVTgtOyZ38ts/S6yIf9ZaevEZacIx5J2ldV/rsguXr30lIaL+ naIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mWgZghy5IGUtb0VJEO2yA9f5xfETr4hMR26QNwwtfDc=; b=HhrkBJl/d7DqPQZVpTae+n3l31nUAuPIh324iqQ4fcghbFCr6PucrzAXjkvmNWxkd7 Mg7rouRCz+RLuA6sWXtPaRItKeLhe9Bb/PH5Hh791cHpEJ143yrWRZe5T6KqfKRrMf6U DVIVIzyNCqjzSU6b15yViXjP23/QZUkztLXJnDrxY0/ojXm5FchO6dhnA+iHOxffxj73 my2NBdHv6xHP4Uq3DP7zbag2jUTXBH7BXQrtpGavglBxmlJS93upfo+U0x6SvFGQ9FzX W9G5iwJ3oclyxx8q9mG0w+2T3Ms906QEeWWPczL6Q3r5VXdgoxZJJqvJvURvU1empbLm 5Yaw== X-Gm-Message-State: AMke39k9bvTGdsjWLAB8ltzKCNA1OzQna5gPsMU/q48dH/NN8RJUMD9BMJRinK+0LT6zjA== X-Received: by 10.107.130.210 with SMTP id m79mr28076407ioi.38.1489429460424; Mon, 13 Mar 2017 11:24:20 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id f85sm8554400ioi.26.2017.03.13.11.24.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 11:24:19 -0700 (PDT) From: Bob Hinden Message-Id: <14356CE3-ABA1-4C04-9A29-4D121DA1D2C2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D48958D3-6733-4D9F-A211-19C03157CB1A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: I-D Action: draft-ietf-6man-segment-routing-header-06.txt Date: Mon, 13 Mar 2017 11:24:20 -0700 In-Reply-To: <148939945585.16850.1089102827781150521@ietfa.amsl.com> To: IPv6 List References: <148939945585.16850.1089102827781150521@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:24:28 -0000 --Apple-Mail=_D48958D3-6733-4D9F-A211-19C03157CB1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, This draft has quite a long author list. It grew significantly from the = previous version. The RFC Style Guide (RFC7322) recommends a limit of five authors. = Sixteen is a lot more than five. The style guide says that drafts with = more than five will require specific approval from the stream to have = this many authors, in this case the IESG. =46rom a practical point of = view having sixteen authors will make getting through AUTH48 very = challenging as each author needs to sign off on the document. I suggest that the authors figure out a way to reduce the number of = listed authors. For example, move most people to a "contributors" = section and leave the document editor or primary authors on the first = page. Thanks, Bob > On Mar 13, 2017, at 3:04 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance of the IETF. >=20 > Title : IPv6 Segment Routing Header (SRH) > Authors : Stefano Previdi > Clarence Filsfils > Kamran Raza > John Leddy > Brian Field > Daniel Voyer > Daniel Bernier > Satoru Matsushima > Ida Leung > Jen Linkova > Ebben Aries > Tomoya Kosugi > Eric Vyncke > David Lebrun > Dirk Steinberg > Robert Raszuk > Filename : draft-ietf-6man-segment-routing-header-06.txt > Pages : 35 > Date : 2017-03-13 >=20 > Abstract: > Segment Routing (SR) allows a node to steer a packet through a > controlled set of instructions, called segments, by prepending an SR > header to the packet. A segment can represent any instruction, > topological or service-based. SR allows to enforce a flow through > any path (topological, or application/service based) while > maintaining per-flow state only at the ingress node to the SR = domain. >=20 > Segment Routing can be applied to the IPv6 data plane with the > addition of a new type of Routing Extension Header. This draft > describes the Segment Routing Extension Header Type and how it is > used by SR capable nodes. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-segment-routing-header= -06 >=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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_D48958D3-6733-4D9F-A211-19C03157CB1A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYxuPVAAoJEK7rdBF357uoM5cH/2oEJoLFnvbGHcAWWRgIJYE7 +LxR/bfkDmoxB2ZTD2vxY8ETPuWYkVOvrdp7qA1QMRaj/vTii51zxW5Q+XaHgpwc WQbf3fldM2QFfWqXImVYSPWhzH/W1mYnlfKH97CmOpXmA4ZBjjoqe/CHTfNzTNuY 36Mkc0EfS0F1dsJYFeO50Qb9RIBDUYbKB9SU81EVi+H1BvZT1lwIT9roHDIdbULt RjmTwJmezqHu6PpXy82n8rOhXM58biNzTZEpOJAD01ouas+DzbGUHeAQUcAb5Idw KOHVy/WSreB4cVsRFiyZgLBwg+w/l8RqR+a1z/533XLgqK9J5zd/2tVyD8prEl4= =iygd -----END PGP SIGNATURE----- --Apple-Mail=_D48958D3-6733-4D9F-A211-19C03157CB1A-- From nobody Mon Mar 13 13:34:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05C2129B36 for ; Mon, 13 Mar 2017 13:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 hNfFkDY8Ep_W for ; Mon, 13 Mar 2017 13:33:56 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E091B129B33 for ; Mon, 13 Mar 2017 13:33:55 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id n21so41487457qta.1 for ; Mon, 13 Mar 2017 13:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+m9VF8+wkEtcjhnR8ZxSvwxrt/N/c5GKQdmexf/bXvQ=; b=Z37f7JahR0YnO7immo6mgp6EPy+hsqyhNGsLnPZhl9AarrJw23cmXTn8W9/85So0eO Q7gLemmRy3jnMssX0WaDYsLWKRCwPfH01qi+bd2btmKz9CIGuAU5N6jUgoxYmGPZSayV y+hGsyfe1fq8lhUN64euwjOZAlvSwKlrZM91c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+m9VF8+wkEtcjhnR8ZxSvwxrt/N/c5GKQdmexf/bXvQ=; b=KHSXZupq4xDCXBJalysczshbqiwKzTr6iqimQHO2/5XrnGDVF4TsxoxEjVrzN9Nxyh Dm0QewtXCRRj0RzXRWLOPXTSZFkG7zwLfRkIevfpZPTh2FGHcG5Pj+tOahA4yv6/pLIc L3hL2Tr5qCK1yrFdDuWLfBcwB+Cx0vgCnMmLmO3qsZM611bdfbJR6/m3vGCHyj92/aVG 0NO11qH7Q7PJNAoselAsUUqxx3uiCj5U6idOy3DUDiYsXKN1U6iNW6DCC6IYLjh94s2o hxC6OJxL+rnLYBdGUpJSyG2j8kEDghe5lVjCk02tlmc1jbKa6XAxlCQctoDCMYD/d72P zt+g== X-Gm-Message-State: AMke39nEMASCM9DEgPjbpiAPCMllsQ1wEkZMv6+KGTRAypBDzks/K6xn4ASiDgp2xmZTbLF92WDffqxQfoknnO0p X-Received: by 10.200.39.41 with SMTP id g38mr38161456qtg.45.1489437234264; Mon, 13 Mar 2017 13:33:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.225 with HTTP; Mon, 13 Mar 2017 13:33:53 -0700 (PDT) In-Reply-To: <148943650492.20338.10199609342471625076.idtracker@ietfa.amsl.com> References: <148943650492.20338.10199609342471625076.idtracker@ietfa.amsl.com> From: Timothy Winters Date: Mon, 13 Mar 2017 16:33:53 -0400 Message-ID: Subject: Fwd: New Version Notification for draft-clw-rfc6434-bis-01.txt To: 6man WG Content-Type: multipart/alternative; boundary=001a114032aa4452ea054aa2a1d5 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:34:02 -0000 --001a114032aa4452ea054aa2a1d5 Content-Type: text/plain; charset=UTF-8 Hi 6MAN, There is a new version of IPv6 Node Requirements available. This version includes RFC updates, removal of out of date RFCs, and requested changes from last time. There are still several areas where there needs to be more discussion which we plan on having in Chicago, but feel free to send comments. ~Tim ---------- Forwarded message ---------- From: Date: Mon, Mar 13, 2017 at 4:21 PM Subject: New Version Notification for draft-clw-rfc6434-bis-01.txt To: Tim Chown , Timothy Winters , John Loughney A new version of I-D, draft-clw-rfc6434-bis-01.txt has been successfully submitted by Tim Winters and posted to the IETF repository. Name: draft-clw-rfc6434-bis Revision: 01 Title: IPv6 Node Requirements Document date: 2017-03-13 Group: Individual Submission Pages: 34 URL: https://www.ietf.org/internet-drafts/draft-clw-rfc6434-bis-0 1.txt Status: https://datatracker.ietf.org/doc/draft-clw-rfc6434-bis/ Htmlized: https://tools.ietf.org/html/draft-clw-rfc6434-bis-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-clw-rfc6434-bis-01 Abstract: This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294. 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 -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a114032aa4452ea054aa2a1d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi 6MAN,

    There is a new version of IPv6= Node Requirements available.=C2=A0 This version includes RFC updates, remo= val of out of date RFCs, and requested changes from last time.=C2=A0=C2=A0<= /div>

    There are still several areas where there needs to= be more discussion which we plan on having in Chicago, but feel free to se= nd comments.

    ~Tim=C2=A0
    ---------- Forwarded message ----------
    From: <internet-drafts@ietf.org>
    Date:= Mon, Mar 13, 2017 at 4:21 PM
    Subject: New Version Notification for draf= t-clw-rfc6434-bis-01.txt
    To: Tim Chown <tim.chown@jisc.ac.uk>, Timothy Winters = <twinters@iol.= unh.edu>, John Loughney <john.loughney@nokia.com>



    A new version of I-D, draft-clw-rfc6434-bis-01.txt
    has been successfully submitted by Tim Winters and posted to the
    IETF repository.

    Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-clw-rfc6434-bis
    Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
    Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 Node Requirements
    Document date:=C2=A0 2017-03-13
    Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 34
    URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-clw-rfc6434-bis= -01.txt
    Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-clw-rfc6434-bis/
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-clw-rfc6434-bis-01
    Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-clw-rfc6434-bis-01=

    Abstract:
    =C2=A0 =C2=A0This document defines requirements for IPv6 nodes.=C2=A0 It is= expected
    =C2=A0 =C2=A0that IPv6 will be deployed in a wide range of devices and situ= ations.
    =C2=A0 =C2=A0Specifying the requirements for IPv6 nodes allows IPv6 to func= tion
    =C2=A0 =C2=A0well and interoperate in a large number of situations and
    =C2=A0 =C2=A0deployments.

    =C2=A0 =C2=A0This document obsoletes RFC 6434, and in turn RFC 4294.




    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




    --

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --001a114032aa4452ea054aa2a1d5-- From nobody Mon Mar 13 16:14:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F838129562 for ; Mon, 13 Mar 2017 16:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bb5HEZRLKErZ for ; Mon, 13 Mar 2017 16:14:38 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AF912945F for ; Mon, 13 Mar 2017 16:14:38 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id y76so235633326qkb.0 for ; Mon, 13 Mar 2017 16:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=kPwDCspX+dvPY1YLI91CWG7JR9QS+M7ldv/iHUgBaO0=; b=fOAL40hUX43bvfbyFkqhoYYheroLuYm7TOQ9i3kWLwNpMAmlhhEEX4KvJZQpDgKr4d bly9n5FtznX2ZxrdZfOC/M4EawoAGIGs/m3G8Qkhl8Zw7UzGxALpJbTjQhBayrrlmrW9 DBityQNkv5kErYQPR4SX/chTw+kRYiSvgR0g1Dwen2SvVXUk0CnhliQ+SXnMGw/Jb0oL sZVMMFGJygFRSKgGZkszcuknCWyGogSHTwiWWXem6XyUsuTXuYBg7txRGtMu0owsQgqS kcgz7Xq5PBANunxDqAmcllF8I0YRESySL9rB/IY/e3MOIaVVUkmLwt16nlFekKWIGxbn 21Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=kPwDCspX+dvPY1YLI91CWG7JR9QS+M7ldv/iHUgBaO0=; b=VheKXy9Av8IA9+ISTi/JKdXldJX++CnB4NapTFYKPeE/Yfvtp97BDRkfFboBgBz74T a2mscF6hUjpH1mO09O/0jCJ3fpw+2T99AhAJESM1icJkhe0M/61Af0so7d3XhazmHPLg 7SzdlczyVmZK4nS9VRrkES3TBKTt0KYar+uk6DRIygQ1Aj5vaPA5ScUueUCC1uEEWseA gIuGOR/uMXAaPe4p2gf7i6sN/fA9t9LlouG2cnddQYsQUGRAEbHQ3jtcOni2TtrdTUV6 ysvCYoxejWCcH9wvAwD8SvQaP8idJI1oHWfxDXWbETxwHiRlS2E/IfMeJsXXZhCXA7DJ iVfw== X-Gm-Message-State: AFeK/H1XXepQ4Hz79yHjSYwsoKN9SlUK+WaOd9QwDL+D7yqcXHhfoLcf42W6c+L7fWBIj8ZF8OQ5dawh+zaYwA== X-Received: by 10.55.123.129 with SMTP id w123mr33073042qkc.20.1489446876976; Mon, 13 Mar 2017 16:14:36 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Mon, 13 Mar 2017 16:14:36 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 13 Mar 2017 16:14:36 -0700 X-Google-Sender-Auth: oBaGiaSE3jlnCh9TDBiPmCUvDbc Message-ID: Subject: a draft about on-link and submit prefixes To: IPv6 IPv6 List Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:14:39 -0000 I've submitted a new individual draft on the separation between on-link and (SLAAC) subnet prefixes, at the risk of stating the obvious: https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix-clarify/ In fact, it was actually too obvious to myself until a few weeks ago, but I realized it might not be as obvious as I originally thought through recent discussions on the wg list. So I thought it may still be worth clarifying explicitly. At least I can just refer to it next time this topic is brought up, instead of explaining it from the scratch again. Hopefully it's useful for some others, too. -- JINMEI, Tatuya From nobody Mon Mar 13 19:40:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7EA12995B; Mon, 13 Mar 2017 19:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KXGFF9Y9qxHd; Mon, 13 Mar 2017 19:40:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD93129420; Mon, 13 Mar 2017 19:40:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCS97373; Tue, 14 Mar 2017 02:40:53 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 14 Mar 2017 02:40:52 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.160]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 14 Mar 2017 10:40:46 +0800 From: Xuxiaohu To: "ipv6@ietf.org" , "spring@ietf.org" Subject: =?utf-8?B?RllJLy/ovazlj5E6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh?= =?utf-8?B?ZnQteHUtbXBscy11bmlmaWVkLXNvdXJjZS1yb3V0aW5nLWluc3RydWN0aW9u?= =?utf-8?Q?-00.txt?= Thread-Topic: =?utf-8?B?RllJLy/ovazlj5E6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh?= =?utf-8?B?ZnQteHUtbXBscy11bmlmaWVkLXNvdXJjZS1yb3V0aW5nLWluc3RydWN0aW9u?= =?utf-8?Q?-00.txt?= Thread-Index: AQHSnGxh0kYjoygqbEmYKgX5zKaIDQ== Date: Tue, 14 Mar 2017 02:40:46 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB640B6@NKGEML515-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.58C75835.00E7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a010e9b3e49db541e74c6ea361336792 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 02:40:58 -0000 VGhpcyBkcmFmdCBtYXkgYmUgaW50ZXJlc3RpbmcgdG8gZm9sa3MgaW52b2x2ZWQgaW4gNm1hbiBh bmQgU1BSSU5HIFdHIGFzIHdlbGwuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnXSDku6PooaggWHV4aWFvaHUNCj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0M+aciDE0 5pelIDEwOjMxDQo+IOaUtuS7tuS6ujogbXBsc0BpZXRmLm9yZw0KPiDkuLvpopg6IFttcGxzXSDo vazlj5E6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQteHUtbXBscy11bmlm aWVkLXNvdXJjZS1yb3V0aW5nLWluc3RydWN0aW9uLTAwLnR4dA0KPiANCj4gSGkgYWxsLA0KPiAN Cj4gQW55IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCj4gDQo+IEJlc3Qg cmVnYXJkcywNCj4gWGlhb2h1DQo+IA0KPiA+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPiDl j5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4gPiDlj5HpgIHml7bpl7Q6IDIwMTflubQz5pyIMTPml6UgMTE6MDANCj4g PiDmlLbku7bkuro6IEhhbWlkIEFzc2FycG91cjsgTHVpcyBNLiBDb250cmVyYXM7IFJvYmVydCBS YXN6dWs7IFh1eGlhb2h1Ow0KPiA+IFN0ZXdhcnQgQnJ5YW50OyBMdWF5IEphbGlsOyBVbWEgQ2h1 bmR1cmk7IEx1aXMgQ29udHJlcmFzDQo+ID4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQo+ID4gZHJhZnQteHUtbXBscy11bmlmaWVkLXNvdXJjZS1yb3V0aW5nLWluc3RydWN0 aW9uLTAwLnR4dA0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwNCj4gPiBkcmFm dC14dS1tcGxzLXVuaWZpZWQtc291cmNlLXJvdXRpbmctaW5zdHJ1Y3Rpb24tMDAudHh0DQo+ID4g aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYaWFvaHUgWHUgYW5kIHBvc3RlZCB0 byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gTmFtZToJCWRyYWZ0LXh1LW1wbHMt dW5pZmllZC1zb3VyY2Utcm91dGluZy1pbnN0cnVjdGlvbg0KPiA+IFJldmlzaW9uOgkwMA0KPiA+ IFRpdGxlOgkJVW5pZmllZCBTb3VyY2UgUm91dGluZyBJbnN0cnVjdGlvbiB1c2luZyBNUExTIExh YmVsIFN0YWNrDQo+ID4gRG9jdW1lbnQgZGF0ZToJMjAxNy0wMy0wOQ0KPiA+IEdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gUGFnZXM6CQkxMA0KPiA+IFVSTDoNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtbXBscy11bmlmaWVkLXNvdXJj ZS1yb3V0DQo+ID4gaW5nLWluc3RydQ0KPiA+IGN0aW9uLTAwLnR4dA0KPiA+IFN0YXR1czoNCj4g PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1tcGxzLXVuaWZpZWQt c291cmNlLXJvdXRpbmctDQo+ID4gaW5zdHJ1Y3Rpb24NCj4gPiAvDQo+ID4gSHRtbGl6ZWQ6DQo+ ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LW1wbHMtdW5pZmllZC1zb3Vy Y2Utcm91dGluZy1pbnN0cg0KPiA+IHVjdGlvbi0wMA0KPiA+DQo+ID4NCj4gPiBBYnN0cmFjdDoN Cj4gPiAgICBNUExTLVNQUklORyBpcyBhbiBNUExTLWJhc2VkIHNvdXJjZSByb3V0aW5nIHBhcmFk aWdtIGluIHdoaWNoIGENCj4gPiAgICBzZW5kZXIgb2YgYSBwYWNrZXQgaXMgYWxsb3dlZCB0byBw YXJ0aWFsbHkgb3IgY29tcGxldGVseSBzcGVjaWZ5IHRoZQ0KPiA+ICAgIHJvdXRlIHRoZSBwYWNr ZXQgdGFrZXMgdGhyb3VnaCB0aGUgbmV0d29yayBieSBpbXBvc2luZyBzdGFja2VkIE1QTFMNCj4g PiAgICBsYWJlbHMgdG8gdGhlIHBhY2tldC4gIFRoaXMgTVBMUyAtYmFzZWQgc291cmNlIHJvdXRp bmcgcGFyYWRpZ20gY291bGQNCj4gPiAgICBhY3R1YWxseSBiZSBsZXZlcmFnZWQgdG8gcmVhbGl6 ZSBhIHVuaWZpZWQgc291cmNlIHJvdXRpbmcgaW5zdHJ1Y3Rpb24NCj4gPiAgICBmb3IgYm90aCBJ UHY0IGFuZCBJUHY2IHVuZGVybGF5cy4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m DQo+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+DQo+ID4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From nobody Mon Mar 13 21:07:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44362129C46 for ; Mon, 13 Mar 2017 21:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 3iV5GZldIi1I for ; Mon, 13 Mar 2017 21:07:11 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCABC129C43 for ; Mon, 13 Mar 2017 21:07:11 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id q7so147531098uaf.2 for ; Mon, 13 Mar 2017 21:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pMYHbHtAZ8pVnmfgSioTLUnLmBMi6wQcHKSlabkpxaw=; b=JNGnKJAi/9egd1x+4U6X6A8JH85svdoY85d9B7jFbR+iMtCFvR1PVQInT0fZk4qHvl /7a2BkMknehH4n6r+Q33OPVi3sXSvqERbgoZJUMjxle7Q+uFJ3MrXK9ClJ5k8LtpCbtE SPgT9rHrmoycGMiz2+sjGufTwnUL/T08YSXrCWo3eIikcgYt8QR1jtoJynxRCEDe5dYX ITXHV5LTjipNnQ6dFkPqWvAEn8qrdLwnaU79NQZ+A3iH/1wlGiThmgdePS8uynqlIc96 3/IAAimNqSAM/LNQS1IS8ajG7c1QukKWq/aM1cNjC6oZtHTz64mhIsf8sq0uzTE5VWOE yIYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pMYHbHtAZ8pVnmfgSioTLUnLmBMi6wQcHKSlabkpxaw=; b=ZuTPQ5VZhUkmPL1/q10NHWV5qPPu28zDfM8xo99dpPCotoiUJ/THdAqu0oIXJRsDj2 UFmnd2/WOJzIEyhkyFjHjLNH5bmuJCXJZhmPPd986wixEWnVb10Zw9mDAclHcx10ADyH LVI2wND2lmtkGG6nYJFHHkm24EXAJ2DEVGrAO/cL12iKsy9k6gVwKf0R9qxDAfhggAAO DTVeYSviUuQOpAxvZSMC5obQ0OZAjyOKe+NBK1iCHu9chYOomOdhGKWtSTaMNLx6CfaJ xHgQWVKTHAl+Y/dqWasy5A+4TNXlo9+yJXSIBQ9AgB8oAkn6Z5BfCG03/ci0Kfne+jsl d6bQ== X-Gm-Message-State: AMke39lwOImitNqmN8jr8pFvq8BTFCKei7LD+s5jZ+Ecqx/AHwKbfLqcXO3oEhD5MOGZqmp0ocoILOoy2p90Dbh3 X-Received: by 10.159.36.10 with SMTP id 10mr18430925uaq.124.1489464430559; Mon, 13 Mar 2017 21:07:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 13 Mar 2017 21:06:50 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 14 Mar 2017 13:06:50 +0900 Message-ID: Subject: Re: a draft about on-link and submit prefixes To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=001a113df6844a5609054aa8f682 Archived-At: Cc: IPv6 IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 04:07:13 -0000 --001a113df6844a5609054aa8f682 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 14, 2017 at 8:14 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > I've submitted a new individual draft on the separation between > on-link and (SLAAC) subnet prefixes, at the risk of stating the > obvious: https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix- > clarify/ Thanks for attempting to clarify the topic. I think it is useful to do so, since the distinctions here are very subtle and even many in the WG (not to mention in the IETF or in the industry) are not fully aware of their implications. If possible, I would suggest making this document even more general. It's mostly geared to how implementations treat PIOs, and refers to RFC 4861 and RFC 4862, but really I think the clarifications it makes have much broader impact. As I see it, the core issues here are: - IPv6 addresses don't specify any on-link information - For most (but not all) unicast addresses, subnet prefixes are 64 bits per RFC 4291. - A given subnet prefix can be spread across multiple links, and a given link can support multiple subnet prefixes. This is not immediately obvious to people who are familiar with the IPv4 subnet model, because it is quite different. For example, it is an entirely valid configuration for an RA to contain a PIO for 2001:db8::/64 A=3D1 L=3D0 and a PIO for 2001:db8::/96 A=3D0 L=3D1. = In this case, the host can form an address via SLAAC that *is not on link*. This is a a perfectly supported configuration that has no equivalent in IPv4. In IPv4 the subnet prefix and the onlink prefix have to match because things wouldn't work otherwise (e.g., the broadcast address would not be on link any more). A corollary to the above is that subnet prefixes don't specify any on-link information. The fact that the subnet prefix is "almost always" 64 bits long doesn't mean that the on-link prefix cannot be /48, /89 or /120. The fact that the on-link prefix is /120 doesn't mean that nodes on that link have to have addresses in that /120. --001a113df6844a5609054aa8f682 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= ue, Mar 14, 2017 at 8:14 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@= wide.ad.jp> wrote:
    I've submitted a new individual draft on the separation betw= een
    on-link and (SLAAC) subnet prefixes, at the risk of stating the
    obvious: https://datatracker.ietf.= org/doc/draft-jinmei-6man-prefix-clarify/
    Thanks for attempting to clarify the topic. I think it is usef= ul to do so, since the distinctions here are very subtle and even many in t= he WG (not to mention in the IETF or in the industry) are not fully aware o= f their implications.

    If possible, I would suggest= making this document even more general. It's mostly geared to how impl= ementations treat PIOs, and refers to RFC 4861 and RFC 4862, but really I t= hink the clarifications it makes have much broader impact. As I see it, the= core issues here are:
    • IPv6 addresses don't specify a= ny on-link information
    • For most (but not all) unicast addresses, su= bnet prefixes are 64 bits per RFC 4291.
    • A given subnet prefix can b= e spread across multiple links, and a given link can support multiple subne= t prefixes.
    This is not immediately obvious to people who are= familiar with the IPv4 subnet model, because it is quite different.

    For example, it is an entirely valid configuration f= or an RA to contain a PIO for 2001:db8::/64 A=3D1 L=3D0 and a PIO for=C2=A0= 2001:db8::/96 A=3D0 L=3D1. In this case, the host can form an address via S= LAAC that *is not on link*. This is a a perfectly supported configuration t= hat has no equivalent in IPv4. In IPv4 the subnet prefix and the onlink pre= fix have to match because things wouldn't work otherwise (e.g., the bro= adcast address would not be on link any more).

    A corollary to the above is that subnet prefixes don't specify any o= n-link information. The fact that the subnet prefix is "almost always&= quot; 64 bits long doesn't mean that the on-link prefix cannot be /48, = /89 or /120. The fact that the on-link prefix is /120 doesn't mean that= nodes on that link have to have addresses in that /120.
    <= /div> --001a113df6844a5609054aa8f682-- From nobody Tue Mar 14 00:07:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272DE1289B0 for ; Tue, 14 Mar 2017 00:07:44 -0700 (PDT) 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 autolearn_force=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 nkUeVDjKEmyp for ; Tue, 14 Mar 2017 00:07:42 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id E6037126CD8 for ; Tue, 14 Mar 2017 00:07:41 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 17D43E6065; Tue, 14 Mar 2017 08:07:40 +0100 (CET) Date: Tue, 14 Mar 2017 08:07:39 +0100 (CET) Message-Id: <20170314.080739.74664517.sthaug@nethelp.no> To: lorenzo@google.com Subject: Re: a draft about on-link and submit prefixes From: sthaug@nethelp.no In-Reply-To: References: 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 Archived-At: Cc: ipv6@ietf.org, jinmei@wide.ad.jp X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 07:07:44 -0000 > If possible, I would suggest making this document even more general. It's > mostly geared to how implementations treat PIOs, and refers to RFC 4861 and > RFC 4862, but really I think the clarifications it makes have much broader > impact. As I see it, the core issues here are: > > - IPv6 addresses don't specify any on-link information > - For most (but not all) unicast addresses, subnet prefixes are 64 bits > per RFC 4291. > - A given subnet prefix can be spread across multiple links, and a given > link can support multiple subnet prefixes. > > This is not immediately obvious to people who are familiar with the IPv4 > subnet model, because it is quite different. I agree that a generalization is a good idea. In particular, it would be good to have (in one place) a definition of what an IPv6 subnet is, especially if a subnet can be spread across multiple links (which is *not* obvious to me from reading RFC 4861 and RFC 4862). Steinar Haug, AS2116 From nobody Tue Mar 14 01:04:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DA11294FB for ; Tue, 14 Mar 2017 01:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 oT4Azh-KLAVX for ; Tue, 14 Mar 2017 01:04:37 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id AEA2E1294E0 for ; Tue, 14 Mar 2017 01:04:37 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 14 Mar 2017 08:04:37 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 0CFC6D788A; Tue, 14 Mar 2017 01:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=xoMlrDAM7mOCZuQgPMAFyKQYEg8=; b= o3Mry0kCk00UZ1qHGOTtOFWG7IuodmsP2eADEtPtlzwJZWjWXaquJ9Y58YYm2NHy eMsm6sfUyph0agrm4IrhBqqSBK4DvxUxIqkegYcZgVG/F4AhlJjz3jFsBj7Nsx+A UOo5rTKqzbiyce7kcd4qBoydow2bJaKDTh8Rfhyu02M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=jPn8i9fUX2Tz2FP7HSzdFqn gs5Rpwbtv4bz2dajp62ZziF3dEkL9ZCd4CeGugWIMcSoo7F2J3GjuV8aEGf1NMni tfNn0IFteW6QoL0Tlz2hgmmQ5m5Dvf0NuQMPdo5JJkc/FSW+QrQ8vEx09i4SBCO6 uW4REV+PBqpsHGl50Ufs= Received: from h.hanazo.no (unknown [173.38.220.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id C971CD788B; Tue, 14 Mar 2017 01:04:36 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6B1309D409E5; Tue, 14 Mar 2017 09:04:34 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2DF3A3B2-9046-4847-8E8D-E76751B939CF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: a draft about on-link and submit prefixes Date: Tue, 14 Mar 2017 09:04:33 +0100 In-Reply-To: <20170314.080739.74664517.sthaug@nethelp.no> To: sthaug@nethelp.no References: <20170314.080739.74664517.sthaug@nethelp.no> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , jinmei@wide.ad.jp X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 08:04:39 -0000 --Apple-Mail=_2DF3A3B2-9046-4847-8E8D-E76751B939CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>=20 >> If possible, I would suggest making this document even more general. = It's >> mostly geared to how implementations treat PIOs, and refers to RFC = 4861 and >> RFC 4862, but really I think the clarifications it makes have much = broader >> impact. As I see it, the core issues here are: >>=20 >> - IPv6 addresses don't specify any on-link information >> - For most (but not all) unicast addresses, subnet prefixes are 64 = bits >> per RFC 4291. >> - A given subnet prefix can be spread across multiple links, and a = given >> link can support multiple subnet prefixes. >>=20 >> This is not immediately obvious to people who are familiar with the = IPv4 >> subnet model, because it is quite different. >=20 > I agree that a generalization is a good idea. In particular, it would > be good to have (in one place) a definition of what an IPv6 subnet is, > especially if a subnet can be spread across multiple links (which is > *not* obvious to me from reading RFC 4861 and RFC 4862). Indeed. I think we can generalize that statement and say it is not = obvious in general. There were proposals around multi-link subnets: https://tools.ietf.org/html/draft-thaler-ipngwg-multilink-subnets-02 Which pretty quickly decayed into implementing a spanning tree in ND and = flooding DAD messages. The remnants of that you can find in proxy RA and DAD proxy work. I would suggest that redefining existing terms to be able to shoe-horn = in a 64 bit boundary isn't helpful. Best regards, Ole --Apple-Mail=_2DF3A3B2-9046-4847-8E8D-E76751B939CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYx6QSAAoJEL7aWKiYQt92BdcQAMp6icndxl/dXpBgMb4tG8Gr oKJwMIHtSzbVXK6BYZDSvUP/qJgQVXa0NkVOKutyOcBlFOutKvX6+h2Y5/28TVPj wzrqs12Eia5EIs59JqY9xtKI0LHAAsERucXd3mv7LWs9DxR6ACDQ+GVH4Cttnl7g vXRR2RuGHV0l62KJgrPcKggLc0Z1RR8DAtkCiIULfexm6C1E/qy3qj29tKNoHgwf RdWZYRXY3QJb5/NZrO4eqILHrNh249XKBqb5aP08tfBoH9MXKCMQThJ5o9NOclc7 J4SBlhFcDZfO0I2uYPRRXEuV7vicj5IEeA/AvYkui1VC0+X+/grrC0rIAaKa/8HO GaMFujTY8u93vxqAYVC/R8AiEQapjOqyxWIjg5AjFKvozC8TbVBjOJuoE+PM9eEs siCEYoFuYCF2+jrc/qgOQQ3qWxD3w4N6zrlM9yUCjRPvIJZZD7cq+AKL53zHHJXA tKg4bKL/OL5aVP4G6vjpdEK7W2Ur1+NgTTGhQBlLSNnvHS1y6aAa4aTo06mEIzss d0prPm8r+6yvnYKjM9IDnSWdBNswfrdCmYnF43AdXGUoj5zFXdMFywGqDD1HErdu 5qbBW+Gq2Z6YQWNdMm35y5Jc+wdiRohFe5cmMCExON0xCncD4cqiyxwtzpdsCo2+ E5C5w1W22o3SVVU8FBYt =KEum -----END PGP SIGNATURE----- --Apple-Mail=_2DF3A3B2-9046-4847-8E8D-E76751B939CF-- From nobody Tue Mar 14 01:14:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93045129525 for ; Tue, 14 Mar 2017 01:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lWhoqRymGrGj for ; Tue, 14 Mar 2017 01:14:38 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD858129524 for ; Tue, 14 Mar 2017 01:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4111; q=dns/txt; s=iport; t=1489479277; x=1490688877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=awvbYm+hyg1b01dVMVKjtjQEEcaFAnsPYhDodKbIqAc=; b=nKaAZJdSYT3McyOTa00OxTHhG+Wi1k3bILezftRz6oRNVn6WDHa1ECy3 pMRhQ5f/7ukf6VZVcwtCy/d9oFoDGh1t0fXZw3Xkq3m16G/B5SLtNXTcU CtxbOZIlUOqLBTwRp24AtIZIzoznyVkUBC/m5C5uZdPJJW7TlDGsJoima M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQB6pcdY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHjWaRUYgPjS2CDh8NhXYCgmQ/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEBATg0CwULAgEIGB4QIQYLJQIEDgWJaAMNCA6vaYc4DYMcAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYZOggWCaoJRRoEaI4M0gjEFiRuSbDoBhnWHF4QsgXt?= =?us-ascii?q?UhFGKBYpViG8BHziBBFgVGCkRAYZFdYcmgS+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,162,1486425600"; d="scan'208";a="397763411" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 08:14:36 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2E8EaWN019256 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 08:14:36 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Mar 2017 04:14:35 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 14 Mar 2017 04:14:36 -0400 From: "Stefano Previdi (sprevidi)" To: Bob Hinden Subject: Re: I-D Action: draft-ietf-6man-segment-routing-header-06.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-06.txt Thread-Index: AQHSnJsEEGjIH2sq/k6DMPoaXWEYWA== Date: Tue, 14 Mar 2017 08:14:35 +0000 Message-ID: <7065669D-B5FB-4FE2-A99B-653D100D63A3@cisco.com> References: <148939945585.16850.1089102827781150521@ietfa.amsl.com> <14356CE3-ABA1-4C04-9A29-4D121DA1D2C2@gmail.com> In-Reply-To: <14356CE3-ABA1-4C04-9A29-4D121DA1D2C2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.85.200] Content-Type: text/plain; charset="us-ascii" Content-ID: <5F64070A12E2AA49BBE8F961CD36BD47@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 08:14:39 -0000 Hi Bob, Before bringing the draft to iesg review, we will trim down the authors lis= t to 5 names and move everybody else into the contributors section. s. > On Mar 13, 2017, at 7:24 PM, Bob Hinden wrote: >=20 > Hi, >=20 > This draft has quite a long author list. It grew significantly from the = previous version. >=20 > The RFC Style Guide (RFC7322) recommends a limit of five authors. Sixtee= n is a lot more than five. The style guide says that drafts with more than= five will require specific approval from the stream to have this many auth= ors, in this case the IESG. From a practical point of view having sixteen = authors will make getting through AUTH48 very challenging as each author ne= eds to sign off on the document. >=20 > I suggest that the authors figure out a way to reduce the number of liste= d authors. For example, move most people to a "contributors" section and l= eave the document editor or primary authors on the first page. >=20 > Thanks, > Bob >=20 >=20 >=20 >> On Mar 13, 2017, at 3:04 AM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the IPv6 Maintenance of the IETF. >>=20 >> Title : IPv6 Segment Routing Header (SRH) >> Authors : Stefano Previdi >> Clarence Filsfils >> Kamran Raza >> John Leddy >> Brian Field >> Daniel Voyer >> Daniel Bernier >> Satoru Matsushima >> Ida Leung >> Jen Linkova >> Ebben Aries >> Tomoya Kosugi >> Eric Vyncke >> David Lebrun >> Dirk Steinberg >> Robert Raszuk >> Filename : draft-ietf-6man-segment-routing-header-06.txt >> Pages : 35 >> Date : 2017-03-13 >>=20 >> Abstract: >> Segment Routing (SR) allows a node to steer a packet through a >> controlled set of instructions, called segments, by prepending an SR >> header to the packet. A segment can represent any instruction, >> topological or service-based. SR allows to enforce a flow through >> any path (topological, or application/service based) while >> maintaining per-flow state only at the ingress node to the SR domain. >>=20 >> Segment Routing can be applied to the IPv6 data plane with the >> addition of a new type of Routing Extension Header. This draft >> describes the Segment Routing Extension Header Type and how it is >> used by SR capable nodes. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-segment-routing-head= er-06 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> 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 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Mar 14 01:48:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB463129441 for ; Tue, 14 Mar 2017 01:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 OHoemtvUr3aj for ; Tue, 14 Mar 2017 01:47:58 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E0B126CD8 for ; Tue, 14 Mar 2017 01:47:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2E8luDJ027875 for ; Tue, 14 Mar 2017 09:47:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7C857205ABF for ; Tue, 14 Mar 2017 09:47:56 +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 728A2205A6A for ; Tue, 14 Mar 2017 09:47:56 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2E8lulp001214 for ; Tue, 14 Mar 2017 09:47:56 +0100 Subject: Re: a draft about on-link and subnet prefixes To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> Date: Tue, 14 Mar 2017 09:47:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 08:48:01 -0000 I suggest adding the following upfront: "The onlink|SLAAC dichotomy MAY be applied; if it is applied, then the routing towards that subnet MUST use the shortest plen of the two" E.g. if the on-link prefix is 48 and the SLAAC prefix is 64 then the 48 (not the 64) must be in the rt tables of routers with routes towards that subnet. Le 14/03/2017 à 00:14, 神明é”哉 a écrit : > I've submitted a new individual draft on the separation between > on-link and (SLAAC) subnet prefixes, at the risk of stating the > obvious: > https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix-clarify/ I have read the draft. It was a good read, thank you. It clarifies the difference between on-link prefixes and SLAAC prefixes. Here are my comments in summary: 1. It does not resolve the question of whether or not the 64bit IID should be required in the IPv6 Addressing Architecture. We can't require all IIDs be 64bit (for SLAAC) and rely on non-64 on-link prefixes at times. There is no recommendation about how to make that work, and intuitively it is prone to error. An example is needed picturing how the dichotomy can work. 2. The explanation of the dichotomy onlink|SLAAC should be accompanied by a recommendation of using the shortest plen of the two (even when that plen is not 64) in the Internet routing setup towards that subnet. This is the crux of it. This recommendation should acknowledge that when that plen is larger than 64, SLAAC/Ethernet can not work. This recommendation should acknowledge that when that plen is smaller than 64, SLAAC/Ethernet can work by using 64 for SLAAC and plen for on-link determination. 3. The draft would benefit from dealing with LL addresses too. Details below: > Although this misunderstanding would normally not cause troubles in > practical deployments, it can be a source of operational surprise or > interoperability problems once an administrator wants to exploit the > idea of this separation more "creatively". This needs the administrator to have ability to set distinct routes towards presumably distinct 'on-link' and SLAAC prefixes. > For brevity, this document focuses on global unicast prefixes. > Discussions on any other types of prefixes, including unicast link- > local prefixes, are out of scope of this document. If one tries to bring the LL prefixes in the picture then the perspective may change. Let me explain why: The LL prefix is not present in RA, there is no 'L' nor 'A' bits to check, yet LL is "on-link" prefix and it is used to auto-configure an Address. So, your definition of an "on-link" prefix being "A prefix advertised in an RA PIO with the L flag being set." is incomplete. The right definition of an "on-link" prefix should be: > A prefix advertised in an RA PIO with the L flag being set, or a > prefix starting with fe81:://10. and, similarly: > SLAAC subnet prefix - A prefix advertised in an RA PIO with the A > flag being set, or a prefix starting with fe82:://10. Further, when the draft says: > It may also be worth noting that an SLAAC subnet prefix is not > directly related to the "subnet prefix" it is wrong. It should say: > It may also be worth noting that, with the exception of LL prefix, an > SLAAC subnet prefix is not directly related to the "subnet prefix" > (i.e. an LL prefix _is_ directly related to the "subnet prefix"). That goes for many other such statements. Each should be qualified by LL. And if we do so, then this dichotomy may appear less obvious. There is always this LL exception. > [RFC4861] and [RFC4862] intentionally separate the concept and > handling of on-link prefixes and SLAAC subnet prefixes, even when > they are specified in the same single PIO. I agree with this dichotomy. It is a tool that can be used to do sophisticated configs in an IPv6 subnet. Similar configs can be achieved in IPv4 as well. (there is equivalency between 1:1::/63 "connected" in rt and 1:1::1/64 on the iface, and 1.1.0.0/23 "connected" in rt and 1.1.0.1/24 on the iface) However, this dichotomy has very many consequences. A number of RFCs and I-Ds misunderstand this dichotomy "on-link"|"SLLAC" and make wrong recommendations. Maybe you want this draft to clarify all these RFCs? One of the worst consequence is the allocation of single /64 prefix for an end user. Many drafts and their respective deployments only give a /64 to the end user: it is used both for SLAAC _and_ for on-link determination. If they agreed the dichotomy then they would give at least two distinct prefixes to the end-user: one for SLAAC and one for on-link determination. Another consequence is the possibility to make wrong configurations. A wrong configuration is the following: in a subnet where plen1 is for on-link determination and plen2 is for SLAAC, it is easily possible to make a Host believe a Neighbor is on-link whereas the routing system to which that subnet is connected routes to another subnet for same Neighbor. If somebody plays too much with this plen1 and plen2 configurations (onlink|SLAAC) on a subnet one can easily make mistakes. There is no recommendation how to avoid these mistakes. Recommendations about how to play with this onlink|SLAAC dichotomy will need to take into account how routing is based on longest-prefix match. Also these recommendations must make sure that allocating a single /64 to an end user does not get into widespread use. > Perhaps the administrator of the link wanted to force most of on-link > communication to 2001:db8:1:2::/64 to be first sent to a default > router, while allowing a particular set of hosts (those using the > address that match the on-link prefix) to communicate directly. I agree with the use-case. But maybe the administrator should know too that the default router will reply back with an ICMP Redirect leading to an end result where the on-link prefix is same as the SLAAC prefix in the rt table. Also, the administrator should know that same effect (force traffic to the defrouter, instead of directly to neighbors) is achieved by using ptp links. This also avoids ICMP Redirect, and thus permanently maintain this "through-defrouter" path, instead of momentarily. > An on-link prefix could be longer than an SLAAC subnet prefix. For > example, when the latter is 2001:db8:1:2::/64, the former could be > 2001:db8:1:2:3:4::/80. I agree it could be. But in this case, one also must make sure the routing towards that subnet is the SLAAC's /64 (not the 'onlink's /80). > An on-link prefix could also be shorter than an SLAAC subnet prefix. > For example, when the latter is 2001:db8:1:2::/64, the former could > be 2001:db8:1::/48. I agree it could be. In this case, one also must make sure the routing towards that subnet is the onlink's /48, and not the SLAAC's /64. Lacking of saying so leads to the undesirable situation of operators allocating a /64 for a ptp link. To combine the two, a recommendation would be: "The onlink|SLAAC dichotomy may be applied only if the routing towards that subnet uses the shortest plen of the two; that could be a value less than 64." Alex From nobody Tue Mar 14 02:30:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F5F129529 for ; Tue, 14 Mar 2017 02:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 Gg4oFAMruBpY for ; Tue, 14 Mar 2017 02:30:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F10129515 for ; Tue, 14 Mar 2017 02:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1489483844; bh=vmj+JPl75uX53KHJqqqEIgszekaJV9D/fb3cy2/wMpo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=abq4gSVfmcO/PJBfOfksw8KWDtPnQeq2nHsswhNgwgaY3LGoaYhVgeLKDbQstE1ektdTJuEfzweFw/HLvMQMejIsNa/JAnSZApMGgOS9y5VQhHNGtxFDtf+DH1DqvhWubuuhJefy2fBoKubbglwCPsjCy/OoixqHes1cFxRfraA= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-108-pmf2uku0N46rqKTI5CnNJg-1; Tue, 14 Mar 2017 09:30:40 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 09:30:39 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 09:30:39 +0000 From: Tim Chown To: "sthaug@nethelp.no" Subject: Re: a draft about on-link and submit prefixes Thread-Topic: a draft about on-link and submit prefixes Thread-Index: AQHSnE+kaN/FUsS5F0a931V053SKyqGTuDAAgAAyhYCAACfvgA== Date: Tue, 14 Mar 2017 09:30:39 +0000 Message-ID: <9B0384FA-7DF8-4AE2-ADA3-48C142203575@jisc.ac.uk> References: <20170314.080739.74664517.sthaug@nethelp.no> In-Reply-To: <20170314.080739.74664517.sthaug@nethelp.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:zRPrm3xSvdgQfVcv+Jsihm3kFG1KCVwW+qidbbBlUL5Kq8wO/HN/ZGxAEy38E4WsejJEtBjSXE4v1gfs+4AT8TyvvInxMfOmyGoinTU7W6lsVJXMbAhqMxkjnhkJZrHCM1Ya7z0UpcheIU8wrOvf+WTRj7OD0f5f7kjp7y0YV7YpTXbab3tQzzgBfl7CeRcXDQyJFGiVMy2Eg84ehF11sUSjeOUiNSvKWKXrDzQjdD1OyKzWpCkTvtVx9AcF+/11gGMhWgFSn0XbNL+9Y6ATbyw6LK4WWnUmoq031ARyjPfFlRoi+E5MR3gqB+XdCioGQn39khD4pjDsic+nBj1WyA==; 20:gGojoao9TRUIlYKaisU/sFFyMLDq4EnKYTzIjdltXELQnrz0Eo2jLNqy5Cy96b3fvMeBHHkJycJ2GR/IS6VVAD94Q9oNh78FeGMwOAcyLdgsWo4hl6iJ6jHCnXlahVIjanOVsawetkEYahgIZ6Pa/vbhMuUlZd6DyAFUI+SJRi4= x-ms-office365-filtering-correlation-id: 10aa86a0-4c32-4aec-94ce-08d46abcc733 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(4326008)(6246003)(5250100002)(86362001)(2501003)(38730400002)(33656002)(1730700003)(8936002)(81166006)(2351001)(110136004)(36756003)(8676002)(50226002)(66066001)(102836003)(305945005)(53936002)(6116002)(3846002)(6512007)(189998001)(82746002)(106116001)(5640700003)(6486002)(74482002)(54906002)(83716003)(99286003)(50986999)(6916009)(6436002)(42882006)(76176999)(6506006)(2950100002)(7736002)(2906002)(5660300001)(229853002)(57306001)(3660700001)(3280700002)(2900100001)(53546007)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 09:30:39.3153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: pmf2uku0N46rqKTI5CnNJg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipv6@ietf.org" , "jinmei@wide.ad.jp" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:30:50 -0000 > On 14 Mar 2017, at 07:07, sthaug@nethelp.no wrote: >=20 >> If possible, I would suggest making this document even more general. It'= s >> mostly geared to how implementations treat PIOs, and refers to RFC 4861 = and >> RFC 4862, but really I think the clarifications it makes have much broad= er >> impact. As I see it, the core issues here are: >>=20 >> - IPv6 addresses don't specify any on-link information >> - For most (but not all) unicast addresses, subnet prefixes are 64 bit= s >> per RFC 4291. >> - A given subnet prefix can be spread across multiple links, and a giv= en >> link can support multiple subnet prefixes. >>=20 >> This is not immediately obvious to people who are familiar with the IPv4 >> subnet model, because it is quite different. >=20 > I agree that a generalization is a good idea. In particular, it would > be good to have (in one place) a definition of what an IPv6 subnet is, > especially if a subnet can be spread across multiple links (which is > *not* obvious to me from reading RFC 4861 and RFC 4862). I like this idea. Examples along the lines that Lorenzo included in his ema= il would also be useful to include, with notes on use cases. Tim From nobody Tue Mar 14 03:48:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59B8129548 for ; Tue, 14 Mar 2017 03:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 sha_raiKhPMw for ; Tue, 14 Mar 2017 03:48:44 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D339612943B for ; Tue, 14 Mar 2017 03:48:42 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 14 Mar 2017 10:48:41 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 50664D788A; Tue, 14 Mar 2017 03:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=AycPcWxJMv1/YF+SkE5nj2ToTd0=; b= Cv3NebMWmJ3mffuyEco6yAJPi7l/64QbM3hQopfxbfH3AZSQW4EhfBRQIOI9TH2M ilCH8BOwbNCIM2u37ttKdB9R+PyAimDRvisnQYHhxdTFyIYmwlOAgXCUERfKXEQS kKUlS4qNc/tI4sEHdF68Ld+3VJ8ArYjYDW7xo2VkLYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=d/I9womKwU+5t50j8ryn6mI e2es7v/Zy3Pr8WNyDPpRftpC+c+M570swyGpPsUDMv5y6UJipTdGjo3edhe40DQ3 hS4GvVMlTVHRylFiO1yNUimIGqd0VElHlQvjq5oi/kQGGsEPhh5W2o7UKQ7Jk4KN MuVtFmqoa4HIPdTrbNqo= Received: from h.hanazo.no (unknown [173.38.220.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 1BE74D788E; Tue, 14 Mar 2017 03:48:41 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0E7259D68A3F; Tue, 14 Mar 2017 11:48:39 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5549FCB2-F5DD-457E-8C42-8097D8DB30A2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: a draft about on-link and submit prefixes Date: Tue, 14 Mar 2017 11:48:38 +0100 In-Reply-To: <9B0384FA-7DF8-4AE2-ADA3-48C142203575@jisc.ac.uk> To: Tim Chown References: <20170314.080739.74664517.sthaug@nethelp.no> <9B0384FA-7DF8-4AE2-ADA3-48C142203575@jisc.ac.uk> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , "jinmei@wide.ad.jp" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 10:48:45 -0000 --Apple-Mail=_5549FCB2-F5DD-457E-8C42-8097D8DB30A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> If possible, I would suggest making this document even more general. = It's >>> mostly geared to how implementations treat PIOs, and refers to RFC = 4861 and >>> RFC 4862, but really I think the clarifications it makes have much = broader >>> impact. As I see it, the core issues here are: >>>=20 >>> - IPv6 addresses don't specify any on-link information >>> - For most (but not all) unicast addresses, subnet prefixes are 64 = bits >>> per RFC 4291. >>> - A given subnet prefix can be spread across multiple links, and a = given >>> link can support multiple subnet prefixes. >>>=20 >>> This is not immediately obvious to people who are familiar with the = IPv4 >>> subnet model, because it is quite different. >>=20 >> I agree that a generalization is a good idea. In particular, it would >> be good to have (in one place) a definition of what an IPv6 subnet = is, >> especially if a subnet can be spread across multiple links (which is >> *not* obvious to me from reading RFC 4861 and RFC 4862). >=20 > I like this idea. Examples along the lines that Lorenzo included in = his email would also be useful to include, with notes on use cases. Any idea of what problem we're trying to solve...? Ole --Apple-Mail=_5549FCB2-F5DD-457E-8C42-8097D8DB30A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYx8qGAAoJEL7aWKiYQt92wOQP+wVQd/daMa3aTo/zZsRNeaxN GI4lsDQX4COFpKe9JY/YNXt2SX23hkAiK3mN5/XIhdbgX3jYPlsA1ApinKKkuIc2 S+iRlQuGsvH+B4YpjUwJw33rrlAkHwvuTaBdfr1hIzrR632I6UH+fBGnu7Zjf5Y8 D+yMlQ0DXmkEUZRqOlWTgiLI4B2N1uLA5Lhyryosa9FTzsSlXcWG5VqA0a6a24xf nFex5WCQnkL3Qz2ElMCQD63mOEhyg7OeMOZdNjZGGUg/khml7IuB7OsennEuQZCB KGcjmy23XvH4WKWybzpV0+hYRz1h+STunv9YLgk3ZfE0BMn4UM30os68Q4r0g1V1 VDBTPElMRuh8JADpD/UOe80607rMH4O0B1hCm+TMlHIu4yZWTuuAMEa8XBWjKDSA b3h5h4+aEd+rVtezu0hQVnaqwO93s5etT3+BVmznKxtc1RuhbsFYk/goI0zEFYpG IzDCLg3jxxI9ucM+GH3EJhF5yHo0NhoxbrmNpMMEnWBJd0P2bdsxMQPdcxJ8l1Qz CkKzwTd2qrTcQm+xvowWdBNfx3DFSh9vFUTkpO5uTkNHj6tJ/ad5pnryNKzhcS1l h86jZ8nh9ezT1YXiK2UDBN0Uf16rhM0rQR0wUviHNyq01Q/RUYGR/jGvvWj2ZeUo OE6N6fwNcoBBgiz4DiNB =09NB -----END PGP SIGNATURE----- --Apple-Mail=_5549FCB2-F5DD-457E-8C42-8097D8DB30A2-- From nobody Tue Mar 14 03:57:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0A12952D for ; Tue, 14 Mar 2017 03:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 xrtfWVue7rwq for ; Tue, 14 Mar 2017 03:57:33 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447E712943B for ; Tue, 14 Mar 2017 03:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1489489051; bh=D5FFXWrNT5a6Kn7x4pmM3h42oH3/zO3YHPqmejKpVek=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eqNjcdu/AwCD4eVBgMoAgU3dOAbP2dWJ3cGY3vMpq9Q5MkEfGF+cIXYCP3hwUqhumDruO+x5QdTwj/3UAkfFTi0RFYTIzAXR/81WiJCwenO4kbLdVU3d+h/uRyNGO/ZM+UpdDoorHhuB4/OMqh7Nof6ttLrKHlKQmr93n71QFoQ= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0148.outbound.protection.outlook.com [213.199.180.148]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-19-n1sxHztRMUKFLXV-Ga8P0Q-1; Tue, 14 Mar 2017 10:57:25 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 10:57:22 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 10:57:21 +0000 From: Tim Chown To: "otroan@employees.org" Subject: Re: a draft about on-link and submit prefixes Thread-Topic: a draft about on-link and submit prefixes Thread-Index: AQHSnE+kaN/FUsS5F0a931V053SKyqGTuDAAgAAyhYCAACfvgIAAFc8AgAACb4A= Date: Tue, 14 Mar 2017 10:57:21 +0000 Message-ID: <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> References: <20170314.080739.74664517.sthaug@nethelp.no> <9B0384FA-7DF8-4AE2-ADA3-48C142203575@jisc.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.62.83.230] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:ZOy2oLCyjSacJkyMQfQWqmIviYfB0vZ1yxh9O7jEJueBAMFMlZ24YKt+onVwBM3Ze+f4ujZyxt2jlPbDK35vmkqomW8hVhQG9qVUuUeeFYL6iChNHcgCYYc6l+gKHAtnzum9ofiwbDuohyQ5Q17uvpyiPsGylCiHUmHEn7rqDmNWx5SaOqAB4N9Vj6wQ1VugehGFCYsTjU+TReYsOWYymCGlngvtdWvUw9lLbyrqcPBGdrBkGxcfYLHWR0yxn34eQekC7HdMSKDChOHaAwEyzYVB8e0pPYXPBGtbHFCGxUiJoyLrT/sEN0XPpzPP32tgqVjXPvVVxez6yV9Q1/Xjvg==; 20:KxfIuhLn56xtz9LdYttL3jLpcfEG6m2pOrlX8MBkXN4QXmYK/B7W0Sbr027kX7fGWFYpjUYOyKBJu94h0Px8KlC6YfpOF1381ZfRtoEnQYXXquK7d+Y5MyV9kP64grO7iBgDs7qdQU6M4gqdKZhmFBNHDExwIDGnrarCMkzNYbw= x-ms-office365-filtering-correlation-id: 15b3ce4a-96f4-4a9c-1ee0-08d46ac8e428 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(4326008)(6246003)(5250100002)(86362001)(2501003)(38730400002)(33656002)(1730700003)(8936002)(2351001)(110136004)(8676002)(36756003)(81166006)(50226002)(305945005)(102836003)(53936002)(6116002)(3846002)(66066001)(189998001)(6512007)(106116001)(6486002)(5640700003)(74482002)(54906002)(99286003)(42882006)(50986999)(6916009)(6436002)(76176999)(6506006)(2950100002)(7736002)(2906002)(5660300001)(93886004)(229853002)(57306001)(3660700001)(3280700002)(2900100001)(53546007)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <9CE588AAFEDF5945A828F875F44F226B@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 10:57:21.7588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: n1sxHztRMUKFLXV-Ga8P0Q-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: 6man WG , "jinmei@wide.ad.jp" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 10:57:35 -0000 SGksDQoNCj4gT24gMTQgTWFyIDIwMTcsIGF0IDEwOjQ4LCBvdHJvYW5AZW1wbG95ZWVzLm9yZyB3 cm90ZToNCj4gDQo+Pj4+IElmIHBvc3NpYmxlLCBJIHdvdWxkIHN1Z2dlc3QgbWFraW5nIHRoaXMg ZG9jdW1lbnQgZXZlbiBtb3JlIGdlbmVyYWwuIEl0J3MNCj4+Pj4gbW9zdGx5IGdlYXJlZCB0byBo b3cgaW1wbGVtZW50YXRpb25zIHRyZWF0IFBJT3MsIGFuZCByZWZlcnMgdG8gUkZDIDQ4NjEgYW5k DQo+Pj4+IFJGQyA0ODYyLCBidXQgcmVhbGx5IEkgdGhpbmsgdGhlIGNsYXJpZmljYXRpb25zIGl0 IG1ha2VzIGhhdmUgbXVjaCBicm9hZGVyDQo+Pj4+IGltcGFjdC4gQXMgSSBzZWUgaXQsIHRoZSBj b3JlIGlzc3VlcyBoZXJlIGFyZToNCj4+Pj4gDQo+Pj4+IC0gSVB2NiBhZGRyZXNzZXMgZG9uJ3Qg c3BlY2lmeSBhbnkgb24tbGluayBpbmZvcm1hdGlvbg0KPj4+PiAtIEZvciBtb3N0IChidXQgbm90 IGFsbCkgdW5pY2FzdCBhZGRyZXNzZXMsIHN1Ym5ldCBwcmVmaXhlcyBhcmUgNjQgYml0cw0KPj4+ PiBwZXIgUkZDIDQyOTEuDQo+Pj4+IC0gQSBnaXZlbiBzdWJuZXQgcHJlZml4IGNhbiBiZSBzcHJl YWQgYWNyb3NzIG11bHRpcGxlIGxpbmtzLCBhbmQgYSBnaXZlbg0KPj4+PiBsaW5rIGNhbiBzdXBw b3J0IG11bHRpcGxlIHN1Ym5ldCBwcmVmaXhlcy4NCj4+Pj4gDQo+Pj4+IFRoaXMgaXMgbm90IGlt bWVkaWF0ZWx5IG9idmlvdXMgdG8gcGVvcGxlIHdobyBhcmUgZmFtaWxpYXIgd2l0aCB0aGUgSVB2 NA0KPj4+PiBzdWJuZXQgbW9kZWwsIGJlY2F1c2UgaXQgaXMgcXVpdGUgZGlmZmVyZW50Lg0KPj4+ IA0KPj4+IEkgYWdyZWUgdGhhdCBhIGdlbmVyYWxpemF0aW9uIGlzIGEgZ29vZCBpZGVhLiBJbiBw YXJ0aWN1bGFyLCBpdCB3b3VsZA0KPj4+IGJlIGdvb2QgdG8gaGF2ZSAoaW4gb25lIHBsYWNlKSBh IGRlZmluaXRpb24gb2Ygd2hhdCBhbiBJUHY2IHN1Ym5ldCBpcywNCj4+PiBlc3BlY2lhbGx5IGlm IGEgc3VibmV0IGNhbiBiZSBzcHJlYWQgYWNyb3NzIG11bHRpcGxlIGxpbmtzICh3aGljaCBpcw0K Pj4+ICpub3QqIG9idmlvdXMgdG8gbWUgZnJvbSByZWFkaW5nIFJGQyA0ODYxIGFuZCBSRkMgNDg2 MikuDQo+PiANCj4+IEkgbGlrZSB0aGlzIGlkZWEuIEV4YW1wbGVzIGFsb25nIHRoZSBsaW5lcyB0 aGF0IExvcmVuem8gaW5jbHVkZWQgaW4gaGlzIGVtYWlsIHdvdWxkIGFsc28gYmUgdXNlZnVsIHRv IGluY2x1ZGUsIHdpdGggbm90ZXMgb24gdXNlIGNhc2VzLg0KPiANCj4gQW55IGlkZWEgb2Ygd2hh dCBwcm9ibGVtIHdlJ3JlIHRyeWluZyB0byBzb2x2ZS4uLj8NCg0KSSB0aGluayBpdOKAmXMgYWRk aW5nIEluZm9ybWF0aW9uYWwgY2xhcml0eSwgZXNwZWNpYWxseSBmb3IgdGhvc2UgZmFtaWxpYXIg d2l0aCB0aGlua2luZyDigJl0aGUgSVB2NCB3YXnigJksIHdpdGhvdXQgYWRkaW5nIHVubmVjZXNz YXJ5IHdvcmRhZ2UgZGlyZWN0bHkgdG8gNDI5MS1iaXMuICANCg0KVGlt From nobody Tue Mar 14 04:10:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E5912949A for ; Tue, 14 Mar 2017 04:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 T-RPKanIqCHP for ; Tue, 14 Mar 2017 04:10:48 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 435F8129535 for ; Tue, 14 Mar 2017 04:03:56 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 14 Mar 2017 11:03:56 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B3946D788A; Tue, 14 Mar 2017 04:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=Zl8dpmr15yzeLQbHq83Ph3IWPCM=; b= mGPTPEU2krhEUaE2NOa+DX+sQLQhaDgow/J/gLoumkOam1SwoHlTy61tIjxLkmUG HHpfJTfKWt9KI+1WaUNFpksQGOYWgzMPGvpTprOXFU5dlS0jqeFPJBjJdZ4pNt86 9PGEJ7G0IZjL0LEhDBFAZpdwY4dEJs8RJmi539nnTfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=e+SKPp8b/r9GeaXGERtTTWX e3I90p2Q4XinxI6Ia2VKDEPACfncinrSnYdAB3nkzTPNDzBq9gi9cjP4c0NsdMKK lz8o5Kien+fLkJCHBja8XpH98aSfGsODvejqCALMe/zuHNUO17W8Dl9iJ5iEpYE3 DC4uVxB6hU3shI4lcICA= Received: from h.hanazo.no (unknown [173.38.220.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 7EFE2D788F; Tue, 14 Mar 2017 04:03:55 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D0AB39D68CCF; Tue, 14 Mar 2017 12:03:53 +0100 (CET) From: otroan@employees.org Message-Id: <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_1DB6C507-5F90-4329-ABED-6F3919483966"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: a draft about on-link and submit prefixes Date: Tue, 14 Mar 2017 12:03:53 +0100 In-Reply-To: <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> To: Tim Chown References: <20170314.080739.74664517.sthaug@nethelp.no> <9B0384FA-7DF8-4AE2-ADA3-48C142203575@jisc.ac.uk> <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , "jinmei@wide.ad.jp" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 11:10:49 -0000 --Apple-Mail=_1DB6C507-5F90-4329-ABED-6F3919483966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>>> I agree that a generalization is a good idea. In particular, it = would >>>> be good to have (in one place) a definition of what an IPv6 subnet = is, >>>> especially if a subnet can be spread across multiple links (which = is >>>> *not* obvious to me from reading RFC 4861 and RFC 4862). >>>=20 >>> I like this idea. Examples along the lines that Lorenzo included in = his email would also be useful to include, with notes on use cases. >>=20 >> Any idea of what problem we're trying to solve...? >=20 > I think it=E2=80=99s adding Informational clarity, especially for = those familiar with thinking =E2=80=99the IPv4 way=E2=80=99, without = adding unnecessary wordage directly to 4291-bis. Right, that was what I feared. Including esoteric examples and examples bordering on configuration = errors, just isn't going to add clarity in my opinion. Ole --Apple-Mail=_1DB6C507-5F90-4329-ABED-6F3919483966 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYx84ZAAoJEL7aWKiYQt92i+wP/REsX0n2qSVNOXwHx+quiQ7t Cz1X868mRwnMU6Y1JUWZq4trgFOkFVo+XKh4d8+cjV5Q4L33ryAw9DAjar6lKc/O KQuz4jDfqgdpiaY1HHnt9wUuYPWBKLlAnBQHXgvKXzL7uCRgiH9d1TYo3WcOZ52+ DwdkzRmuZu97fwfi8+7sXzBnxOchzm0R1Lm7ahMgcB2ECYcYQS71covmgoK+AQSb o1buiJbHIMT2xg3Q4mFCWeKd74MhC/72xhFeH61jES5X63Do6zwslEua3liE+DT3 ODjVTThtpMaqV6/GhlgMyaokVJMJjk1NaEDbvGi2W9FuGcfflUfDJYyxCetLo1yg 0R1CDiSoAqx5nFf35GTOmN511TFdq4WWTSuvhyM0oNqcxBdGF8NFKTB6wX8erKOr 2kRzHscDkEZt764H5PaqvxnBJ7tb6IE0ZfZQaI/fL0o3MM6s+A2ESqY10Iicf5z1 sTT3DkNlEbcm1iLGTyAIv2YhaJ5yY4pbO48iNtv2JJbQhbTXT4i+srxNNt0Bm/EN UBrWbzTas/yJSJGp5z8e6GuHsINl41YlQgT50Ia/zonu99i1q933EYzt1pPv07lU ELOYXcHqizwHhnm3VvrfSqsn10u2Vy95Y6krE4kfXhsFE8+3BG0iSY29aMfRy8Rd hnQp1exWr0tRZMX0E7sf =bNz4 -----END PGP SIGNATURE----- --Apple-Mail=_1DB6C507-5F90-4329-ABED-6F3919483966-- From nobody Tue Mar 14 05:26:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA97512956F for ; Tue, 14 Mar 2017 05:26:43 -0700 (PDT) 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 autolearn_force=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 PDotFr5maah9 for ; Tue, 14 Mar 2017 05:26:42 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8D212955C for ; Tue, 14 Mar 2017 05:26:42 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 701D9E6065; Tue, 14 Mar 2017 13:26:40 +0100 (CET) Date: Tue, 14 Mar 2017 13:26:40 +0100 (CET) Message-Id: <20170314.132640.74662612.sthaug@nethelp.no> To: otroan@employees.org Subject: Re: a draft about on-link and submit prefixes From: sthaug@nethelp.no In-Reply-To: <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> References: <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> 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 Archived-At: Cc: ipv6@ietf.org, jinmei@wide.ad.jp X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 12:26:44 -0000 > Right, that was what I feared. > Including esoteric examples and examples bordering on configuration errors, just isn't going to add clarity in my opinion. Could an IPv6 subnet be defined *without esoteric examples*? If not - maybe the IPv6 subnet concept is too complex to be useful? Just asking... Steinar Haug, AS2116 From nobody Tue Mar 14 05:49:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BD51293E0 for ; Tue, 14 Mar 2017 05:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 ZHOcs46nXaNS for ; Tue, 14 Mar 2017 05:49:06 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81543127A90 for ; Tue, 14 Mar 2017 05:49:06 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r136so51124316vke.1 for ; Tue, 14 Mar 2017 05:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=acj6sd8IhE47NIrmnyOJHAmed0noh1PScn+0scf8PZU=; b=hxOuvCOgxShTvzvFuOHv6uc+rWgqFl+eLP8NM9h/ULMSLYbao+bqhkZsFy2/Wqq5bx MFgkYk1FBS+0KlK4cFEaASyIi8KOpeYVRIjlr/6TXFbBMm9k2Be10MeIyVCCO1zrKK5Q XmJcBanAi1x8yFAak/7dGIiAZHovEBwYTFUEU5+xKbnRWknBlKjmKp3sKz1WNaKOruyF F0ro8lMdhecciY9sU/Uogrt9TZiBJD87I+RIsPXrgHz0aUaclxSRnoD42qZWDChu49Cy JiRrr757Jg9aCpc0JFGQbdgYrQRDX0OBmCDAzCthV2A29ma9P397onv1xEH8Hrl3TWUa y9VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=acj6sd8IhE47NIrmnyOJHAmed0noh1PScn+0scf8PZU=; b=QMB24DwuKXj6cDnz9xrj1zIMql7y7X/k3psH7ZxDO+nnJZ+vnOKkakr2INl/mbwj8t qQRZS38AsLSSF6iWutW2yX9qDnJuYQ5NKVbgdNN42ogM8UwiB+vxyzyUJjL6jpMNxoLS 8guqvv8wMwkyUy60bLpgFXnewxRVC20jF5mOdUJyycLFht+8hcuHHxN0nH13KA5lQZXE ky4jfGxMWEUYfOM5HBFijN1/qWi9m8Or1asPw9B+o2v9yXscPKI/vU1rxPn9m4qXIxBu GahTpTOhSsOkf/7AWMTdTFjI4KpVdK5WyZbx17j7DJBA9xoEN/VRsvKFO7q1qSg9PNfO mfaA== X-Gm-Message-State: AMke39llzNS5gytxyLxqJ+sabyUAF2LA3REnc1AB4L//DGT5bbDYCjXYleOFZOukkNC8lD65XnSSMCDaBYTUIWCD X-Received: by 10.31.170.15 with SMTP id t15mr14853824vke.6.1489495745269; Tue, 14 Mar 2017 05:49:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 14 Mar 2017 05:48:44 -0700 (PDT) In-Reply-To: <20170314.132640.74662612.sthaug@nethelp.no> References: <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> <20170314.132640.74662612.sthaug@nethelp.no> From: Lorenzo Colitti Date: Tue, 14 Mar 2017 21:48:44 +0900 Message-ID: Subject: Re: a draft about on-link and submit prefixes To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=001a11432250caef1d054ab04004 Archived-At: Cc: IETF IPv6 Mailing List , =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 12:49:07 -0000 --001a11432250caef1d054ab04004 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 14, 2017 at 9:26 PM, wrote: > Could an IPv6 subnet be defined *without esoteric examples*? > > If not - maybe the IPv6 subnet concept is too complex to be useful? > Let's go back to IPv4, it's easy to understand. --001a11432250caef1d054ab04004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    On T= ue, Mar 14, 2017 at 9:26 PM, <sthaug@nethelp.no> wrote:
    =
    Could an IPv6 subnet be defined *without eso= teric examples*?

    If not - maybe the IPv6 subnet concept is too complex to be useful?

    Let's go back to IPv4, it's easy to un= derstand.=C2=A0
    --001a11432250caef1d054ab04004-- From nobody Tue Mar 14 05:50:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6D8129578 for ; Tue, 14 Mar 2017 05:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 58SrFHMfD2dm for ; Tue, 14 Mar 2017 05:50:32 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BC3127A90 for ; Tue, 14 Mar 2017 05:50:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v2ECoTY5025410 for ; Tue, 14 Mar 2017 13:50:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 40E67203049 for ; Tue, 14 Mar 2017 13:50: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 29D30202D10 for ; Tue, 14 Mar 2017 13:50:29 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2ECoSCA025808 for ; Tue, 14 Mar 2017 13:50:29 +0100 Subject: Re: a draft about on-link and subnet prefixes To: ipv6@ietf.org References: <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> <20170314.132640.74662612.sthaug@nethelp.no> From: Alexandre Petrescu Message-ID: <758cf108-a9ae-37ac-b693-879dafed82d6@gmail.com> Date: Tue, 14 Mar 2017 13:50:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 12:50:34 -0000 Le 14/03/2017 à 13:48, Lorenzo Colitti a écrit : > On Tue, Mar 14, 2017 at 9:26 PM, > wrote: > > Could an IPv6 subnet be defined *without esoteric examples*? > > If not - maybe the IPv6 subnet concept is too complex to be useful? > > > Let's go back to IPv4, it's easy to understand. Not that either. Simpler is better. If simpler could only be other-than-64... Alex > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Mar 14 06:20:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889441294E3 for ; Tue, 14 Mar 2017 06:20:26 -0700 (PDT) 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 autolearn_force=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 DEqgO1AnkPcN for ; Tue, 14 Mar 2017 06:20:25 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id CACE3129498 for ; Tue, 14 Mar 2017 06:20:24 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A447DE6065; Tue, 14 Mar 2017 14:20:23 +0100 (CET) Date: Tue, 14 Mar 2017 14:20:23 +0100 (CET) Message-Id: <20170314.142023.41722849.sthaug@nethelp.no> To: lorenzo@google.com Subject: Re: a draft about on-link and submit prefixes From: sthaug@nethelp.no In-Reply-To: References: <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> <20170314.132640.74662612.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org, jinmei@wide.ad.jp X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 13:20:26 -0000 > > Could an IPv6 subnet be defined *without esoteric examples*? > > > > If not - maybe the IPv6 subnet concept is too complex to be useful? > > Let's go back to IPv4, it's easy to understand. I hope it's possible to ask for clarifications of the IPv6 subnet model without returning to IPv4. I haven't seen a definition of what an IPv6 subnet is. I specifically haven't seen where it is defined that a given subnet prefix can be spread across multiple links - especially since RFC 4291 says "Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link." So if this is no longer the case (just like it's not the case that all IPv6 netmasks are /64 or /127) then it is useful to have this defined somewhere. Steinar Haug, AS2116 From nobody Tue Mar 14 08:32:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449D112947D for ; Tue, 14 Mar 2017 08:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HG1e7AvmztKt for ; Tue, 14 Mar 2017 08:32:02 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FF5129421 for ; Tue, 14 Mar 2017 08:32:01 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id g138so276074itb.0 for ; Tue, 14 Mar 2017 08:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+Lj9Q0Kco0fkPbAZxKfnt12XtlOVMIx0NO41Dzd7+ds=; b=r1Fv8jcgcCEXkr24x7owrsRcxFSJ8KWsFL82dElncpB8euc6G+fzJk0k5ObtQORwh1 RlwaJn/Rb4+hIonJjliZqGYC8kjiZUOuobEPXRcMrUx+mBgaji9fnzmu7hZnTJma7l3e M8KhLP9UcBjajVbMquRTSPm3oiTWMq8pomPA5LLeTlYBDKo235h35a1CIzuQegvls+lg eT7aIoeda86C/VFzyfUVAcIClf+YHIUGzIDm88rrloYIUaPZGyELYTDPyHymyXrcjmK9 i1qaW7wi/huFmLFxZvfpjRtdGDpG62Betd6Vtaej5y2lLGf+iUZGTkhBROgb3SWU4yl8 CIjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+Lj9Q0Kco0fkPbAZxKfnt12XtlOVMIx0NO41Dzd7+ds=; b=DxfD5PbImBRemFduJTYJ1v9qzvkr7OVkw9ewex2x3WjVmBfI5o2+Ttlju/sexj9JVj DKeF89mp5CYTJbfvrx04fRwKikdR4OyWFFcRWxuFINhnUmuOFhCSSreDFLnkIwi0WZXt tyPudhWPyoClJSWFl0wN0GBPhcSWu/u3AqaajzEeXyfNBZYZFLU1aNU8wiqPQuSgzA1W CC7ulEqHh45qCSS880tOoNQmlGcZrw4/nSCKmgQZQSN4LwSo6HMTMRlNluEt34iOGTtV 3FY8CAAKX07iwmn8+UHYzwCZImHxaBIZKIdOsR22aSanANzI7q+ooEaj3aoTZuFL0ZXX JGLQ== X-Gm-Message-State: AFeK/H3KOMSLVhbG6+9AOjJOq5AhDkSJrlb1rkJBXyVWydsw1GEFqREUQt2s1MX+OA7/og== X-Received: by 10.36.66.141 with SMTP id i135mr463711itb.86.1489505521289; Tue, 14 Mar 2017 08:32:01 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id g103sm90976iod.44.2017.03.14.08.32.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 08:32:00 -0700 (PDT) Subject: Re: a draft about on-link and submit prefixes To: otroan@employees.org, Tim Chown References: <20170314.080739.74664517.sthaug@nethelp.no> <9B0384FA-7DF8-4AE2-ADA3-48C142203575@jisc.ac.uk> <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> Cc: 6man WG , "jinmei@wide.ad.jp" From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 15 Mar 2017 04:32:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 15:32:03 -0000 On 15/03/2017 00:03, otroan@employees.org wrote: >>>>> I agree that a generalization is a good idea. In particular, it wou= ld >>>>> be good to have (in one place) a definition of what an IPv6 subnet = is, >>>>> especially if a subnet can be spread across multiple links (which i= s >>>>> *not* obvious to me from reading RFC 4861 and RFC 4862). >>>> >>>> I like this idea. Examples along the lines that Lorenzo included in = his email would also be useful to include, with notes on use cases. >>> >>> Any idea of what problem we're trying to solve...? >> >> I think it=E2=80=99s adding Informational clarity, especially for thos= e familiar with thinking =E2=80=99the IPv4 way=E2=80=99, without adding u= nnecessary wordage directly to 4291-bis. >=20 > Right, that was what I feared. > Including esoteric examples and examples bordering on configuration err= ors, just isn't going to add clarity in my opinion. I think we have no idea yet what the flexibility of IPv6 is going to allo= w people to do in future. By the time our descendants get around to delegating e000::/3 things may look very esoteric indeed. But for now, I think what jinmei proposes is a good idea - it is completely clear from= the recent discussions that some clarification is needed. Brian From nobody Tue Mar 14 10:30:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DB11329F4 for ; Tue, 14 Mar 2017 10:30:13 -0700 (PDT) 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 autolearn_force=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 N-e2UDFQRwIb for ; Tue, 14 Mar 2017 10:30:11 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by ietfa.amsl.com (Postfix) with ESMTP id F16D71329F3 for ; Tue, 14 Mar 2017 10:30:10 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 2555943E9C9; Tue, 14 Mar 2017 18:30:07 +0100 (CET) Date: Tue, 14 Mar 2017 18:30:01 +0100 (CET) Message-Id: <20170314.183001.1219187989044942807.he@uninett.no> To: otroan@employees.org Cc: Tim.Chown@jisc.ac.uk, ipv6@ietf.org, jinmei@wide.ad.jp Subject: Re: a draft about on-link and submit prefixes From: Havard Eidnes In-Reply-To: <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> References: <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 17:30:13 -0000 Pj4+Pj4gSSBhZ3JlZSB0aGF0IGEgZ2VuZXJhbGl6YXRpb24gaXMgYSBnb29kIGlkZWEuIEluIHBh cnRpY3VsYXIsIGl0IHdvdWxkDQo+Pj4+PiBiZSBnb29kIHRvIGhhdmUgKGluIG9uZSBwbGFjZSkg YSBkZWZpbml0aW9uIG9mIHdoYXQgYW4gSVB2NiBzdWJuZXQgaXMsDQo+Pj4+PiBlc3BlY2lhbGx5 IGlmIGEgc3VibmV0IGNhbiBiZSBzcHJlYWQgYWNyb3NzIG11bHRpcGxlIGxpbmtzICh3aGljaCBp cw0KPj4+Pj4gKm5vdCogb2J2aW91cyB0byBtZSBmcm9tIHJlYWRpbmcgUkZDIDQ4NjEgYW5kIFJG QyA0ODYyKS4NCj4+Pj4gDQo+Pj4+IEkgbGlrZSB0aGlzIGlkZWEuIEV4YW1wbGVzIGFsb25nIHRo ZSBsaW5lcyB0aGF0IExvcmVuem8NCj4+Pj4gaW5jbHVkZWQgaW4gaGlzIGVtYWlsIHdvdWxkIGFs c28gYmUgdXNlZnVsIHRvIGluY2x1ZGUsIHdpdGgNCj4+Pj4gbm90ZXMgb24gdXNlIGNhc2VzLg0K Pj4+IA0KPj4+IEFueSBpZGVhIG9mIHdoYXQgcHJvYmxlbSB3ZSdyZSB0cnlpbmcgdG8gc29sdmUu Li4/DQo+PiANCj4+IEkgdGhpbmsgaXTigJlzIGFkZGluZyBJbmZvcm1hdGlvbmFsIGNsYXJpdHks IGVzcGVjaWFsbHkgZm9yDQo+PiB0aG9zZSBmYW1pbGlhciB3aXRoIHRoaW5raW5nIOKAmXRoZSBJ UHY0IHdheeKAmSwgd2l0aG91dCBhZGRpbmcNCj4+IHVubmVjZXNzYXJ5IHdvcmRhZ2UgZGlyZWN0 bHkgdG8gNDI5MS1iaXMuDQo+IA0KPiBSaWdodCwgdGhhdCB3YXMgd2hhdCBJIGZlYXJlZC4NCj4g SW5jbHVkaW5nIGVzb3RlcmljIGV4YW1wbGVzIGFuZCBleGFtcGxlcyBib3JkZXJpbmcgb24NCj4g Y29uZmlndXJhdGlvbiBlcnJvcnMsIGp1c3QgaXNuJ3QgZ29pbmcgdG8gYWRkIGNsYXJpdHkgaW4g bXkNCj4gb3Bpbmlvbi4NCg0KSSBkaXNhZ3JlZS4gIE1ha2luZyBhIGNsYXJpZmljYXRpb24gaW1w bGllcyBkZWxpbmVhdGluZyB0aGUgYm9yZGVyLA0KYW5kIG5vdCBuZWNjZXNzYXJpbHkgZGVzY3Jp YmluZyB0aGUgdHlwaWNhbCBzaXR1YXRpb24gb3IgdXNhZ2UuICBCeQ0KbmVjZXNzaXR5IHlvdSB3 aWxsIGhhdmUgdG8gZmluZCBlZGdlIGNhc2VzIGFsb25nIHRoZSBib3JkZXIuDQoNCkRvIHlvdSB0 aGluayB0aGVyZSdzIHNvbWV0aGluZyB3aGljaCBpcyBmYWN0dWFsbHkgb3IgdGVjaG5pY2FsbHkN CmluYWNjdXJhdGUgaW4gdGhlIGRyYWZ0IEppbm1laSBwb3N0ZWQ/ICBEbyB5b3UgdGhpbmsgc29t ZSBvZiB0aGUNCnNldHVwcyB3aGljaCBhcmUgZGVzY3JpYmVkIGFyZSBzdGlsbCAid2l0aGluIHRo ZSBib3JkZXIiIG9mIHdoYXQncw0KZGVzY3JpYmVkIGluIHRoZSBzdGFkbmFyZHMgYnV0IHNob3Vs ZCBub3QgYmU/DQoNCkl0IG1heSBub3QgYmUgcHJldHR5LCBidXQgaXQncyBwZXJoYXBzIHRpbWUg dG8gb3duIHVwIHRvIHdoYXQgd2UndmUNCmJlZ2F0Pw0KDQpSZWdhcmRzLA0KDQotIEjDpXZhcmQN Cg== From nobody Tue Mar 14 10:55:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B1C120689 for ; Tue, 14 Mar 2017 10:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 gZiWiEzbuMjO for ; Tue, 14 Mar 2017 10:55:10 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353F71200E9 for ; Tue, 14 Mar 2017 10:55:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v2EHt9qZ058718; Tue, 14 Mar 2017 10:55:09 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v2EHt6kj058687 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 14 Mar 2017 10:55:06 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 14 Mar 2017 10:55:05 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Tue, 14 Mar 2017 10:55:05 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: a draft about on-link and submit prefixes Thread-Topic: a draft about on-link and submit prefixes Thread-Index: AQHSnE+gspgFpkHp+UGBnGnpIc+eZqGULYkAgAAyhYCAACf0gIAAFcoAgAACb4CAAAHTgIAASvCA//+wdHA= Date: Tue, 14 Mar 2017 17:55:05 +0000 Message-ID: <75bc0c36624c40b9ada79e8b3cd28359@XCH15-06-11.nw.nos.boeing.com> References: <20170314.080739.74664517.sthaug@nethelp.no> <9B0384FA-7DF8-4AE2-ADA3-48C142203575@jisc.ac.uk> <49C05C3D-9594-4A46-BBA4-5767A9FDD34A@jisc.ac.uk> <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 17:55:11 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFIENhcnBlbnRlcg0KDQo+IEJ1dCBmb3Ig bm93LCBJIHRoaW5rIHdoYXQgamlubWVpIHByb3Bvc2VzIGlzIGEgZ29vZCBpZGVhIC0gaXQgaXMg Y29tcGxldGVseQ0KPiBjbGVhciBmcm9tIHRoZSByZWNlbnQgZGlzY3Vzc2lvbnMgdGhhdCBzb21l IGNsYXJpZmljYXRpb24gaXMgbmVlZGVkLg0KDQorMQ0KDQpJIGZvdW5kIEppbm1laS1zYW4ncyBJ LUQgdG8gYmUgcXVpdGUgY2xlYXIgYW5kIHRvIHRoZSBwb2ludC4gTm90IHN1cmUgSSB3b3VsZCBt dWRkeSBpdCB1cCB3aXRoIHRvbyBtYW55IHNwZWNpZmljIGV4YW1wbGVzLCBvZiB0b28gbWFueSBj b3JuZXIgY2FzZXMuIFdoYXQgaXMgaW4gdGhlcmUgbm93IGlzIGZhY3R1YWwsIGFuZCBjbGVhcmx5 IGV4cHJlc3NlZC4gR29pbmcgb2ZmIG9uIHRhbmdlbnRzIHdpbGwgY3JlYXRlIGVuZGxlc3MgZGVi YXRlcyBhcyB0byB3aGV0aGVyIHNvbWUgY29ybmVyIGNhc2UgaXMgYSBtaXNjb25maWd1cmF0aW9u IG9yIG5vdCwgaW50ZW5kZWQgYnkgdGhlIEZvdW5kaW5nIEZhdGhlcnMgb3Igbm90LCBhbmQganVz dCBwcm9sb25nIHRoZSBtaXNjb25jZXB0aW9ucyBhYm91dCBhIHJpZ2lkIDY0LWJpdCBib3VuZGFy eS4NCg0KQmVydA0KDQo= From nobody Tue Mar 14 11:26:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EA912998F for ; Tue, 14 Mar 2017 11:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UOO9cYsM_56B for ; Tue, 14 Mar 2017 11:26:43 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAFB126CE3 for ; Tue, 14 Mar 2017 11:26:43 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id p64so255081026qke.1 for ; Tue, 14 Mar 2017 11:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=r1DanXygxeL7VrnRiEqXqt/tRqamu0OLz8LJI91K8ic=; b=DLhVHV6IqGtquWD+JKTCuOplrpIASK7z28KTWGgp/T8QMiTPhk3HTYJ6DTW2V4uzC3 QMHM5tvBUR1+FzpcYt0PIx9FyqH3W5NwUZpaJyogb3Tsu1U/VNfKC+XUzydZFAIEUOOs I46m5DmJZ6XRWzpXlZrplBx6C2BnzThQa5DKiK/KG9zu8Cimi5zNuaqo4ago9CwMVodv ni+2I8ZkrPdcKRBjNhFiGtU554FkpxCHdnppO3oH6T0AoVwrQ3Mk4GYt1MAOzjOPgpqf g4YpLWM+z31Csbe2eX444X+rxDLytwd354VNJQX2enRo0OjerJeRYui2GiShHhXOx//S dQIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=r1DanXygxeL7VrnRiEqXqt/tRqamu0OLz8LJI91K8ic=; b=c2xsYTIYvFgfkmIdAVQsPhJ6moNhQTD5xhTy6ddnmer9nWjIb8H5FXP8WW2NqZ5zzM X6AtlIeP14KYVwbrCd8+BXrg21sVgbtIruo4IZjOkzYr7UeL4tjiFt1W40FFXvCl8TnQ X/qIAW6DhZy0bx5mxU32YVRYEEbVBhNEDIRNwjNmVz6RQSnp3ImAwkHECW6VEiXCq9eo 4skcv8pWw86NYbpa2js1UGQpUV9/Cy/5WjfSJVV/1nO0lCZNZiA1KTz5Fma4mqy4cw7X Hm3r2y3K0b1IpZ+TzdZgyos1SwESKT4JqBgfBRcrjAvUT6EGOsJktIspm4Kg2MWZLmDv VyBg== X-Gm-Message-State: AFeK/H24R3TupYnQPRbPs6p4k4ABbtXzDcFDv/XBdq+cKVDFgLv4/AoNL9Fn7pO1T+K0vilsKf64fQzpZD9dBw== X-Received: by 10.55.146.135 with SMTP id u129mr37153259qkd.219.1489516002197; Tue, 14 Mar 2017 11:26:42 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Tue, 14 Mar 2017 11:26:41 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 14 Mar 2017 11:26:41 -0700 X-Google-Sender-Auth: JKs5-A6YKrSUJuk0eNQVBDxLvrU Message-ID: Subject: Re: a draft about on-link and submit prefixes To: Lorenzo Colitti Cc: IPv6 IPv6 List Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 18:26:46 -0000 At Tue, 14 Mar 2017 13:06:50 +0900, Lorenzo Colitti wrote: > > I've submitted a new individual draft on the separation between > > on-link and (SLAAC) subnet prefixes, at the risk of stating the > > obvious: https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix- > > clarify/ > > > Thanks for attempting to clarify the topic. I think it is useful to do so, > since the distinctions here are very subtle and even many in the WG (not to > mention in the IETF or in the industry) are not fully aware of their > implications. Thanks for reading the draft and for the prompt feedback. > If possible, I would suggest making this document even more general. It's > mostly geared to how implementations treat PIOs, and refers to RFC 4861 and > RFC 4862, but really I think the clarifications it makes have much broader > impact. As I see it, the core issues here are: I see the possibility of generalization. In particular, we could generalize the term/concept of "subnet prefix" so that it doesn't limit the context to SLAAC. At least in the initial version of the draft, however, I intentionally focused on the prefixes advertised via PIOs in order to avoid distraction or unnecessary controversy from the primary clarification I wanted to make first (which itself was deemed to be sufficiently subtle). If others also think it helpful to generalize the discussion as a continuation of this draft, I'm happy to revise the draft that way. A few quick comments on the specific points: > - IPv6 addresses don't specify any on-link information This one actually seems to be covered by RFC5942 (although it's a different question whether it's well understood and/or whether a further clarification attempts help). > - For most (but not all) unicast addresses, subnet prefixes are 64 bits > per RFC 4291. I'm not sure if this is directly relevant to the separation of on-link and subnet prefixes. > - A given subnet prefix can be spread across multiple links, and a given > link can support multiple subnet prefixes. Same for the latter. I see the former is related to the fact that on-link prefixes are independent from subnet prefixes, but I'm not so sure if this will be in the scope of "generalized clarification". -- JINMEI, Tatuya From nobody Tue Mar 14 12:19:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1331D1299AF for ; Tue, 14 Mar 2017 12:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Z2vAwB-2fCK4 for ; Tue, 14 Mar 2017 12:19:41 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA3B129705 for ; Tue, 14 Mar 2017 12:19:41 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id j5so74484710pfb.2 for ; Tue, 14 Mar 2017 12:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=/WJ9MH5nXo/i5PUaMVL0AGMSqNN+3xuWY90SGOyDFJ0=; b=ivohGfaHT6OaFAtTbKIMNsYbyUAFDCF7FsLurOHvqkc9Z8CPE8F8rb6o9JgbWwtpVM fWGmhZHIK9BagfdIaQCkqXyMVIcGh8A0GY0Ms/d6dJsd0By2nvPM37fZDHQLuv9kVivs GMh84cCUrW8M7MspzIzPk4gTLc06ZbIJ77lxZ96g0FYINTgNWNyYSEQfomxh+vWjyMFp ksy4X96BV4Aehy6T7K9Ot9qmHqF/WVAP9HOIc8HHz0kqgOCaeB6N/FWXxRcHUAOHeeET 1i6sesn7VGb/tyrZPveXt9SoiKgioBQ3AcpH5TOKzcXzyv9S1auN+2PPx7Q7MDkOQKBW sCOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=/WJ9MH5nXo/i5PUaMVL0AGMSqNN+3xuWY90SGOyDFJ0=; b=uSthkza4FOG4s/W9x7fnUDykW6kaSurLEdMg5LXTpTSmFDhTCCHJ3Jf7sHyrlCmr5G tOD39nW6XJ4UynCZOlck2r0uXWrQ2LwWVMjlUqy9BvE2zY9tL5/MjnmYGH9z8Ezk8Mxo 8ma4XuJHy3hZidO4cRS0vKHpP15KeFId++DjpHUNiBkS4W56+q6he9MDbeq8fUBniKOe a1Ia/QD7ueiuB3Vntx2q93q5s5Y6yVNX28fTon9sipT50G256EVA2+HdpnSlpEknx/GL ck1r6JstH+8qUXHa3db9hJDTOh/Oij+FTzUyOw62PZTpz4OMQhZmOZImo//9Qin1pUH+ hawA== X-Gm-Message-State: AMke39nOysUxBcwdAkLFqCeA1f9hjdfudbVCWXayB2yYiXXL0B8jHh4v/6JTVXFmTvbyUrAa X-Received: by 10.99.64.70 with SMTP id n67mr44949576pga.53.1489519180992; Tue, 14 Mar 2017 12:19:40 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id e2sm40269918pga.61.2017.03.14.12.19.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 12:19:40 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_2AE83383-DA0F-4A23-8693-8601FBCC3F08" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: a draft about on-link and submit prefixes Date: Tue, 14 Mar 2017 12:19:39 -0700 References: <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> <20170314.132640.74662612.sthaug@nethelp.no> <20170314.142023.41722849.sthaug@nethelp.no> To: 6man WG In-Reply-To: <20170314.142023.41722849.sthaug@nethelp.no> Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 19:19:43 -0000 --Apple-Mail=_2AE83383-DA0F-4A23-8693-8601FBCC3F08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, First, my thanks to Jinmei-san for this well-written draft. I have only = minor quibbles with it, most of which were already surfaced by Lorenzo, = and the rest are probably nits not worth mentioning at this point. I=E2=80=99d like to respond to a comment that came in the ensuing = discussion. I think it=E2=80=99s relevant. On Mar 14, 2017, at 06:20, sthaug@nethelp.no wrote: >=20 > I haven't seen a definition of what an IPv6 subnet is. I specifically > haven't seen where it is defined that a given subnet prefix can be > spread across multiple links - especially since RFC 4291 says >=20 > "Currently, IPv6 continues the IPv4 model in that a subnet prefix is > associated with one link." >=20 > So if this is no longer the case (just like it's not the case that all > IPv6 netmasks are /64 or /127) then it is useful to have this defined > somewhere. p1. In my proposal for additional text in revising RFC 4291, I noted = that the sentence highlighted above is a) superseded by The IPv6 Subnet = Model [RFC5942], which coincidentally provides a definition of an IPv6 = subnet in section 1, and b) I offered an alternative formulation of that = text with the statement updated to match current reality accordingly. p2. A fine example of an existing technology where a subnet is shared = across multiple links is "Extending an IPv6 /64 Prefix from a Third = Generation Partnership Project (3GPP) Mobile Interface to a LAN Link=E2=80= =9D [RFC7278]. Another that comes to mind is a certain application of = "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based = Networks=E2=80=9D [RFC6282] at HOMENET routers connected to residential = LAN networks behind IPv6 Customer Edge Routers that implement "Basic = Requirements for IPv6 Customer Edge Routers=E2=80=9D [RFC7084]. Clearly, that sentence in RFC 4291 highlighted above, which persists in = the latest draft of I-D.ietf-6man-rfc4291bis too, is a source of = confusion. We have published many RFCs, several of them in the Standards = Track, that conflict absolutely with that statement. It=E2=80=99s = definitely not an accurate statement anymore, if it ever was. --james woodyatt > --Apple-Mail=_2AE83383-DA0F-4A23-8693-8601FBCC3F08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi everyone,

    First, my thanks to Jinmei-san for this well-written draft. I = have only minor quibbles with it, most of which were already surfaced by = Lorenzo, and the rest are probably nits not worth mentioning at this = point.

    I=E2=80=99= d like to respond to a comment that came in the ensuing discussion. I = think it=E2=80=99s relevant.

    On Mar 14, 2017, at 06:20, sthaug@nethelp.no = wrote:

    I haven't seen a definition of what an IPv6 = subnet is. I specifically
    haven't seen where it is defined = that a given subnet prefix can be
    spread across multiple = links - especially since RFC 4291 says

    "Currently, IPv6 continues the IPv4 model in that a subnet = prefix is
    associated with one link."

    So if this is no longer the case (just like it's not the case = that all
    IPv6 netmasks are /64 or /127) then it is useful = to have this defined
    somewhere.

    p1. In my proposal for additional text in revising = RFC 4291, I noted that the sentence highlighted above is a) superseded = by The IPv6 Subnet Model [RFC5942], which coincidentally provides a = definition of an IPv6 subnet in section 1, and b) I offered an = alternative formulation of that text with the statement updated to match = current reality accordingly.

    p2. A = fine example of an existing technology where a subnet is shared across = multiple links is "Extending an IPv6 /64 Prefix from a Third Generation = Partnership Project (3GPP)  Mobile Interface to a LAN Link=E2=80=9D = [RFC7278]. Another that comes to mind is a certain application of = "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based = Networks=E2=80=9D [RFC6282] at HOMENET routers connected to residential = LAN networks behind IPv6 Customer Edge Routers that implement "Basic = Requirements for IPv6 Customer Edge Routers=E2=80=9D = [RFC7084].

    Clearly, that sentence in RFC 4291 highlighted above, which = persists in the latest draft of I-D.ietf-6man-rfc4291bis too, is a = source of confusion. We have published many RFCs, several of them in the = Standards Track, that conflict absolutely with that statement. It=E2=80=99= s definitely not an accurate statement anymore, if it ever = was.


    --james woodyatt <jhw@google.com>



    = --Apple-Mail=_2AE83383-DA0F-4A23-8693-8601FBCC3F08-- From nobody Tue Mar 14 15:55:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64947131614 for ; Tue, 14 Mar 2017 15:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5ali9fwdwgZW for ; Tue, 14 Mar 2017 15:55:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EC8129B4C for ; Tue, 14 Mar 2017 15:55:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 34A22205AB; Tue, 14 Mar 2017 19:18:03 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 21B0C636E0; Tue, 14 Mar 2017 18:54:59 -0400 (EDT) From: Michael Richardson To: IPv6 IPv6 List , Lorenzo Colitti cc: =?us-ascii?Q?=3D=3FUTF-8=3FB=3F56We5piO6YGU5ZOJ=3F=3D?= Subject: Re: a draft about on-link and submit prefixes In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:55:02 -0000 --=-=-= Content-Type: text/plain Lorenzo Colitti wrote: > * IPv6 addresses don't specify any on-link information > * For most (but not all) unicast addresses, subnet prefixes are 64 > bits per RFC 4291. > * A given subnet prefix can be spread across multiple links, and a > given link can support multiple subnet prefixes. Is it reasonable for some routers to RA for a PIO as on-link on some interfaces/ports, and not on others? I think that this doesn't work unless you mix in some kind of proxy-ND. My goal in asking this is to reduce some of the pushback from the reasonable proposal (in other places, such as homenet) that home wifi not be bridged to wired, and that different frequencies should have their own prefixes. The alternative is that all interfaces get not-on-link, and we manage /128 routes, which seems slightly dumb to do on the wired side. > A corollary to the above is that subnet prefixes don't specify any > on-link information. The fact that the subnet prefix is "almost > always" 64 bits long doesn't mean that the on-link prefix cannot be > /48, /89 or /120. The fact that the on-link prefix is /120 doesn't > mean that nodes on that link have to have addresses in that /120. Can we do something useful with this? It seems to me that with DHCPv6 doing assignment, that we could. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljIdMIACgkQgItw+93Q 3WWGLggAjxmOnI7ChH3LYDiyCI2RPt5WSL2MDJZJ/67yIR0v5h/S71cbbTFz4VqR 100PZAhhe5bzsBWafwCQieB+yNB1jqHs+ks03/iM1hgIUGBLzDiurz6AlY7knndu CKCp0xwCfRcogUPznLmqULhH9Xk8/sSZ+QsQjQ2p3O7PKTgbH7Xb9zTRIR2TIIgB Cy+rUbeMIGf3Dgh3rhp3EKSoNKqijBrz5bq4rnbir/LuOZgmvBP+YRmIQUw9vYhy rDA7z0+4/WoZDp2d46Ioki+Hnw3wAl+fp0VD3AlwFb95GQqgNbLnVPVXUgUcM+e3 eRCSmhE9kJUc7083EmTul3RE4MjOCw== =XHHK -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 14 16:01:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8BB129BC6 for ; Tue, 14 Mar 2017 16:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ktJT1qGf71T0 for ; Tue, 14 Mar 2017 16:01:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F78129440 for ; Tue, 14 Mar 2017 16:01:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2108A205AB; Tue, 14 Mar 2017 19:24:07 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 13B4A636E0; Tue, 14 Mar 2017 19:01:03 -0400 (EDT) From: Michael Richardson To: ipv6@ietf.org cc: sthaug@nethelp.no, lorenzo@google.com, jinmei@wide.ad.jp Subject: Re: a draft about on-link and submit prefixes In-Reply-To: <20170314.142023.41722849.sthaug@nethelp.no> References: <026FE8B0-6FFA-4835-8D72-D4CBC6187A2D@employees.org> <20170314.132640.74662612.sthaug@nethelp.no> <20170314.142023.41722849.sthaug@nethelp.no> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 23:01:06 -0000 --=-=-= Content-Type: text/plain sthaug@nethelp.no wrote: > I haven't seen a definition of what an IPv6 subnet is. I specifically > haven't seen where it is defined that a given subnet prefix can be > spread across multiple links - especially since RFC 4291 says > "Currently, IPv6 continues the IPv4 model in that a subnet prefix is > associated with one link." My goal is to get rid of layer-2 games; most of which were caused by lack of subnets in IP4b., They have become huge un-seeable/un-traceable protocols stacks of various kinds of poorly implemented STP. v6 prefixes are plentiful, and we should use them... but we haven't found "the" solution to discovery across subnets, and haven't made side-wide multicast work easily, so we are doing site-wide discovery via other methods. So, many want to keep bridging networks with 1000:1 bandwidth ratios (GbE vs -70dbm wifi at 1Mb/s... ) Maybe there are some happy middle ground that comes from the revelation that subnets != links. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljIdi4ACgkQgItw+93Q 3WXqyQf/St2H47l0IjCah0zV6Wy/e+Es3foGzEo7leVFviurZ1up3qIcjQY+TVbZ jMZICypd+6+tlcxcUqKWmHHxEJxwfLEjsHk8dVuHEYl2n4UT7J2xZ2iHDYuq2QLm 5LrePFk+9sZHcXEpKlIAo4O4S4DntaRUADBhCPGBQW0vzCWEsNNa6LhCN3caXJt2 6JgvnLNH9A5ovqvlrRIWgX+I340XHO02fX9s0hUQgPaVEKZZFFf9nZmaler7Xktw baytYHnKq2aLh2FMoUwika5vf3MQ8THLGz/gwfOHRI403kms2ZpSQWUxFYmj4beH EA34/lWip17sVJtCgozPaGYINxErJA== =BpD3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 14 17:08:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A023D1316E4 for ; Tue, 14 Mar 2017 17:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LitQRdeP3igJ for ; Tue, 14 Mar 2017 17:08:35 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A794F1293E3 for ; Tue, 14 Mar 2017 17:08:35 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id 1so1433272qkl.3 for ; Tue, 14 Mar 2017 17:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UGMFwgpilSo+QmSaWmm7QJ9WShvw4IlZtUrFP4ytpNo=; b=OG/D+Rs3dtQ2OCDjUJunXmNDi/PA9F24nPcPwIfOKKIXPrpfLJjVNpc5wmtLaWHzzG iZqrbwNwlyDj6GyWAmqOYAuPaDrfyuJwrvELqAjowJdeGrM7tcFQr/BikhQddST19a8D +STinAGOz+h3CNEJVjvYS7osvokaH6kLQ1hqx2CGn5hP1LRAVzqg78w/0C6II/8/LS5L VfeC0vnSM3E5DlXtrxDyxUyBmf0gZWljuaRn0Bn3PimbKQM1HsGLISpZ09mcOxjDZY8z nMQ6w54hYX3icdQWoT9VmJoE7NbPWmbo4RSsiAR0jNvZkmCzyK1k9CbIuP3El2je5kPO yvAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UGMFwgpilSo+QmSaWmm7QJ9WShvw4IlZtUrFP4ytpNo=; b=DRa7sRfm+SgJgeE2vRuRu8pVwblPVuFbGiwINEFtPRB/5HG4cYunHWzYOe1oXvPc6n icOTkqtDvHE4cbQ5hgCg0nu8z6DwStv5Dp/oByV7XWTjwzN9j9T9CZ2B2rB5/ScCJXCk nmgweAUVYBgKfBQ5g1oFgaolkxWrUIBzZTjIobakqh4xvbX1urqIqD+nkqIsEKMtYMV7 sHmybonyKG0Cdgm0YCNuplDXqEk7Oe+QKvAdw7Vd0JHfI3sahGHTtnmMvwuI+o7lqfiA WK3Huvf5HM1et5uwsYZPlNvchf17wwBc55yz2RmPX/n/uXyigsNJAcFJDbb4l5YLm5+n Ydqg== X-Gm-Message-State: AFeK/H0vE8dCFud90EabGWJQI9lTp+i5vFMOLBZUHSMujwNIVoE6y6yxPonwzeheCWW0MeLzzbwRHetGQY8aIA== X-Received: by 10.233.222.197 with SMTP id s188mr295344qkf.311.1489536514451; Tue, 14 Mar 2017 17:08:34 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Tue, 14 Mar 2017 17:08:34 -0700 (PDT) In-Reply-To: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 14 Mar 2017 17:08:34 -0700 X-Google-Sender-Auth: p_yCPp48Dw1KEyvO3XBqWZXmpKY Message-ID: Subject: Re: a draft about on-link and subnet prefixes To: Alexandre Petrescu Cc: IPv6 IPv6 List Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 00:08:39 -0000 At Tue, 14 Mar 2017 09:47:49 +0100, Alexandre Petrescu wrote: > I suggest adding the following upfront: > > "The onlink|SLAAC dichotomy MAY be applied; if it is applied, then the > routing towards that subnet MUST use the shortest plen of the two" > > E.g. if the on-link prefix is 48 and the SLAAC prefix is 64 then the 48 > (not the 64) must be in the rt tables of routers with routes towards > that subnet. Thanks for the feedback. I'm not sure how to interpret this, but in any event, adding a new MAY or MUST is clearly out of scope of this draft. It only intends to explain what the current specifications try to specify in case it may no be very clear. > > I've submitted a new individual draft on the separation between > > on-link and (SLAAC) subnet prefixes, at the risk of stating the > > obvious: > > https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix-clarify/ > > I have read the draft. It was a good read, thank you. It clarifies the > difference between on-link prefixes and SLAAC prefixes. > > Here are my comments in summary: > > 1. It does not resolve the question of whether or not the 64bit IID > should be required in the IPv6 Addressing Architecture. No it doesn't, and it's intentional. > 2. The explanation of the dichotomy onlink|SLAAC should be accompanied > by a recommendation of using the shortest plen of the two (even when > that plen is not 64) in the Internet routing setup towards that > subnet. This is the crux of it. I'm not sure what this means. > This recommendation should acknowledge that when that plen is larger > than 64, SLAAC/Ethernet can not work. There's no recommendation in this draft; it only talks about facts. Anyway, it's true that if (SLAAC subnet) plen is larger (or shorter) than 64 SLAAC over Ethernet does not work. It's already covered in bit more generalized text: [...] This means that, for example, if the length of interface identifiers for the link is specified as 63, 64, or 65, then the SLAAC subnet prefix length must be 65, 64, or 63, respectively; otherwise the PIO is ignored for the purpose of SLAAC. > This recommendation should acknowledge that when that plen is smaller > than 64, SLAAC/Ethernet can work by using 64 for SLAAC and plen for > on-link determination. I'm not sure what this means. But, as long as the current specifications go, SLAAC doesn't work on Ethernet if the subnet prefix is smaller (or larger for that matter) than 64. If you are trying to propose loosening it, that's fine - please write a proposal in a separate draft. But that's out of scope of this draft, which only talks about what current standards state. > 3. The draft would benefit from dealing with LL addresses too. Perhaps, but I intentionally made it more focused to avoid distraction, at least for the 00 version. > Details below: > > > Although this misunderstanding would normally not cause troubles in > > practical deployments, it can be a source of operational surprise or > > interoperability problems once an administrator wants to exploit the > > idea of this separation more "creatively". > > This needs the administrator to have ability to set distinct routes > towards presumably distinct 'on-link' and SLAAC prefixes. > > > For brevity, this document focuses on global unicast prefixes. > > Discussions on any other types of prefixes, including unicast link- > > local prefixes, are out of scope of this document. > > I'll skip any LL-specific discussion to avoid distraction. If and when we see the need to cover this topic within this draft, I'll come back to these points. > > > > [RFC4861] and [RFC4862] intentionally separate the concept and > > handling of on-link prefixes and SLAAC subnet prefixes, even when > > they are specified in the same single PIO. [...] > However, this dichotomy has very many consequences. > > A number of RFCs and I-Ds misunderstand this dichotomy "on-link"|"SLLAC" > and make wrong recommendations. Maybe you want this draft to clarify > all these RFCs? Which RFCs are they? I don't intend to update any existing RFCs in this draft, but I could refer to those RFCs as example cases if and when I revise the draft. > One of the worst consequence is the allocation of single /64 prefix for > an end user. Many drafts and their respective deployments only give a > /64 to the end user: it is used both for SLAAC _and_ for on-link > determination. If they agreed the dichotomy then they would give at > least two distinct prefixes to the end-user: one for SLAAC and one for > on-link determination. Perhaps, but such a discussion is out of scope of this draft. > Another consequence is the possibility to make wrong configurations. > > A wrong configuration is the following: in a subnet where plen1 is for > on-link determination and plen2 is for SLAAC, it is easily possible to > make a Host believe a Neighbor is on-link whereas the routing system to > which that subnet is connected routes to another subnet for same Neighbor. > > If somebody plays too much with this plen1 and plen2 configurations > (onlink|SLAAC) on a subnet one can easily make mistakes. There is no > recommendation how to avoid these mistakes. > > Recommendations about how to play with this onlink|SLAAC dichotomy will > need to take into account how routing is based on longest-prefix match. > > Also these recommendations must make sure that allocating a > single /64 to an end user does not get into widespread use. Ditto. > > Perhaps the administrator of the link wanted to force most of on-link > > communication to 2001:db8:1:2::/64 to be first sent to a default > > router, while allowing a particular set of hosts (those using the > > address that match the on-link prefix) to communicate directly. > > I agree with the use-case. > > But maybe the administrator should know too that the default router will > reply back with an ICMP Redirect leading to an end result where the > on-link prefix is same as the SLAAC prefix in the rt table. Yes (although the admin would disable sending redirects if this is really the operation they want and their router supports the knob), that's why the draft says "first sent to a default router". Anyway, as admitted this is an imaginary use case. I didn't intend to insist that's necessarily realistic. > > An on-link prefix could be longer than an SLAAC subnet prefix. For > > example, when the latter is 2001:db8:1:2::/64, the former could be > > 2001:db8:1:2:3:4::/80. > > I agree it could be. > > But in this case, one also must make sure the routing towards that > subnet is the SLAAC's /64 (not the 'onlink's /80). I don't see why. > > An on-link prefix could also be shorter than an SLAAC subnet prefix. > > For example, when the latter is 2001:db8:1:2::/64, the former could > > be 2001:db8:1::/48. > > I agree it could be. > > In this case, one also must make sure the routing towards that subnet is > the onlink's /48, and not the SLAAC's /64. Implementation specifics (whether it's implemented as a "route") aside, an RFC4861-compliant host implementation should already do so. > Lacking of saying so leads to the undesirable situation of operators > allocating a /64 for a ptp link. > > To combine the two, a recommendation would be: > > "The onlink|SLAAC dichotomy may be applied only if the routing towards > that subnet uses the shortest plen of the two; that could be a value > less than 64." (Aside from whether this makes sense or not) again, there's no recommendation in this draft. It only explains what current protocol specifications state, just more explicitly. -- JINMEI, Tatuya From nobody Tue Mar 14 19:47:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE212940C; Tue, 14 Mar 2017 19:47:20 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iCELpv5bVM0E; Tue, 14 Mar 2017 19:47:18 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF25129452; Tue, 14 Mar 2017 19:47:18 -0700 (PDT) X-AuditID: c618062d-d73ff700000009d8-3d-58c8bc457bc5 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by (Symantec Mail Security) with SMTP id C6.AE.02520.54CB8C85; Wed, 15 Mar 2017 05:00:05 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 22:47:10 -0400 From: Suresh Krishnan To: "ietf@ietf.org" , 6man WG CC: "draft-ietf-6man-rfc2460bis.all@ietf.org" Subject: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvg== Date: Wed, 15 Mar 2017 02:47:06 +0000 Message-ID: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_935C0C0C-E7E4-489E-B3E7-4CA2A452A3C8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLonXNd1z4kIg8f/9C1evb3GZvFs43wW i5dn3zM5MHssWfKTKYAxissmJTUnsyy1SN8ugStj172fbAVLXSpWnVzA2sB40K6LkZNDQsBE 4siht8wgtpDAekaJvi9FXYxcQPZyIHvHLFaQBBtQ0Yadn5lAbBEBG4mZu3rB4swCkRInHi5g A7GFBVwknu7dwQZR4ymxbuNhFghbT6Lj8RawOIuAqsSS9y1AvRwcvAL2Ek9PhIGEGQXEJL6f WsMEMVJc4taT+UwQt4lIPLx4mg3CFpV4+fgfK4StJPHx93x2kDuZBaYwSkzvXwn2AK+AoMTJ mU9YJjAKzUIyaxayullI6iCKtCWWLXwNFOcAsnUkJi9khAibSrw++hHKtpaY8esgG4StKDGl +yH7AkaOVYwcpcUFObnpRgabGIFRckyCTXcH4/3pnocYBTgYlXh4C1hPRAixJpYVV+YeYlQB an20YfUFRimWvPy8VCUR3jsLgdK8KYmVValF+fFFpTmpxYcYpTlYlMR541bfDxcSSE8sSc1O TS1ILYLJMnFwSjUwSvk3inxzNin2P5T0Of7qwgVCQkejCm+pH3I5VRiQvefVB0mrPR8aKpa3 MS+asaT7dOGTlfvWsyZl33tTcnTRqocalktm63F79KyZdFX9V9u5Mt8WBp2mHNUfa18zbf74 5c+6BJvdwbXTvbM+zRcr6ypqK/I4+O5kjZif1U1/ZpYlsU6n+xIWKLEUZyQaajEXFScCACc/ ShSaAgAA Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 02:47:20 -0000 --Apple-Mail=_935C0C0C-E7E4-489E-B3E7-4CA2A452A3C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks to everyone who commented during the IETF Last Call of = draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this = draft was mainly focused around the text in Section 4 that discusses the = handling of extension headers. The biggest concern raised was that the = current text is ambiguous on whether header insertion is allowed on = intermediate nodes or not. There were some people arguing that an = explicit prohibition is not necessary as the text is already clear, = while others believed that explicitly listing the prohibitions will = minimize any misunderstandings in the future. There was also a small = number of people who wanted to explicitly allow header insertion and = describe how to do it, but this was clearly out of scope for this draft = (but may be in scope for future work in 6man). Overall, no one argued = against the fact that the intent of the text in RFC2460 was to forbid = insertion of extension headers on any other node but the source of the = packet. The only argument made against adding clarifying text was that = the text was already clear. Given this, I believe there is consensus to = add explicit text about header insertion into the draft before it = progresses further. I have discussed this with the editor and the = document shepherd and would like to propose the following text change. OLD (from -08): The insertion of Extension Headers by any node other than the source of the packet causes serious problems. Two examples include breaking the integrity checks provided by the Authentication Header Integrity [RFC4302], and breaking Path MTU Discovery which can result in ICMP error messages being sent to the source of the packet that did not insert the header, rather than the node that inserted the header. One approach to avoid these problems is to encapsulate the packet using another IPv6 header and including the additional extension header after the first IPv6 header, for example, as defined in [RFC2473] With one exception, extension headers are not processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header... NEW: With one exception, extension headers are not examined, processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header... Please feel free to comment either privately or on list if you have any = concerns with this resolution going forward. Regards Suresh P.S.: There were also other editorial issues that were raised during = last call and they should be addressed in the next version of the draft= --Apple-Mail=_935C0C0C-E7E4-489E-B3E7-4CA2A452A3C8 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzE1MDI0NzA4WjAjBgkqhkiG9w0B CQQxFgQUAv2xWnWCZyHpTgpC7rM83TaGStwwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQCG9kLryOY3qXOX8wMx4FfU0lf2qFws1K8CZWsjojirzod1gUWCvtjPBOeSxqO+ WZFZzaa2oY5nVohLInFcZwVJnIrTPU0WmpeQYd3uivKHsHCg+t2osW90z7oLSytPIeS15nuooZ5W Yr8KTLU4p1qRacwJJ2nFp1HXPoLZDE5zd+ghymG5Au5Egb1z4QZA5ujy6uiMAsMmFODrVSPbiGh2 HaOK/euui4aoevexquNXA1ben5SNq0gyy1eySnTJbWn0G262Q4NGbaOOSOirpYBEYep62s+Selh+ iWeCgii4xfmKmHAobJS6zcU1PnyTe2uE7nY/RqriKwWRDcxkOhipAAAAAAAA --Apple-Mail=_935C0C0C-E7E4-489E-B3E7-4CA2A452A3C8-- From nobody Wed Mar 15 07:58:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3611315E9 for ; Wed, 15 Mar 2017 07:58:09 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 S0R4x8HXoDCL for ; Wed, 15 Mar 2017 07:58:07 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A921315DB for <6man@ietf.org>; Wed, 15 Mar 2017 07:58:06 -0700 (PDT) Received: from [192.168.0.34] (71-82-231-201.fibertel.com.ar [201.231.82.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E63F780544; Wed, 15 Mar 2017 15:58:02 +0100 (CET) Subject: "Recommendation on Temporary IPv6 Interface Identifiers" (revised I-D) (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-01.txt) References: <148942937853.9227.2944252822855237301.idtracker@ietfa.amsl.com> Cc: draft-gont-6man-non-stable-iids@tools.ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 To: "6man@ietf.org" <6man@ietf.org> X-Forwarded-Message-Id: <148942937853.9227.2944252822855237301.idtracker@ietfa.amsl.com> Message-ID: Date: Wed, 15 Mar 2017 11:57:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148942937853.9227.2944252822855237301.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 14:58:09 -0000 Folks, We have posted a rev of our I-D "Recommendation on Temporary IPv6 Interface Identifiers". It's available here: You're feedback is welcome. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-6man-non-stable-iids-01.txt Date: Mon, 13 Mar 2017 11:22:58 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Madeleine Garcia Corbo , Christian Huitema , Madelen Corbo , Guillermo Gont A new version of I-D, draft-gont-6man-non-stable-iids-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-6man-non-stable-iids Revision: 01 Title: Recommendation on Temporary IPv6 Interface Identifiers Document date: 2017-03-13 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-gont-6man-non-stable-iids-01.txt Status: https://datatracker.ietf.org/doc/draft-gont-6man-non-stable-iids/ Htmlized: https://tools.ietf.org/html/draft-gont-6man-non-stable-iids-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-6man-non-stable-iids-01 Abstract: This document clarifies the stability requirements for IPv6 addresses, and provides recommendations regarding the generation of Temporary addresses. Finally, it formally updates RFC4941 such that nodes are allowed to configure only temporary addresses. 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 From nobody Wed Mar 15 08:01:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A481315FB for ; Wed, 15 Mar 2017 08:00:59 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 70hrzCU-rrIg for ; Wed, 15 Mar 2017 08:00:56 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB77F131604 for <6man@ietf.org>; Wed, 15 Mar 2017 08:00:55 -0700 (PDT) Received: from [192.168.0.34] (71-82-231-201.fibertel.com.ar [201.231.82.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5D95E80544; Wed, 15 Mar 2017 16:00:53 +0100 (CET) Subject: IPv6 Address Usage Recommendations (revised I-D, Fwd: New Version Notification for draft-gont-6man-address-usage-recommendations-02.txt) References: <148944356914.20433.4232955187735083255.idtracker@ietfa.amsl.com> Cc: draft-gont-6man-address-usage-recommendations@tools.ietf.org To: "6man@ietf.org" <6man@ietf.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <148944356914.20433.4232955187735083255.idtracker@ietfa.amsl.com> Message-ID: <258547d4-eb2a-2257-b1a8-d37afcc2abd3@si6networks.com> Date: Wed, 15 Mar 2017 12:00:45 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148944356914.20433.4232955187735083255.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:00:59 -0000 Folks, We've posted a rev of our I-D "IPv6 Address Usage Recommendations". It is available at: This one is closely related to draft-gont-6man-non-stable-iids and to (the recently published) RFC8064. Your feedback will be highly appreciated. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-6man-address-usage-recommendations-02.txt Date: Mon, 13 Mar 2017 15:19:29 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Madeleine Garcia Corbo , Christian Huitema , Madelen Corbo , Guillermo Gont A new version of I-D, draft-gont-6man-address-usage-recommendations-02.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-6man-address-usage-recommendations Revision: 02 Title: IPv6 Address Usage Recommendations Document date: 2017-03-13 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-gont-6man-address-usage-recommendations-02.txt Status: https://datatracker.ietf.org/doc/draft-gont-6man-address-usage-recommendations/ Htmlized: https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-6man-address-usage-recommendations-02 Abstract: This document analyzes the security and privacy implications of IPv6 addresses based on a number of properties such as address scope, stability, and usage type. It analyzes what properties are desirable for some popular scenarios, and provides advice regarding the configuration and usage of such addresses. 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 From nobody Wed Mar 15 08:55:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78AE1316A8; Wed, 15 Mar 2017 08:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 oUd8llH42SHy; Wed, 15 Mar 2017 08:55:09 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A0F1315AE; Wed, 15 Mar 2017 08:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8814; q=dns/txt; s=iport; t=1489593309; x=1490802909; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yIRAFpwkzabIqarhAmkAHQUnNJ+vI6HfxkGQaS2uQgY=; b=NjVvPyec0FzTR3thk3OrIf9apDX2k3hu4XRXYDUZoJYYZaw8H/VkeCPB SS0Q+fWT7f0AAraw0xHxSnPqe85RUv1zaSIxTsDVbXw9sqR9PwhvLUqXK K3ryf2J302CFrA1jP9fzAOMPO3WYa/HYJsFD3kXyNo3M4nkUW4l0AsyXC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAgCoY8lY/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgycqYYEKB4NZig2RNx+VPIIOHwuFeAIaglQ/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBASEROgsFCwIBCBgCAhEVAgICJQsVEAIEDgWJeAgOriyCJopfA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VDggUIgmKEVD+CRy6CMQWJG5MoAYo?= =?us-ascii?q?diB2Be4UligWTRgEfOIEEWBVBEQGERR2BY3WIJYENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,169,1486425600"; d="scan'208";a="398503292" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2017 15:55:01 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2FFt16h030618 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Mar 2017 15:55:01 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Mar 2017 11:55:00 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 15 Mar 2017 11:55:00 -0400 From: "Stefano Previdi (sprevidi)" To: Suresh Krishnan CC: "ietf@ietf.org" , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Index: AQHSnaSAxRLtjcu1EUaNXmYCyEu8gw== Date: Wed, 15 Mar 2017 15:55:00 +0000 Message-ID: <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> In-Reply-To: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.226.30] Content-Type: text/plain; charset="utf-8" Content-ID: <1D37C893B235B34F801F8198029EAA03@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:55:12 -0000 U3VyZXNoLA0KDQpJIGFwcHJlY2lhdGUgeW91ciBlZmZvcnQgYW5kIEnigJltIG9idmlvdXNseSBp bnRlcmVzdGVkIGludG8gZmluZGluZyBhIHdheSBvdXQgZnJvbSB0aGlzIGlzc3VlLg0KDQpUbyBt eSB2aWV3LCBkdWUgdG8gdGhlIHdvcmsgdGhhdCBoYXMgYmVlbiBpbml0aWF0ZWQgaW4gZHJhdC1p ZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBhbmQgcmVjZW50bHkgaW4gZHJhZnQtZmls c2ZpbHMtc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLCB0aGUgY3VycmVudCB0ZXh0IG9mIFJGQzI0 NjAgKGkuZS4sIG5vdCB0aGUg4oCcYmlz4oCdIHZlcnNpb24pIGlzIGdvb2QgZW5vdWdoLg0KDQpS RkMyNDYwIHNlY3Rpb24gNCBzdGF0ZXM6DQoNCiAgIFdpdGggb25lIGV4Y2VwdGlvbiwgZXh0ZW5z aW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCBvciBwcm9jZXNzZWQNCiAgIGJ5IGFueSBub2Rl IGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwgdW50aWwgdGhlIHBhY2tldCByZWFjaGVz DQogICB0aGUgbm9kZSAob3IgZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbiB0aGUgY2FzZSBv ZiBtdWx0aWNhc3QpDQogICBpZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZp ZWxkIG9mIHRoZSBJUHY2IGhlYWRlci4NCg0KTm93LCBSRkMyNDYwIGhhcyBiZWVuIHdyaXR0ZW4g YWxtb3N0IDIwIHllYXJzIGFnbyBhbmQgc2luY2UgdGhlbiwgYm90aCB0ZWNobm9sb2d5IGFuZCBu ZXR3b3JrIG9wZXJhdG9ycyByZXF1aXJlbWVudHMgaGF2ZSBldm9sdmVkLg0KDQpXZSBkbyBoYXZl IHRvZGF5IHVzZSBjYXNlcyB3aGVyZSBub3Qgb25seSB0aGUgc291cmNlIG9mIGEgcGFja2V0IHNo b3VsZCBiZSBhbGxvd2VkIHRvIGluc2VydCBhIGhlYWRlciBidXQgYWxzbyB0aGUgc291cmNlIOKA nGRvbWFpbuKAnSBvZiBhIHBhY2tldC4gSeKAmWxsIHRyeSB0byBleHBsYWluLg0KDQpJbiBhIGRv bWFpbiBjb250cm9sbGVkIGJ5IGEgc2luZ2xlIG9yZ2FuaXphdGlvbiAodHlwaWNhbGx5IHRoZSBz ZXQgb2YgQVNzIHVuZGVyIGNvbnRyb2wgb2YgdGhlIHNhbWUgb3BlcmF0b3IpIGEgcGFja2V0IGVu dGVycyBhdCB0aGUgZWRnZSB3aGVyZSB0aGUgaW5ncmVzcyBub2RlIGFwcGxpZXMgYSBwb2xpY3kg cmVzdWx0ZWQgaW50byBhbiBhZGRpdGlvbmFsIG91dGVyIGlwdjYgaGVhZGVyIHRoYXQgbWF5IG9y IG1heSBub3QgY29udGFpbiBhbiBleHRlbnNpb24gaGVhZGVyLiBCb3R0b20gbGluZSwgdGhlIG91 dGVyIGhlYWRlciBtZWFucyB0aGF0IG5vdywgaXQgaXMgYSBORVcgcGFja2V0LCBvcmlnaW5hdGVk IGJ5IHRoZSBpbmdyZXNzIG5vZGUsIHdpdGggU0EvREEgcmVwcmVzZW50aW5nIHRoZSBub2RlcyB0 aGF0IGFyZSBpbnNpZGUgdGhlIG9wZXJhdG9yIGRvbWFpbi4gVGhlcmVmb3JlLCB3ZSBjYW4gc2F5 IHRoYXQgdGhpcyBuZXcgcGFja2V0IChmb3JtZWQgYnkgYW4gb3V0ZXIgaGVhZGVyIGFuZCBlbmNh cHN1bGF0ZWQgb3JpZ2luYWwgcGFja2V0KSBpcyBub3cgb3duZWQgYnkgdGhlIG9wZXJhdG9yIGFu ZCB3aGF0ZXZlciB0aGUgb3BlcmF0b3IgZG9lcyB3aXRoIHRoaXMgcGFja2V0Og0KDQouIFRoZSBw YWNrZXQgTVVTVCBsZWF2ZSB0aGUgb3BlcmF0b3IgbmV0d29yayBpbiB0aGUgZXhhY3Qgc2FtZSBz aGFwZS9mb3JtYXQgYXMgaXQgZW50ZXJlZCAoaS5lLjogb3V0ZXIgZW5jYXBzdWxhdGlvbiByZW1v dmVkKS4NCi4gVGhlIG91dGVyIGhlYWRlciBNQVkgY2hhbmdlIHdoaWxlIGluIHRyYW5zaXQgaW4g dGhlIG9wZXJhdG9y4oCZcyBkb21haW4uIE1vcmVvdmVyLCBhIGhlYWRlciBNQVkgYmUgaW5zZXJ0 ZWQgd2hpbGUgaW5zaWRlIHRoZSBvcGVyYXRvcuKAmXMgZG9tYWluIChrbm93aW5nIHRoYXQgb3V0 ZXIgaGVhZGVyIGFuZCBhbnkgb3RoZXIgaW5zZXJ0ZWQgaGVhZGVyIHdvdWxkIGJlIHJlbW92ZWQg YXQgZWdyZXNzKS4gVGhpcyBtZWFucyB0aGF0IGFuIFNSSCBNQVkgYmUgaW5zZXJ0ZWQgYXQgdGhl IHNhbWUgdGltZSB0aGUgb3V0ZXIgaGVhZGVyIGlzIGFkZGVkIGJ1dCBpdCBjYW4gYWxzbyBiZSB0 aGF0IHRoZSBpbmdyZXNzIGFkZHMgdGhlIG91dGVyIGhlYWRlciBhbmQgc29tZSBvdGhlciBub2Rl IGluc2VydHMgYW4gU1JIIChlLmcuOiBmYXN0IHJlcm91dGUgd2l0aGluIG9wZXJhdG9y4oCZcyBp bmZyYXN0cnVjdHVyZSkuDQouIFdoaWxlIGluIHRyYW5zaXQsIHRoZSBvcGVyYXRvciBuZXR3b3Jr IG11c3QgaGFuZGxlIGFzcGVjdHMgbGlrZSBNVFUgcHJvcGVybHksIHRha2luZyBpbnRvIGFjY291 bnQgdGhlIGluY3JlYXNlZCBzaXplIG9mIHRoZSBwYWNrZXQuDQoNClNvLCB0aGlzIHVzZSBjYXNl IGVubGFyZ2UgdGhlIHJ1bGUgZm9yIGhlYWRlciBpbnNlcnRpb24uDQoNCk9yaWdpbmFsbHkgUkZD MjQ2MCBzdGF0ZWQgdGhhdCBvbmx5IHRoZSBzb3VyY2Ugb2YgdGhlIHBhY2tldCBpcyBlbnRpdGxl ZCB0byBhZGQgYW4gRUguIE5vdyB3ZeKAmXJlIGdvaW5nIHRvIHByb3Bvc2UgdGhhdCB0aGUgc291 cmNlIOKAnGRvbWFpbuKAnSBvZiB0aGUgcGFja2V0IGlzIGFsbG93ZWQgdG8gaW5zZXJ0IEVIcy4g VGhlIHNvdXJjZSBkb21haW4gYmVpbmcgdGhlIHNldCBvZiBub2RlcyAoaW5jbHVkaW5nIHRoZSBp bmdyZXNzIG5vZGUgYWRkaW5nIHRoZSBvdXRlciBoZWFkZXIpIHVuZGVyIGNvbW1vbiBhZG1pbmlz dHJhdGlvbi4gVGhpcyBhbHNvIGltcGxpZXMgdGhhdCB3aGVuIHRoZSBwYWNrZXQgbGVhdmVzIHRo ZSBkb21haW4sIGl0IG11c3QgcmVjb3ZlciBpdHMgb3JpZ2luYWwgZm9ybWF0L3NoYXBlLg0KDQpJ biBvcmRlciB0byBoYXZlIGEgbW9yZSBwcm9kdWN0aXZlIGRpc2N1c3Npb24sIHdlIGFyZSB3cml0 aW5nIGEgZHJhZnQgb24gaGVhZGVyIGluc2VydGlvbiB0aGF0IHdpbGwgYmUgc3VibWl0dGVkIGFz IHNvb24gYXMgdGhlIHdpbmRvd3MgcmUtb3BlbiAoZHVyaW5nIGlldGYgd2VlaykuDQoNCkluIHRo ZSBtZWFuIHRpbWUsIEkgdGhpbmsgaXQgaXMgd2F5IHRvbyBwcmVtYXR1cmUgdG8gY29tZSB0byBj b25jbHVzaW9uIG9uIHdoYXQgdGV4dCBzaG91bGQgYmUgdXNlZCBmb3IgUkZDMjQ2MGJpcyBhbmQg SSByZWNvbW1lbmQgdGhhdCB0aGUgY3VycmVudCB0ZXh0IGlzIGxlZnQgdW5jaGFuZ2VkIHVudGls IHdlIGZpZ3VyZWQgb3V0IHdoYXQgdG8gZG8gd2l0aCBFSCBpbnNlcnRpb24uDQoNClRoYW5rcy4N CnMuDQoNCg0KPiBPbiBNYXIgMTUsIDIwMTcsIGF0IDM6NDcgQU0sIFN1cmVzaCBLcmlzaG5hbiA8 c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGFua3MgdG8gZXZl cnlvbmUgd2hvIGNvbW1lbnRlZCBkdXJpbmcgdGhlIElFVEYgTGFzdCBDYWxsIG9mIGRyYWZ0LWll dGYtNm1hbi1yZmMyNDYwYmlzLTA4LiBUaGUgSUVURiBsYXN0IGNhbGwgZGlzY3Vzc2lvbiBmb3Ig dGhpcyBkcmFmdCB3YXMgbWFpbmx5IGZvY3VzZWQgYXJvdW5kIHRoZSB0ZXh0IGluIFNlY3Rpb24g NCB0aGF0IGRpc2N1c3NlcyB0aGUgaGFuZGxpbmcgb2YgZXh0ZW5zaW9uIGhlYWRlcnMuIFRoZSBi aWdnZXN0IGNvbmNlcm4gcmFpc2VkIHdhcyB0aGF0IHRoZSBjdXJyZW50IHRleHQgaXMgYW1iaWd1 b3VzIG9uIHdoZXRoZXIgaGVhZGVyIGluc2VydGlvbiBpcyBhbGxvd2VkIG9uIGludGVybWVkaWF0 ZSBub2RlcyBvciBub3QuIFRoZXJlIHdlcmUgc29tZSBwZW9wbGUgYXJndWluZyB0aGF0IGFuIGV4 cGxpY2l0IHByb2hpYml0aW9uIGlzIG5vdCBuZWNlc3NhcnkgYXMgdGhlIHRleHQgaXMgYWxyZWFk eSBjbGVhciwgd2hpbGUgb3RoZXJzIGJlbGlldmVkIHRoYXQgZXhwbGljaXRseSBsaXN0aW5nIHRo ZSBwcm9oaWJpdGlvbnMgd2lsbCBtaW5pbWl6ZSBhbnkgbWlzdW5kZXJzdGFuZGluZ3MgaW4gdGhl IGZ1dHVyZS4gVGhlcmUgd2FzIGFsc28gYSBzbWFsbCBudW1iZXIgb2YgcGVvcGxlIHdobyB3YW50 ZWQgdG8gZXhwbGljaXRseSBhbGxvdyBoZWFkZXIgaW5zZXJ0aW9uIGFuZCBkZXNjcmliZSBob3cg dG8gZG8gaXQsIGJ1dCB0aGlzIHdhcyBjbGVhcmx5IG91dCBvZiBzY29wZSBmb3IgdGhpcyBkcmFm dCAoYnV0IG1heSBiZSBpbiBzY29wZSBmb3IgZnV0dXJlIHdvcmsgaW4gNm1hbikuIE92ZXJhbGws IG5vIG9uZSBhcmd1ZWQgYWdhaW5zdCB0aGUgZmFjdCB0aGF0IHRoZSBpbnRlbnQgb2YgdGhlIHRl eHQgaW4gUkZDMjQ2MCB3YXMgdG8gZm9yYmlkIGluc2VydGlvbiBvZiBleHRlbnNpb24gaGVhZGVy cyBvbiBhbnkgb3RoZXIgbm9kZSBidXQgdGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0LiAgVGhlIG9u bHkgYXJndW1lbnQgbWFkZSBhZ2FpbnN0IGFkZGluZyBjbGFyaWZ5aW5nIHRleHQgd2FzIHRoYXQg dGhlIHRleHQgd2FzIGFscmVhZHkgY2xlYXIuIEdpdmVuIHRoaXMsIEkgYmVsaWV2ZSB0aGVyZSBp cyBjb25zZW5zdXMgdG8gYWRkIGV4cGxpY2l0IHRleHQgYWJvdXQgaGVhZGVyIGluc2VydGlvbiBp bnRvIHRoZSBkcmFmdCBiZWZvcmUgaXQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBJIGhhdmUgZGlzY3Vz c2VkIHRoaXMgd2l0aCB0aGUgZWRpdG9yIGFuZCB0aGUgZG9jdW1lbnQgc2hlcGhlcmQgYW5kIHdv dWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRleHQgY2hhbmdlLg0KPiANCj4gT0xE IChmcm9tIC0wOCk6DQo+IA0KPiBUaGUgaW5zZXJ0aW9uIG9mIEV4dGVuc2lvbiBIZWFkZXJzIGJ5 IGFueSBub2RlIG90aGVyIHRoYW4gdGhlIHNvdXJjZQ0KPiBvZiB0aGUgcGFja2V0IGNhdXNlcyBz ZXJpb3VzIHByb2JsZW1zLiAgVHdvIGV4YW1wbGVzIGluY2x1ZGUgYnJlYWtpbmcNCj4gdGhlIGlu dGVncml0eSBjaGVja3MgcHJvdmlkZWQgYnkgdGhlIEF1dGhlbnRpY2F0aW9uIEhlYWRlciBJbnRl Z3JpdHkNCj4gW1JGQzQzMDJdLCBhbmQgYnJlYWtpbmcgUGF0aCBNVFUgRGlzY292ZXJ5IHdoaWNo IGNhbiByZXN1bHQgaW4gSUNNUA0KPiBlcnJvciBtZXNzYWdlcyBiZWluZyBzZW50IHRvIHRoZSBz b3VyY2Ugb2YgdGhlIHBhY2tldCB0aGF0IGRpZCBub3QNCj4gaW5zZXJ0IHRoZSBoZWFkZXIsIHJh dGhlciB0aGFuIHRoZSBub2RlIHRoYXQgaW5zZXJ0ZWQgdGhlIGhlYWRlci4NCj4gDQo+IE9uZSBh cHByb2FjaCB0byBhdm9pZCB0aGVzZSBwcm9ibGVtcyBpcyB0byBlbmNhcHN1bGF0ZSB0aGUgcGFj a2V0DQo+IHVzaW5nIGFub3RoZXIgSVB2NiBoZWFkZXIgYW5kIGluY2x1ZGluZyB0aGUgYWRkaXRp b25hbCBleHRlbnNpb24NCj4gaGVhZGVyIGFmdGVyIHRoZSBmaXJzdCBJUHY2IGhlYWRlciwgZm9y IGV4YW1wbGUsIGFzIGRlZmluZWQgaW4NCj4gW1JGQzI0NzNdDQo+IA0KPiBXaXRoIG9uZSBleGNl cHRpb24sIGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBub3QgcHJvY2Vzc2VkIGJ5IGFueSBub2RlDQo+ IGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwgdW50aWwgdGhlIHBhY2tldCByZWFjaGVz IHRoZSBub2RlIChvcg0KPiBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluIHRoZSBjYXNlIG9m IG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUNCj4gRGVzdGluYXRpb24gQWRkcmVzcyBmaWVs ZCBvZiB0aGUgSVB2NiBoZWFkZXIuLi4NCj4gDQo+IE5FVzoNCj4gDQo+IFdpdGggb25lIGV4Y2Vw dGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCwgcHJvY2Vzc2VkLA0KPiBp bnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5 IHBhdGgsDQo+IHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3IgZWFjaCBvZiB0 aGUgc2V0IG9mIG5vZGVzLCBpbg0KPiB0aGUgY2FzZSBvZiBtdWx0aWNhc3QpIGlkZW50aWZpZWQg aW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YNCj4gdGhlIElQdjYgaGVhZGVyLi4u DQo+IA0KPiBQbGVhc2UgZmVlbCBmcmVlIHRvIGNvbW1lbnQgZWl0aGVyIHByaXZhdGVseSBvciBv biBsaXN0IGlmIHlvdSBoYXZlIGFueSBjb25jZXJucyB3aXRoIHRoaXMgcmVzb2x1dGlvbiBnb2lu ZyBmb3J3YXJkLg0KPiANCj4gUmVnYXJkcw0KPiBTdXJlc2gNCj4gDQo+IFAuUy46IFRoZXJlIHdl cmUgYWxzbyBvdGhlciBlZGl0b3JpYWwgaXNzdWVzIHRoYXQgd2VyZSByYWlzZWQgZHVyaW5nIGxh c3QgY2FsbCBhbmQgdGhleSBzaG91bGQgYmUgYWRkcmVzc2VkIGluIHRoZSBuZXh0IHZlcnNpb24g b2YgdGhlIGRyYWZ0LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGlu ZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= From nobody Wed Mar 15 09:17:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8392D1316EF; Wed, 15 Mar 2017 09:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Sy2-BJG3Vi0S; Wed, 15 Mar 2017 09:16:55 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF221316DF; Wed, 15 Mar 2017 09:16:55 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id f103so3438980ioi.2; Wed, 15 Mar 2017 09:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=k8AKD/ic+Z/Rl8U0gVP1nnucq5l9rr2MKlSwGfLTsH0=; b=L+02JaxDGNwyTEPtAR5YJGlcwEjNeOq4F7lKI9CtiT7RYy2DhPHqT4YEAevKybq5Qm SeCGmHCBc5xEcjBoA0o9fm328dHfqw1m/rVD8c4A+7CnCUrkhVn596GneTgp8X0KNcpT 2VoHHz2yRCCQD8KXWiAVBkWKemvRy7rDxqYoDqSgCRiO8bOjcqQMZMcHVnyMpMN7Jd5K QmGZxWSAP/r0W61PQavrb2Iu/j4fWLGjldUpcDclaMw11I4RoPq/HGANwa+9Pj7h09KX eToOr6CxnQxgjKiIE+oDsQ0+mPFM0jEhclR2eK7OdXXRXIBMcNWZqiwCbFWZqpeccDdn IAjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=k8AKD/ic+Z/Rl8U0gVP1nnucq5l9rr2MKlSwGfLTsH0=; b=uTPRur52hE548gI8sQDVfBREdDprAfK6hJFaKBZlfeM9YjbfbgpyYxU5jSBchuyzMA NP+BfrYOPcjD/gznTEHr4xTYTAAgmhAKDKvnrRqtu9i7F7W5IxmmolIfxGmL6iNbUx/5 C0/M77NBoj/IlPEJSPk7q7PwgxwLX04+lQLtwcNu8PkKDM91ceDeqXsGY9FQ9q3xM6Kf 01SR09JKeBOFoBdej4s5cSOPcrnOSUFneg6urJ1dJSeio9T5vDUFgAu6j7U6MNdDaZSY ocOITb+RiKbaRUck2tkO12qCLIpFFyi3b/412Zx8WS2VhgOrjgmD+3hEf/bClZxAVWzg VXag== X-Gm-Message-State: AFeK/H3k+w0jZccnlMXkvqq3+FsKpY5p7DWI3VJ1bkRrPRCFivSaNuXuFl54+bhmED+zLw== X-Received: by 10.107.135.136 with SMTP id r8mr5728744ioi.36.1489594609564; Wed, 15 Mar 2017 09:16:49 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id b126sm1666577ioa.55.2017.03.15.09.16.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 09:16:49 -0700 (PDT) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: "Stefano Previdi (sprevidi)" References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> Cc: Suresh Krishnan , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" From: Brian E Carpenter Organization: University of Auckland Message-ID: <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> Date: Thu, 16 Mar 2017 05:16:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:16:57 -0000 Stefano, On 16/03/2017 04:55, Stefano Previdi (sprevidi) wrote: ... > In the mean time, I think it is way too premature to come to conclusion on what text should be used for RFC2460bis and I recommend that the current text is left unchanged until we figured out what to do with EH insertion. I believe that we have figured it out: extension header insertion is harmful to Internet interoperability. I fully agree with Suresh's understanding of the rough consensus. Brian From nobody Wed Mar 15 09:23:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5C71316F5 for ; Wed, 15 Mar 2017 09:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 hd0TVy-_0Xqz for ; Wed, 15 Mar 2017 09:23:03 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9471316D6 for ; Wed, 15 Mar 2017 09:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1489594981; bh=o6YtjseSoo95+W9dh710zYYYwlt7CAxZ8M4C/3JBMoA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=I/PZxR/49dqdn51eHNMqF+dIv2eOX0OjWehaA/Cxs+in6/jT67oUbc6Lfljj/sGV+4fBRB0A1HMedwY4Z4fHNwctyVSv4g1Rrhhypkenx4OSx1l3xkJ6BgQBpFsciJ7Dy1JXpJMFJ1q0jO7j3EMdlGbTnsEzYJlDzcHfQCbjvTA= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0184.outbound.protection.outlook.com [213.199.180.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-99-63W5PtfBMreF5JfEyzGsNQ-1; Wed, 15 Mar 2017 16:21:36 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 16:21:34 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0977.010; Wed, 15 Mar 2017 16:21:34 +0000 From: Tim Chown To: Brian E Carpenter CC: "Stefano Previdi (sprevidi)" , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "Suresh Krishnan" , "ietf@ietf.org" Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGWDpMAgAAGIICAAAFLgA== Date: Wed, 15 Mar 2017 16:21:34 +0000 Message-ID: <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> In-Reply-To: <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:2IW+zL5ZcNcooPBquPK05yQrSXMjt4XyZoQ8MLfkMu+O57L1RHH7A0SW8toSxVkb6BviJ+khxXsP+frLcDaDsfCBGR1ZqKN1Mx1e72KqN/4LVPB6IL9BCi583l1IrR5WoUC25K/3blG3HSqjdFtMyAhiqyDBMVcEEtRK0x3Z2szbT4wHIRR+CvDkg9uMbBx0eKMyEhFgLTVUwBIUFVxJrGjJn38wG2h/AxCmMTBNsju/OWOObX0fa7iemVKZ2xxCkEGmKKiNjh23HxelriO8iahTedCPasf27TOjx9T4LScdLt1XLKn688c6+yu0j654j9fnajXaayeZVzLEEAT89Q==; 20:XC9fMcbLLLEvhozQPQruaGBja7QpomRZub1P/h0PZebSDew0NTBqmkKLhjwKGGiOba8kqKE1kzP/KuuQq3cdYHWikRTJG9Ozw0FPOVGVEdv29BBPkyzUDLH6gYMdIdXL79iZ1tFpA0rId1YA9FCUGirmJ+afysYd2xr/c4Mya8I= x-ms-office365-filtering-correlation-id: 38f7abdc-7212-42b3-1ac6-08d46bbf5914 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254022); SRVR:AM3PR07MB1138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(6246003)(74482002)(6512007)(33656002)(230783001)(99286003)(86362001)(76176999)(4326008)(53936002)(39060400002)(110136004)(38730400002)(2900100001)(229853002)(2906002)(7736002)(54906002)(50986999)(6486002)(6506006)(5250100002)(189998001)(3660700001)(42882006)(6436002)(3280700002)(66066001)(82746002)(2950100002)(83716003)(5660300001)(36756003)(6916009)(53546007)(57306001)(81166006)(8676002)(8936002)(3846002)(102836003)(6116002)(50226002)(305945005)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 16:21:34.2276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138 X-MC-Unique: 63W5PtfBMreF5JfEyzGsNQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:23:04 -0000 SGksDQoNCj4gT24gMTUgTWFyIDIwMTcsIGF0IDE2OjE2LCBCcmlhbiBFIENhcnBlbnRlciA8YnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IFN0ZWZhbm8sDQo+IE9uIDE2 LzAzLzIwMTcgMDQ6NTUsIFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIHdyb3RlOg0KPiAuLi4N Cj4+IEluIHRoZSBtZWFuIHRpbWUsIEkgdGhpbmsgaXQgaXMgd2F5IHRvbyBwcmVtYXR1cmUgdG8g Y29tZSB0byBjb25jbHVzaW9uIG9uIHdoYXQgdGV4dCBzaG91bGQgYmUgdXNlZCBmb3IgUkZDMjQ2 MGJpcyBhbmQgSSByZWNvbW1lbmQgdGhhdCB0aGUgY3VycmVudCB0ZXh0IGlzIGxlZnQgdW5jaGFu Z2VkIHVudGlsIHdlIGZpZ3VyZWQgb3V0IHdoYXQgdG8gZG8gd2l0aCBFSCBpbnNlcnRpb24uDQo+ IA0KPiBJIGJlbGlldmUgdGhhdCB3ZSBoYXZlIGZpZ3VyZWQgaXQgb3V0OiBleHRlbnNpb24gaGVh ZGVyIGluc2VydGlvbiBpcyBoYXJtZnVsIHRvIEludGVybmV0IGludGVyb3BlcmFiaWxpdHkuDQo+ IA0KPiBJIGZ1bGx5IGFncmVlIHdpdGggU3VyZXNoJ3MgdW5kZXJzdGFuZGluZyBvZiB0aGUgcm91 Z2ggY29uc2Vuc3VzLg0KDQpJIGFsc28gYWdyZWUgd2l0aCBTdXJlc2jigJlzIGFwcHJhaXNhbC4g DQoNClRpbQ== From nobody Wed Mar 15 09:33:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27BF131710; Wed, 15 Mar 2017 09:33:37 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IJihrUvtmIRy; Wed, 15 Mar 2017 09:33:36 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A5E1316A1; Wed, 15 Mar 2017 09:33:35 -0700 (PDT) X-AuditID: 60721c4b-957ff700000006b0-02-58c96cdd6ec3 Received: from VAADCEX42.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id B7.A1.01712.DDC69C85; Wed, 15 Mar 2017 12:33:34 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX42.cable.comcast.com (147.191.103.219) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Mar 2017 12:33:32 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Wed, 15 Mar 2017 12:33:32 -0400 From: "Leddy, John" To: Tim Chown , Brian E Carpenter CC: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "Stefano Previdi (sprevidi)" , "ietf@ietf.org" Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Index: AQHSnaSAxRLtjcu1EUaNXmYCyEu8g6GWVuWAgAABTAD//8BKAA== Date: Wed, 15 Mar 2017 16:33:32 +0000 Message-ID: References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> In-Reply-To: <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.253] Content-Type: text/plain; charset="utf-8" Content-ID: <6B5658A0B408DE478EE7BA7F06511FEB@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsWSUOxpoXs/52SEwYSJTBZtF/cxWbx6e43N 4tnG+SwWL8++Z7JYv/sRk0Xfz8dsDmweU35vZPXYOesuu8eSJT+ZPFb+vsIWwBLFZZOSmpNZ llqkb5fAlbHv2hPGglVcFYfnfWFrYOzg6mLk5JAQMJHYt/kEWxcjF4eQwEwmiR/rvzJCOIcY JdpaW6AyJxklHmx4zgbSwiagIzFj2jVWEFtEIFzi8ad2ZpAiZoETjBLLJu1nB0kIC3hITNp0 jQWiyFNi3cbDULaTxOQ3+8BqWARUJVbOvwdm8wq4SNx71QNWIyRwk1Hi91oJEJtTwE5i/qdf TCA2o4CYxPdTa8BsZgFxiVtP5jNB/CAgsWTPeWYIW1Ti5eN/YMeJCuhJPLx3kxUiriNx9voT RgjbQGLr0n0sELaixL4PK4B6OYBmakqs36UPMd5B4vCPB6wQtqLElO6HUGcKSpyc+QSqVVzi 8JEdrBMYpWchuWgWwqRZSCbNQjJpFpJJCxhZVzHKlSUmpiTnZuSXlhgY6iUnJuWk6iXn5yYn FpeA6E2MoPRQJOO9g3HdT/dDjAIcjEo8vN9DTkYIsSaWFVfmAqOKg1lJhLctCyjEm5JYWZVa lB9fVJqTWnyIUZqDRUmc95LI6gghgfTEktTs1NSC1CKYLBMHp1QDoxK39Q/zFVeWhxt0L16+ 1rd+wpvCw/z/7NebrTD85VG2IJKnPXfaK7UQA67/qbUcPVvMStcvzmf5JPropLp3Jc8FYYfu TqVI98Q9/jNL2X4lue/Y+dvDfQKzr3WF6KmOUGXryQ8YYuceZ3IWnGTl1sO49qzTBK+lSoz7 eU7O9+zhivTxeOyuxFKckWioxVxUnAgA0wR6fAsDAAA= Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:33:38 -0000 RG9lcyB0aGlzIG1lYW4gdGhhdCBvbmx5IG1pZGRsZSBib3hlcywgbm90IGNvdmVyZWQgYnkgdGhl IGFyY2hpdGVjdHVyZSBjb3VsZCBpbnNlcnQgYW4gZXh0ZW5zaW9uIGhlYWRlciBmb3IgdXNlIHdp dGhpbiB0aGUgZG9tYWluPw0KDQpKb2huDQoNCk9uIDMvMTUvMTcsIDEyOjIxIFBNLCAiaWV0ZiBv biBiZWhhbGYgb2YgVGltIENob3duIiA8aWV0Zi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBUaW0uQ2hvd25AamlzYy5hYy51az4gd3JvdGU6DQoNCiAgICBIaSwNCiAgICANCiAgICA+IE9u IDE1IE1hciAyMDE3LCBhdCAxNjoxNiwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVu dGVyQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IFN0ZWZhbm8sDQogICAgPiBPbiAx Ni8wMy8yMDE3IDA0OjU1LCBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSB3cm90ZToNCiAgICA+ IC4uLg0KICAgID4+IEluIHRoZSBtZWFuIHRpbWUsIEkgdGhpbmsgaXQgaXMgd2F5IHRvbyBwcmVt YXR1cmUgdG8gY29tZSB0byBjb25jbHVzaW9uIG9uIHdoYXQgdGV4dCBzaG91bGQgYmUgdXNlZCBm b3IgUkZDMjQ2MGJpcyBhbmQgSSByZWNvbW1lbmQgdGhhdCB0aGUgY3VycmVudCB0ZXh0IGlzIGxl ZnQgdW5jaGFuZ2VkIHVudGlsIHdlIGZpZ3VyZWQgb3V0IHdoYXQgdG8gZG8gd2l0aCBFSCBpbnNl cnRpb24uDQogICAgPiANCiAgICA+IEkgYmVsaWV2ZSB0aGF0IHdlIGhhdmUgZmlndXJlZCBpdCBv dXQ6IGV4dGVuc2lvbiBoZWFkZXIgaW5zZXJ0aW9uIGlzIGhhcm1mdWwgdG8gSW50ZXJuZXQgaW50 ZXJvcGVyYWJpbGl0eS4NCiAgICA+IA0KICAgID4gSSBmdWxseSBhZ3JlZSB3aXRoIFN1cmVzaCdz IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHJvdWdoIGNvbnNlbnN1cy4NCiAgICANCiAgICBJIGFsc28g YWdyZWUgd2l0aCBTdXJlc2jigJlzIGFwcHJhaXNhbC4gDQogICAgDQogICAgVGltDQoNCg== From nobody Wed Mar 15 10:16:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C27D13172A; Wed, 15 Mar 2017 10:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CuDOGKnRKCOb; Wed, 15 Mar 2017 10:16:24 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7375131728; Wed, 15 Mar 2017 10:16:24 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 1so18521323qkl.3; Wed, 15 Mar 2017 10:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Hx+7cXVMfWsVpJoyiKAvDjfdqJ1yxC0flytf4nDJgVk=; b=RQYA61w+SPnbOd8gDM74a2DKWuqUx9myV6Sm3S2SL1Xr+JOJYCIytXK1j6E7wvemuG 8XhsPu/F0L37ogjV/NDkxqYxWCd7/ye9ogSOUcyt958varwBWQmnZ70thjmI/G7RjG5o gNAm5VhfmI7s4VC8HsSTcjR8hRxPVo0UdY1RgidJUZG6ricgBEU+a1jrmeWlddbUroxQ IWI2caD3m+i3D9M6XwWEZMYCCIFNwhFLQ5uTB1p2P/nUts3cDQ+rjxrawld9dPgGHIVK mEBU16DGlSKHtyl+RTBYZXtLiG0t7ctds3I15+MJrEY+dRiNvSu/gzFqsFs769soOkTh 4UCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=Hx+7cXVMfWsVpJoyiKAvDjfdqJ1yxC0flytf4nDJgVk=; b=bqyaCKfIweBnSCIUo1r+4ZShXyUIoC2WXvH/FiURdhyqw07cpuJPixq6UNyKBCTTm2 Fy8bvn4Kw39v+HZ4/UhEw69NDZ//YGYwDqtro6csfu+cqrDLySywO7I1hm4SXV8Wqx2j +nCcIjuNmRtDHiOnFZ8CKp5ZXiDOK5JQI8LOyTvQu6Xfjnjgd+Qw91yv8inxNt85fS7/ q82vPVWOzHjZkWmThwVLl/5oQSvcZLcnRegkPWBSwVFCyOze1V9EIpfJmQRoKBMlz6Jm ikQmllIzwBlLtYHvUQUjcFcNOKnndOoDYCksQyBY9GxYk0fI+TmJE7iqqrwYW9ZCGKsY 33Qg== X-Gm-Message-State: AFeK/H3DQzd1lUzNVDtLMNVR9QJiJygqWe9YuUWPbLnme82zBPjPGJIcoj1pQYVougk/v8Z94qcWP0CpfUpkfA== X-Received: by 10.55.146.135 with SMTP id u129mr3716542qkd.219.1489598183727; Wed, 15 Mar 2017 10:16:23 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Wed, 15 Mar 2017 10:16:23 -0700 (PDT) In-Reply-To: <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 15 Mar 2017 10:16:23 -0700 X-Google-Sender-Auth: cRRNJV4d-w5NpKk5sr53nQgZm8Q Message-ID: Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Brian E Carpenter Cc: "Stefano Previdi (sprevidi)" , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , Suresh Krishnan , "ietf@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 17:16:26 -0000 At Thu, 16 Mar 2017 05:16:55 +1300, Brian E Carpenter wrote: > > In the mean time, I think it is way too premature to come to conclusion= on what text should be used for RFC2460bis and I recommend that the curren= t text is left unchanged until we figured out what to do with EH insertion. > > I believe that we have figured it out: extension header insertion is harm= ful to Internet interoperability. > > I fully agree with Suresh's understanding of the rough consensus. I also support Suresh's proposal. BTW, At Wed, 15 Mar 2017 15:55:00 +0000, "Stefano Previdi (sprevidi)" wrote: >> Originally RFC2460 stated that only the source of the packet is >> entitled to add an EH. Now we=E2=80=99re going to propose that the sourc= e >> =E2=80=9Cdomain=E2=80=9D of the packet is allowed to insert EHs. [...] >> >> In order to have a more productive discussion, we are writing a >> draft on header insertion that will be submitted as soon as the >> windows re-open (during ietf week). IMHO this plan explains exactly why we rather need to make it more explicit in rfc2460bis that this version of spec does not assume EH to be inserted or deleted except at the source node (not "domain"). I'm totally open to the discussion of possible extensions with the concept of "source domain". But it should be fair to say it will take time, at least for months, and quite likely more than a year. If we keep the rfc2460bis text "ambiguous" in the meantime, we'll leave the risk that it's interpreted more loosely and someone develops an implementation that violates the assumption more casually. To me, it's more responsible to be more explicit in the current specification to prevent further accidental misunderstanding unless and until we have the possible revised conditions. -- JINMEI, Tatuya From nobody Wed Mar 15 10:58:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3600013175C; Wed, 15 Mar 2017 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Q4GJHgzNIybm; Wed, 15 Mar 2017 10:57:58 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EDC13175A; Wed, 15 Mar 2017 10:57:57 -0700 (PDT) Received: from [85.158.136.35] by server-5.bemta-5.messagelabs.com id 7D/D7-29481-3A089C85; Wed, 15 Mar 2017 17:57:55 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRWlGSWpSXmKPExsXi7PqsVXdxw8k Ig9X35Sxevb3GZvFs43wWi5dn3zNZrN/9iMlixpyf7A6sHlN+b2T1+PX1KpvHkiU/mQKYo1gz 85LyKxJYM6YtXsZa8E6s4vj59cwNjF+Euhg5OSQE/CR6L11j62Lk4hAS2MsoseHEGSYI5wajx PkLM1ghnNOMEuc6pgJlODjYBHQk5ryQB+kWETCVOD/jPDOIzSxwhFGi+bEHiC0s4CExadM1Fo gaT4l1Gw9D2VYSU14eZgWxWQRUJf5t/8kGMpIXKP5zgh1IWEigQGLp7LVg5ZwCthI3p3aBlTM KiEl8P7WGCWKVuMStJ/OZIB4QkFiyB+IECQFRiZeP/7FC2AYSW5fuY4GoN5B4f24+1JnaEssW vgazeQUEJU7OfMICUS8pcXDFDRaIGxQl5t16ywLx+jxGiYlb29ghiuwl/l/6wTiBUWoWkjtmI dkxC8mOWUh2LGBkWcWoUZxaVJZapGtooZdUlJmeUZKbmJmja2hgqpebWlycmJ6ak5hUrJecn7 uJERjlDECwg7Fpu+chRkkOJiVRXpXckxFCfEn5KZUZicUZ8UWlOanFhxhlODiUJHhL64FygkW p6akVaZk5wHQDk5bg4FES4bUHSfMWFyTmFmemQ6ROMSpKifOuBkkIgCQySvPg2mAp7hKjrJQw LyPQIUI8BalFuZklqPKvGMU5GJWEeUNApvBk5pXATX8FtJgJaPHbDydAFpckIqSkGhhNZROYU 1JV78450jDB7cKTSgvPrMvXF4nZ3quzbQ+10q0TO/T848GJZ/LULX7tiKuV/dDvKtG57OtPQb O9N1e9vqrjN1NpWW5FxFWR8v8tz+5P9arvCv8gcm/K0sMbvdyazTZK7pv0cOv0ytxvPfO0uaz yzpdnr5U4//ak9J2iGWYN7GaiO9cpsRRnJBpqMRcVJwIA2EU5Y2wDAAA= X-Env-Sender: daniel.voyer@bell.ca X-Msg-Ref: server-14.tower-125.messagelabs.com!1489600671!71930018!6 X-Originating-IP: [67.69.230.133] X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29394 invoked from network); 15 Mar 2017 17:57:55 -0000 Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (67.69.230.133) by server-14.tower-125.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 15 Mar 2017 17:57:55 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-WYN.bell.corp.bce.ca Received: from DG2MBX03-WYN.bell.corp.bce.ca (198.235.102.32) by EX13EDGE02-WYN.bell.corp.bce.ca (198.235.68.44) with Microsoft SMTP Server id 15.0.1210.3; Wed, 15 Mar 2017 13:57:31 -0400 Received: from DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) by DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Mar 2017 13:57:37 -0400 Received: from DG2MBX03-WYN.bell.corp.bce.ca ([fe80::c841:4444:5043:4356]) by DG2MBX03-WYN.bell.corp.bce.ca ([fe80::c841:4444:5043:4356%23]) with mapi id 15.00.1210.000; Wed, 15 Mar 2017 13:57:37 -0400 From: "Voyer, Daniel" To: "Stefano Previdi (sprevidi)" CC: Suresh Krishnan , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGWUaEA///fNVw= Date: Wed, 15 Mar 2017 17:57:37 +0000 Message-ID: References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>, <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> In-Reply-To: <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: SoftFail (EX13EDGE02-WYN.bell.corp.bce.ca: domain of transitioning daniel.voyer@bell.ca discourages use of 198.235.102.32 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE02-WYN.bell.corp.bce.ca Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 17:58:01 -0000 > We do have today use cases where not only the source of a packet should b= e allowed to insert a header but also the source =93domain=94 of a packet. = I=92ll try to explain. >=20 > In a domain controlled by a single organization (typically the set of ASs= under control of the same operator) a packet enters at the edge where the = ingress node applies a policy resulted into an additional outer ipv6 header= that may or may not contain an extension header. Bottom line, the outer he= ader means that now, it is a NEW packet, originated by the ingress node, wi= th SA/DA representing the nodes that are inside the operator domain. Theref= ore, we can say that this new packet (formed by an outer header and encapsu= lated original packet) is now owned by the operator and whatever the operat= or does with this packet: >=20 > . The packet MUST leave the operator network in the exact same shape/form= at as it entered (i.e.: outer encapsulation removed). > . The outer header MAY change while in transit in the operator=92s domain= . Moreover, a header MAY be inserted while inside the operator=92s domain (= knowing that outer header and any other inserted header would be removed at= egress). This means that an SRH MAY be inserted at the same time the outer= header is added but it can also be that the ingress adds the outer header = and some other node inserts an SRH (e.g.: fast reroute within operator=92s = infrastructure). > . While in transit, the operator network must handle aspects like MTU pro= perly, taking into account the increased size of the packet. DV: I concur with this explanation & needs. >=20 > Originally RFC2460 stated that only the source of the packet is entitled = to add an EH. Now we=92re going to propose that the source =93domain=94 of = the packet is allowed to insert EHs. The source domain being the set of nod= es (including the ingress node adding the outer header) under common admini= stration. This also implies that when the packet leaves the domain, it must= recover its original format/shape. >=20 > In order to have a more productive discussion, we are writing a draft on = header insertion that will be submitted as soon as the windows re-open (dur= ing ietf week). >=20 > In the mean time, I think it is way too premature to come to conclusion o= n what text should be used for RFC2460bis and I recommend that the current = text is left unchanged until we figured out what to do with EH insertion. DV: I support this recommendation, especially that there will be a document= submitted in 2 weeks, stated here, that will add more context. Which posit= ion the WG good discussion. > Thanks. > s. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Mar 15 11:13:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29259131775; Wed, 15 Mar 2017 11:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 yrELJmRGY_mr; Wed, 15 Mar 2017 11:13:19 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B47131773; Wed, 15 Mar 2017 11:13:18 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2FICOpe013839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Mar 2017 11:12:25 -0700 (PDT) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: "Stefano Previdi (sprevidi)" , Suresh Krishnan References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" From: Joe Touch Message-ID: <51747194-64e8-5957-167d-3132185039b3@isi.edu> Date: Wed, 15 Mar 2017 11:12:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:13:21 -0000 Stefano, Your case below falls under the "acting on behalf of the endpoint" approach, IMO. I'm comfortable with the current proposed resolution, which IMO allows for enterprises to "create" the IP header in whatever distributed system they want. The only rule is simple: that enterprise must act like a host in total, i.e., it must follow node requirements. If you do that, then nobody will care how you implement header creation. Joe On 3/15/2017 8:55 AM, Stefano Previdi (sprevidi) wrote: > Suresh, > > I appreciate your effort and I=E2=80=99m obviously interested into find= ing a way out from this issue. > > To my view, due to the work that has been initiated in drat-ietf-6man-s= egment-routing-header and recently in draft-filsfils-srv6-network-program= ming, the current text of RFC2460 (i.e., not the =E2=80=9Cbis=E2=80=9D ve= rsion) is good enough. > > RFC2460 section 4 states: > > With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches= > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header. > > Now, RFC2460 has been written almost 20 years ago and since then, both = technology and network operators requirements have evolved. > > We do have today use cases where not only the source of a packet should= be allowed to insert a header but also the source =E2=80=9Cdomain=E2=80=9D= of a packet. I=E2=80=99ll try to explain. > > In a domain controlled by a single organization (typically the set of A= Ss under control of the same operator) a packet enters at the edge where = the ingress node applies a policy resulted into an additional outer ipv6 = header that may or may not contain an extension header. Bottom line, the = outer header means that now, it is a NEW packet, originated by the ingres= s node, with SA/DA representing the nodes that are inside the operator do= main. Therefore, we can say that this new packet (formed by an outer head= er and encapsulated original packet) is now owned by the operator and wha= tever the operator does with this packet: > > . The packet MUST leave the operator network in the exact same shape/fo= rmat as it entered (i.e.: outer encapsulation removed). > . The outer header MAY change while in transit in the operator=E2=80=99= s domain. Moreover, a header MAY be inserted while inside the operator=E2= =80=99s domain (knowing that outer header and any other inserted header w= ould be removed at egress). This means that an SRH MAY be inserted at the= same time the outer header is added but it can also be that the ingress = adds the outer header and some other node inserts an SRH (e.g.: fast rero= ute within operator=E2=80=99s infrastructure). > . While in transit, the operator network must handle aspects like MTU p= roperly, taking into account the increased size of the packet. > > So, this use case enlarge the rule for header insertion. > > Originally RFC2460 stated that only the source of the packet is entitle= d to add an EH. Now we=E2=80=99re going to propose that the source =E2=80= =9Cdomain=E2=80=9D of the packet is allowed to insert EHs. The source dom= ain being the set of nodes (including the ingress node adding the outer h= eader) under common administration. This also implies that when the packe= t leaves the domain, it must recover its original format/shape. > > In order to have a more productive discussion, we are writing a draft o= n header insertion that will be submitted as soon as the windows re-open = (during ietf week). > > In the mean time, I think it is way too premature to come to conclusion= on what text should be used for RFC2460bis and I recommend that the curr= ent text is left unchanged until we figured out what to do with EH insert= ion. > > Thanks. > s. > > >> On Mar 15, 2017, at 3:47 AM, Suresh Krishnan wrote: >> >> Thanks to everyone who commented during the IETF Last Call of draft-ie= tf-6man-rfc2460bis-08. The IETF last call discussion for this draft was m= ainly focused around the text in Section 4 that discusses the handling of= extension headers. The biggest concern raised was that the current text = is ambiguous on whether header insertion is allowed on intermediate nodes= or not. There were some people arguing that an explicit prohibition is n= ot necessary as the text is already clear, while others believed that exp= licitly listing the prohibitions will minimize any misunderstandings in t= he future. There was also a small number of people who wanted to explicit= ly allow header insertion and describe how to do it, but this was clearly= out of scope for this draft (but may be in scope for future work in 6man= ). Overall, no one argued against the fact that the intent of the text in= RFC2460 was to forbid insertion of extension headers on any other node b= ut the source of the packet. The only argument made against adding clari= fying text was that the text was already clear. Given this, I believe the= re is consensus to add explicit text about header insertion into the draf= t before it progresses further. I have discussed this with the editor and= the document shepherd and would like to propose the following text chang= e. >> >> OLD (from -08): >> >> The insertion of Extension Headers by any node other than the source >> of the packet causes serious problems. Two examples include breaking >> the integrity checks provided by the Authentication Header Integrity >> [RFC4302], and breaking Path MTU Discovery which can result in ICMP >> error messages being sent to the source of the packet that did not >> insert the header, rather than the node that inserted the header. >> >> One approach to avoid these problems is to encapsulate the packet >> using another IPv6 header and including the additional extension >> header after the first IPv6 header, for example, as defined in >> [RFC2473] >> >> With one exception, extension headers are not processed by any node >> along a packet's delivery path, until the packet reaches the node (or >> each of the set of nodes, in the case of multicast) identified in the >> Destination Address field of the IPv6 header... >> >> NEW: >> >> With one exception, extension headers are not examined, processed, >> inserted, or deleted by any node along a packet's delivery path, >> until the packet reaches the node (or each of the set of nodes, in >> the case of multicast) identified in the Destination Address field of >> the IPv6 header... >> >> Please feel free to comment either privately or on list if you have an= y concerns with this resolution going forward. >> >> Regards >> Suresh >> >> P.S.: There were also other editorial issues that were raised during l= ast call and they should be addressed in the next version of the draft---= ----------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Wed Mar 15 11:14:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81E0131776; Wed, 15 Mar 2017 11:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 2aQlbJFYPRYd; Wed, 15 Mar 2017 11:14:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8B9131765; Wed, 15 Mar 2017 11:14:36 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2FIE8Pf014148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Mar 2017 11:14:10 -0700 (PDT) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: "Leddy, John" , Tim Chown , Brian E Carpenter References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" , "Stefano Previdi (sprevidi)" From: Joe Touch Message-ID: Date: Wed, 15 Mar 2017 11:14:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:14:38 -0000 On 3/15/2017 9:33 AM, Leddy, John wrote: > Does this mean that only middle boxes, not covered by the architecture could insert an extension header for use within the domain? Please see my recent post about Stefano's issue. IMO, any opaque (distributed) system that acts like a host can follow the host (node) requirements. The instant that system is not opaque or fails to act like a single host, it becomes noncompliant. Joe From nobody Wed Mar 15 11:48:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3047C1317BC; Wed, 15 Mar 2017 11:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fGsGeVsMkIQH; Wed, 15 Mar 2017 11:48:49 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44E21317B0; Wed, 15 Mar 2017 11:48:48 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id n21so19985791qta.1; Wed, 15 Mar 2017 11:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/c5YxBQESe9wUc9UE6eQAQLEXC3hZiY9BRVTZEI/R4M=; b=THKmNrvq64yi35SPzr3py67ULKdGf8P6h+1XBAT4e5xqQEREU5HmeAOntkuk39UiFW mOOkhpPk0+SvzKRo/7bZnyPHBUDnV7HZf8JLI/f0VRr7juYJmEulnzoyW7/TPuPKpB07 1tCsmORAZ0pgBMSHQo+nEoTBKrfiVvX3OZjITIRpFnpTyOdVw1yHcRlAu1asz4/cTdGL 60dccrEyjsTuC+L36v3hrX09byrVbOyF3Hyfgs/mOY9t9xUmGHO39cluIWAugPcfccjk CNYnpxYl8Y6yDhMPJdkmIv1V8rXDRik9cc4ZzPo1K3ETBtkTk71Pyl9mmYxwwBsnvJp4 SZwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/c5YxBQESe9wUc9UE6eQAQLEXC3hZiY9BRVTZEI/R4M=; b=fRTM9JHDbuOUx5S4M71lC15Aio14UZCTcbAIs6nC0LBr60D8oZ58qktAXEb1cn73JP DiIQ0F8dKqmpeRqQtIem36mtFwwXZ0fvNOVthcOHiF8wGTFDBZVuZy12TXnRtPdgIgBZ r5KY2NcBgZPhKhf5w6UJGli+Dq9R5Ms+oJmT5pyb/Ot2eHSsx+/Zk/JbJuXJnn3rDX44 3YddpG00eTOaBgY+owHc08ud3JQK1AHhTkdizhG3PLOYlTnAhkBCRQldn3usQFcGWOcm 7aqtqIVJTN8MWzx63ZW3xFJmibFtWtX/Fl1yDFrfE8TArHotQlCa8Mc4hVfeezED2GY1 FkiA== X-Gm-Message-State: AFeK/H13uVNPXprXvdt/oufMSQXeSofCkto+gEnAVqpOt8v6TZIC53bKJFsFbQ0ZmM2A5RcM3Kd9sJBluIXEzA== X-Received: by 10.237.42.109 with SMTP id k42mr4680057qtf.52.1489603727993; Wed, 15 Mar 2017 11:48:47 -0700 (PDT) MIME-Version: 1.0 Sender: fgont.si6networks@gmail.com Received: by 10.140.17.213 with HTTP; Wed, 15 Mar 2017 11:48:47 -0700 (PDT) Received: by 10.140.17.213 with HTTP; Wed, 15 Mar 2017 11:48:47 -0700 (PDT) In-Reply-To: <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> From: Fernando Gont Date: Wed, 15 Mar 2017 15:48:47 -0300 X-Google-Sender-Auth: lSWIJwTFL0OmLPaDgC4voHHYSc4 Message-ID: Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Brian E Carpenter Cc: ietf@ietf.org, 6man Mailing List , "Stefano Previdi (sprevidi)" , "draft-ietf-6man-rfc2460bis.all@ietf.org" Content-Type: multipart/alternative; boundary=001a114239121037d7054ac965e9 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:48:50 -0000 --001a114239121037d7054ac965e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 El 15/3/2017 13:17, "Brian E Carpenter" escribi=C3=B3: > Stefano, > On 16/03/2017 04:55, Stefano Previdi (sprevidi) wrote: > ... > > In the mean time, I think it is way too premature to come to conclusion > on what text should be used for RFC2460bis and I recommend that the curre= nt > text is left unchanged until we figured out what to do with EH insertion. > > I believe that we have figured it out: extension header insertion is > harmful to Internet interoperability. > > I fully agree with Suresh's understanding of the rough consensus. > > Brian > > --001a114239121037d7054ac965e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    +1


    El 15/3/2017 13:17, "Brian E Carp= enter" <brian.e.carp= enter@gmail.com> escribi=C3=B3:
    Stefano,
    On 16/03/2017 04:55, Stefano Previdi (sprevidi) wrote:
    ...
    > In the mean time, I think it is way too premature to come to conclusio= n on what text should be used for RFC2460bis and I recommend that the curre= nt text is left unchanged until we figured out what to do with EH insertion= .

    I believe that we have figured it out: extension header insertion is harmfu= l to Internet interoperability.

    I fully agree with Suresh's understanding of the rough consensus.

    =C2=A0 =C2=A0Brian

    --001a114239121037d7054ac965e9-- From nobody Wed Mar 15 11:59:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A345B1317C4; Wed, 15 Mar 2017 11:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5CvrN5SPTKBx; Wed, 15 Mar 2017 11:59:25 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F7B1317B6; Wed, 15 Mar 2017 11:59:25 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id z13so26950965iof.2; Wed, 15 Mar 2017 11:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Ws6E1ZoldqSknOCCnwZETYm/BULceeEuOtraiX3XFcY=; b=WJlIJijpV8QSOi3uBfekk2iNSoIYyrCr000BTtHXYEnqf678otwjr2Gm87SrvBLAgJ Kq7y2PIw0oidr9I9giGN6mR3LR4pIPvwanfot0rnUJ9nLV/hLXOu+5XLbt2EvpXygOtm 1yJCro1jVdoFZ88xB4oaZIs9FC5JqOr6SyaHgrH4QWEy3ScYyeR3qK8X8iuNfCiUVCWF jSXH/5e9pMXWXH9V3Js7GmZ0Xa5hf27veGIURx1LpJG+H4n8D4T7247V1ivL698nlGtd dmnEoRBGO7bzSuNtPeIoJqDPESrrgT/2i71xaA1RGJPE1cbVTVy9tFrFBVy0RiY+fhgF YUHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Ws6E1ZoldqSknOCCnwZETYm/BULceeEuOtraiX3XFcY=; b=TZ8Hs10K/Hc6peGXtMkb6FzgvLKzXn6f6spQcd6JLjLsSeGKUQcXMzmZeJwjLyGTjf 56pQIIA4yl4oEDh6Qz70f5eM90nuT0MR7HFfqKbVIbY1HTeziI9pWYDUUprpAVI4rRbd kVaKGs/bSzu4+azLMlhi5dlZbonQUPo3RyXNKJH7n2mzhDWqcOvOeIT8lxT8z3jEunSh 3RIG3QDz5854w5oAOunj3iSsbtHVJ8T4xWhaXk9ktv6ge8hz/ubnJsunZ61tvEBnK0Jo PJUP39zNi+HHy7o3zbGXXz65f7B78IxCmH+dKXSZJHCk41tGIexGrwtnBlmGWy1P9vEA 1tCA== X-Gm-Message-State: AFeK/H0Citk4edN09Jhb5gXWImJ5eZ4uur+R3oQZj8efcQp7CpBnH4QSrQZZKXmQfQJXJw== X-Received: by 10.107.2.201 with SMTP id 192mr6547803ioc.81.1489604365107; Wed, 15 Mar 2017 11:59:25 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id i189sm538611ita.23.2017.03.15.11.59.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 11:59:24 -0700 (PDT) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Joe Touch , "Leddy, John" , Tim Chown References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" , "Stefano Previdi (sprevidi)" From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 16 Mar 2017 07:59:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 18:59:28 -0000 On 16/03/2017 07:14, Joe Touch wrote: > > > On 3/15/2017 9:33 AM, Leddy, John wrote: >> Does this mean that only middle boxes, not covered by the architecture could insert an extension header for use within the domain? > Please see my recent post about Stefano's issue. IMO, any opaque > (distributed) system that acts like a host can follow the host (node) > requirements. > > The instant that system is not opaque or fails to act like a single > host, it becomes noncompliant. That's the point. That's why the 6man WG shot down proposals to play intra-domain tricks with the flow label a few years ago, and they didn't even break PMTUD or IPsec/AH. In another form, the answer to John is that there are no protocol police, so what consenting adults do inside their own networks simply isn't an issue that an Internet-wide spec can or should address. And for sure, the spec for IPvN for any value of N is an Internet-wide spec. If Stefano and colleagues describe how private domains can perform tricks that MUST NOT be exported to the Internet, that is fine. Whether that becomes a standards track document or an Independent Submission RFC is another question. But IMHO it is completely orthogonal to the rough consensus on 2460bis. Brian From nobody Wed Mar 15 13:20:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9493F131815 for ; Wed, 15 Mar 2017 13:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hzRSrhXdG3g7 for ; Wed, 15 Mar 2017 13:20:21 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB331317F9 for <6man@ietf.org>; Wed, 15 Mar 2017 13:20:20 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id 1so23067717qkl.3 for <6man@ietf.org>; Wed, 15 Mar 2017 13:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uc9MI/vynyMDyxbWcKco7jUK+2+dxFRzkAh8Q3wvq5E=; b=H7ffmKQR09hAQs+d70poIthbqcKkxJJm2bnO7gUVGgAqhIilCtEd+Id8lhhZGe6Hyg TEpuZ2VWPgC/3Vd+NrXodaKTdsycbY2Bk3jIzciZv1znw2OgT91v1hycpL1loHnym7TZ JpivJkflpv7uzMBVhsIKMY23VGlBYnKNMfC231sKA1ERiUbd/DZ/n/KE5B1JwpuC8Zwk neixE/WLIEMRvqGat8xyjs9zAaSzChcVHFwGU+d/HJj1hw437YgmHNWxJCwxaAexcDP4 cFzhvkhz5E3sG6X+JjbE/CxHpHwEDQW9nOef5dgcP6hf+OjH7Ukb1liyAxL5kB/vkZUV EFoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uc9MI/vynyMDyxbWcKco7jUK+2+dxFRzkAh8Q3wvq5E=; b=TkgXK/ArigPcjwtpcgJn8j4SjBSmMkAea8Rq8wV45hipGBk+b4RdHFoAbLf6fQ7UCd rQEfbTPK4nB/qAQt5Hj/pno0qAw7S/bvJFsYTGlqLrJFLXL9Jha5XGjTVy17HC3+KmXL ix6f+Th+f9DTKEhjD7p2c5Ry2UAPaIR2LiwKjmK6g+j9AYBE0UNzZjbHDDS7DX5ESp1n Wz0kVBYkpwryIhG1RwEVF8dqFfvaNDf3mjqzuXcvJDaqKlmhECTImn0/0da57ekBsEFw iaE9bjd4is84b2dyJW4nXFq8JHpn+5FMk4qd29M5R1h9XFHKcsBtm9Woq9P/XUAAnzFp WgHA== X-Gm-Message-State: AFeK/H2G+c9pb2WTtuxZqKCguPQrANmytIAbW7sntzvk0rH9lS2a2L0z2w7cPd65ubT0Cgt9B+xq8LkikL64yw== X-Received: by 10.55.127.4 with SMTP id a4mr4917557qkd.215.1489609219948; Wed, 15 Mar 2017 13:20:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.142.207 with HTTP; Wed, 15 Mar 2017 13:19:49 -0700 (PDT) In-Reply-To: References: <148942937853.9227.2944252822855237301.idtracker@ietfa.amsl.com> From: Mark Smith Date: Thu, 16 Mar 2017 07:19:49 +1100 Message-ID: Subject: Re: "Recommendation on Temporary IPv6 Interface Identifiers" (revised I-D) (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-01.txt) To: Fernando Gont Cc: "6man@ietf.org" <6man@ietf.org>, draft-gont-6man-non-stable-iids@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:20:22 -0000 Hi, Firstly, I really like this draft. Suggestions/comments: o 3.3. Requirements for Temporary IPv6 Addresses " Temporary addresses MUST have a limited lifetime, which should be different for different addresses." For clarity, I'd suggest adding: "This includes when a node has different addresses from within the same prefix." just to be very clear that there is a requirement of individual addresses, and that it doesn't change if they happen to be from within the same prefix. (I assume this is the case?) " 4. The resulting interface identifiers MUST NOT embed layer-2 identifiers (e.g. MAC addresses)." perhaps add, "to prevent correlation between IPv6 IIDs and MAC addresses, when an outside entity has been able to record both." "This is in contrast with e.g. stable addresses [RFC7217], that do not have have a limited lifetime." I think this is technically not true, the standard IPv6 preferred and valid lifetimes could cause a stable address to expire, so in those terms stable addresses, as do all IPv6 addresses, have a "lifetime" which may be limited (static addresses could be considered an exception, however it is only convention that when they're configured they have a infinite preferred and valid lifetime.) Perhaps this would be more accurate: "This is in contrast with e.g. stable addresses [RFC7217], who's values do not change in response to a privacy event or the expiration of a timer, such as the address's preferred or valid lifetime." "Having a variable maximum lifetime prevents an observer from synchronizing with the temporary address regeneration; that is, from being able to expect when address will be regenerated, and thus infer that one newly observed addresses is the result of regenerating a previously observed one." This draft seems to be going a bit further in this direction (in a good way) than RFC4941 does (based on my brief reading of "3.5. Regeneration of Randomized Interface Identifiers") RFC4941 seems to have either host or interface universal values (TEMP_PREFERRED_LIFETIME: 1day, TEMP_VALID_LIFETIME:1 week) for the maximum lifetimes of temporary addresses. It looks to be focusing on avoiding synchronised address changes across clients rather than across addresses within a client. "That is, a host that de- attaches from a network and subsequently re-attaches to a (possibly different) network should regenerate all of its temporary addresses." RFC4941 only very briefly deals with this scenario. I agree with doing it, however I think there is a risk of a DoS on the link or similar if an interface starts failing, and disconnects/re-connects rapidly. I think there should be some prevention against this e.g., multiple disconnects/connects within 3 seconds indicates the interface is failing and regeneration of temporary addresses should not take place if this occurs. "Besides, a node that generates an IPv6 address by embedding a link-layer address in the IPv6 address will, when configuring addresses for different prefixes, result in the same IID being used for such prefixes, thus allowing the corresponding traffic to be correlated." An example of significance might be correlation between internal ULA address traffic and external GUA address traffic if the IIDs are shared and the foreign entity has managed to capture both. ULA would tend to have greater privacy expectations or semantics because they're not global addresses and not intended to be exposed to global parties. "The resulting Interface Identifier SHOULD be compared against the reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] and against those Interface Identifiers already employed in an address of the same network interface and the same network prefix." Also against addresses on different network interfaces attached to the same network. Perhaps this IID comparison should really be taking place across all addresses from within and across prefixes independent of interfaces? Actually, I think that is really saying that there is no IID duplication across any of the addresses used by the host. "The algorithm in [RFC7217] can be augmented for the generation of temporary addresses. The benefit of this would be that a node could employ a single algorithm for generating stable and temporary addresses, by employing appropriate parameters. Nodes would employ the following algorithm for generating the temporary IID:" A brief mention of what is changed verses RFC7217 before presenting the algorithm would be useful. It seems MAC_Address and Time are the differences? Regarding using the MAC_Address, "Employing the MAC address in this expression (in replacement of the Net_Iface parameter of the expression in RFC7217) means that the re-generation of a randomized MAC address will result in a different temporary address." it isn't clear to me whether randomised MAC addresses is a requirement or a recommendation when using this algorithm. With it replacing Net_Iface, it seems to be leaning towards a requirement. nits: - " a node may want to use only Temporary address (e.g., a temporary address)." This text seemed a little confusing because it seemed the temporary address text was being repeated. I realised that the capital T "Temporary" was a special word, perhaps the parenthesis text is unnecessary here. e.g. " a node may want to use only Temporary address ." - In the terminology section, it might be worth quoting a few of the repeatedly used terms from RFC7721 for the convenience of the reader. "Temporary address" would be an example. - Should "stable address" be capitalised throughout as it too is a term defined in RFC7721? - With both "Temporary address" and "temporary address" terms both being used, it seems like there is some sort of difference between what these terms mean. It's not really obvious to me what that difference is. It would seem to me that "Temporary address" (and "Stable address") should always be being used, as their definitions in RFC7721 would seem to apply universally. - "3.3. Requirements for Temporary IPv6 Addresses The requirements for temporary IPv6 addresses are as follows:" -"t","+"T" "The requirements for Temporary IPv6 addresses are as follows:" Regards, Mark. From nobody Wed Mar 15 13:34:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E046C131826; Wed, 15 Mar 2017 13:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 bgaQyHwoU87P; Wed, 15 Mar 2017 13:34:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012F71315A7; Wed, 15 Mar 2017 13:34:33 -0700 (PDT) Received: from [128.9.184.222] ([128.9.184.222]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v2FKYFrQ021996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Mar 2017 13:34:15 -0700 (PDT) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Brian E Carpenter , "Leddy, John" , Tim Chown References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" , "Stefano Previdi (sprevidi)" From: Joe Touch Message-ID: <39a51f77-a89f-2a22-dd9b-af8255a4aa25@isi.edu> Date: Wed, 15 Mar 2017 13:34:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:34:35 -0000 Agreed. Joe On 3/15/2017 11:59 AM, Brian E Carpenter wrote: > On 16/03/2017 07:14, Joe Touch wrote: >> >> On 3/15/2017 9:33 AM, Leddy, John wrote: >>> Does this mean that only middle boxes, not covered by the architecture could insert an extension header for use within the domain? >> Please see my recent post about Stefano's issue. IMO, any opaque >> (distributed) system that acts like a host can follow the host (node) >> requirements. >> >> The instant that system is not opaque or fails to act like a single >> host, it becomes noncompliant. > That's the point. That's why the 6man WG shot down proposals to play > intra-domain tricks with the flow label a few years ago, and they > didn't even break PMTUD or IPsec/AH. > > In another form, the answer to John is that there are no protocol police, > so what consenting adults do inside their own networks simply isn't an > issue that an Internet-wide spec can or should address. And for sure, the > spec for IPvN for any value of N is an Internet-wide spec. > > If Stefano and colleagues describe how private domains can perform tricks > that MUST NOT be exported to the Internet, that is fine. Whether that > becomes a standards track document or an Independent Submission RFC is > another question. But IMHO it is completely orthogonal to the rough > consensus on 2460bis. > > Brian From nobody Wed Mar 15 13:39:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1189131827; Wed, 15 Mar 2017 13:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eVjRl2TDWQuj; Wed, 15 Mar 2017 13:39:30 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8374D1315A7; Wed, 15 Mar 2017 13:39:30 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id 72so15285013uaf.3; Wed, 15 Mar 2017 13:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LDzdPKwtU2L7kdWIFxVhAgLtziivGxboU2IdORfil0s=; b=FYqgt4AZEPig3nXIyqnTEbdVlPaXokyT5A23zlKyoLbZCjBW5n3c1gt8qhKmxJUBb5 vLBnEaEgd7bab32wX9+6FLtyBRtigiSbtmWuZDlg/06nktc5EBRDZX512Ah4Xm9h0oYa ipyudZWlq2g2dLUyPL6W8xcBWybV54QIiE+XRS/FUMCh0tusjv8IL1rU7rv3W3gmS645 /x4C8NwEIaI0p1evnt963pxlK01dBSrinuz/zc2afm6Y7zxzrU95fKd1uhwHqh9Jb2di rbZjBBE5Odcuk57fVRdVQ18vnj5N3bQJkLrmRxcdvtH01TRsvt+asmkFNEMKxSKjS2O4 taUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LDzdPKwtU2L7kdWIFxVhAgLtziivGxboU2IdORfil0s=; b=l9DD0UZHLai+ssaAlLqgbJffIhrXI+Q59BA86a8QaqnD42EcuzCkzVwQZFil4yn6fn 6wJgWaDvyTfv4W85i+RKbBr0lzGHKzN8ffmtV+A01O1IyqB6Gl4R3Nsa8csrvGao2AEp rsOpN+ZWZotfDcmz2oxiKveDeG65RLs6edamPegH1FEO7fZpXxUngUKESIT3+8FRlmif h0LymlqbiUnbFxWZzVkomlVIRor5/Gsyo11lxpE/Nt3P05jistjKerPg0LcQ6lF8fBWr sTTKUgXn50uGY6UID/dVZHjZia+QOAmKzn3e8h90cmHcNMTellzwLSyp6I1UwzqqyMTU 7Xcg== X-Gm-Message-State: AFeK/H10VTVRHtmfyLgisMexC0CI6Gd8HVvHILSTd0T3XgX9xa0WLkOKtb2S0+m0SxI9QCpr6/cmvC9/awARfA== X-Received: by 10.159.40.226 with SMTP id d89mr2160544uad.98.1489610369643; Wed, 15 Mar 2017 13:39:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.142.207 with HTTP; Wed, 15 Mar 2017 13:38:58 -0700 (PDT) In-Reply-To: <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> From: Mark Smith Date: Thu, 16 Mar 2017 07:38:58 +1100 Message-ID: Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Brian E Carpenter Cc: "Stefano Previdi (sprevidi)" , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , Suresh Krishnan , "ietf@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:39:32 -0000 On 16 March 2017 at 03:16, Brian E Carpenter wrote: > Stefano, > On 16/03/2017 04:55, Stefano Previdi (sprevidi) wrote: > ... >> In the mean time, I think it is way too premature to come to conclusion on what text should be used for RFC2460bis and I recommend that the current text is left unchanged until we figured out what to do with EH insertion. > > I believe that we have figured it out: extension header insertion is harmful to Internet interoperability. I and others were going to work on an ID describing why, however the other co-authors seem to have disappeared. I'll start putting together what I have over the next week. Regards, Mark. > > I fully agree with Suresh's understanding of the rough consensus. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Mar 15 16:30:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EBD129C70 for ; Wed, 15 Mar 2017 16:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 bCSsPPwS3xYq for ; Wed, 15 Mar 2017 16:30:32 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8D612E858 for ; Wed, 15 Mar 2017 16:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1489620629; bh=iOoSbw2B1yB8vbmfNH74zQQotgi7HFhucth64OWQsts=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Z4CIZIa8kMB8TisCI9FbjMSkDrT9VcDy2JqFjmE79xNBQelAvR6AUfo6gJsUNg0OrQxYyYOxVdYsU4eJPbMbain8/Pbc0tQs/NhdA8c2INvc/dqMVzhH9xhkGqvSiLGhBE8swZtPz9BNNI20qlMSK+MKGPbxBV92FfEtWSbkCgc= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0177.outbound.protection.outlook.com [213.199.154.177]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-103-wqu_9MEZNvqiDxvMYcdTQg-1; Wed, 15 Mar 2017 23:30:25 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 23:30:23 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.0977.013; Wed, 15 Mar 2017 23:30:23 +0000 From: Tim Chown To: Brian E Carpenter CC: Joe Touch , "Leddy, John" , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" , "Stefano Previdi (sprevidi)" Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGWDpMAgAAGIICAAAFLgIAAA1kAgAAcHgCAAAysgIAAS6oA Date: Wed, 15 Mar 2017 23:30:23 +0000 Message-ID: <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:7904:94e8:362f:9092] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:dihn/He7cQCpi1nURC6r3PBslY2Pms+OaOWKjeAzrGo81H3Zu5bRvmZWhv93X0rOVLKsZxhYftiE7kTDZ5/64JBoiD9iyxkhGX8dJ+6gFPEhxzVcaEWwCt1uBl/hGq7zWTcOUYifu5eCtxNAdRCMqi6NpiUSUZVKmQacxsRztmlwjMBzuF+mpW0bIr4MxlrUz3cS1FcgoCyBgNLwzEBd93G/WuKvzDp1nceRsn+A6uz8kfgPToWHtI9N7LoR/rZjglDJFMR2AAqTHgo2UeBUobcJAyNGTIX+R0JpJK2hujY96EY6w9g08bZpbfDbs2JvtLBFanNxvnPm6kQ79UI49A==; 20:qHt0jwp4T45imEgrrhH9sEvDMzs2zTHzKEz91dnpExF7gyeDToV9qC8NS70UdwWF34YEXLPRe68tfMi2+5m/mGzMsJlCd1/SrAA8z0HDjg6UgnDN7z6XbSPfPvjBPs1Rh3zyiPQZ22zFeBxK+U5Ja2ESo+jaHolgRi3b1/n4Nuk= x-ms-office365-filtering-correlation-id: 197ee99c-1ca4-4075-fe1d-08d46bfb40fc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(377454003)(82746002)(36756003)(229853002)(6486002)(83716003)(6116002)(53936002)(33656002)(102836003)(230783001)(2906002)(3280700002)(3660700001)(5250100002)(53546007)(189998001)(2900100001)(74482002)(93886004)(4326008)(7736002)(305945005)(6916009)(42882006)(6512007)(99286003)(54906002)(50226002)(57306001)(6436002)(6506006)(86362001)(39060400002)(81166006)(8676002)(50986999)(76176999)(8936002)(38730400002)(6246003)(110136004)(2950100002)(5660300001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 23:30:23.5866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: wqu_9MEZNvqiDxvMYcdTQg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 23:30:34 -0000 > On 15 Mar 2017, at 18:59, Brian E Carpenter = wrote: >=20 > On 16/03/2017 07:14, Joe Touch wrote: >>=20 >>=20 >> On 3/15/2017 9:33 AM, Leddy, John wrote: >>> Does this mean that only middle boxes, not covered by the architecture = could insert an extension header for use within the domain? >> Please see my recent post about Stefano's issue. IMO, any opaque >> (distributed) system that acts like a host can follow the host (node) >> requirements. >>=20 >> The instant that system is not opaque or fails to act like a single >> host, it becomes noncompliant. >=20 > That's the point. That's why the 6man WG shot down proposals to play > intra-domain tricks with the flow label a few years ago, and they > didn't even break PMTUD or IPsec/AH. >=20 > In another form, the answer to John is that there are no protocol police, > so what consenting adults do inside their own networks simply isn't an > issue that an Internet-wide spec can or should address. And for sure, the > spec for IPvN for any value of N is an Internet-wide spec. >=20 > If Stefano and colleagues describe how private domains can perform tricks > that MUST NOT be exported to the Internet, that is fine. Whether that > becomes a standards track document or an Independent Submission RFC is > another question. But IMHO it is completely orthogonal to the rough > consensus on 2460bis. Exactly. Tim From nobody Wed Mar 15 18:12:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAC712F28B; Wed, 15 Mar 2017 18:12:21 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 v5FTHjV83DML; Wed, 15 Mar 2017 18:12:14 -0700 (PDT) Received: from tsinghua.edu.cn (smtp11.tsinghua.edu.cn [166.111.204.35]) by ietfa.amsl.com (Postfix) with ESMTP id CD99412F274; Wed, 15 Mar 2017 18:12:13 -0700 (PDT) Received: from [10.235.130.16] (unknown [58.200.235.59]) by app3 (Coremail) with SMTP id DMxvpgDn7u5e5slYCalDAg--.6843S2; Thu, 16 Mar 2017 09:12:06 +0800 (CST) Message-ID: <58C9E662.6060100@cernet.edu.cn> Date: Thu, 16 Mar 2017 09:12:02 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian E Carpenter CC: Joe Touch , "Leddy, John" , Tim Chown , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030700070707020503000404" X-CM-TRANSID: DMxvpgDn7u5e5slYCalDAg--.6843S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WrW8Kry7Gw4rKr4xJr4rGrg_yoW8Xw15pr Waqry7tr1DJF1xJr48Jw18Xr1vqrW5Kr47WF18tryrAw1UArnF9r1Utry8WryjkryFqw1U tr4UWF1DG3W8XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUySb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l84ACjcxK6I8E87Iv67AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr0_Gr 1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAqjxCE14ACF2xKxwAqx4xG6I8vx48I 62xC7I0kMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4I kC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxkIecxEwVAF wVWkMxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI 0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE 14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20x vaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v2 6r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x0UUjR-UUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 01:12:22 -0000 This is a multi-part message in MIME format. --------------030700070707020503000404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian E Carpenter ??: > On 16/03/2017 07:14, Joe Touch wrote: > >> On 3/15/2017 9:33 AM, Leddy, John wrote: >> >>> Does this mean that only middle boxes, not covered by the architecture could insert an extension header for use within the domain? >>> >> Please see my recent post about Stefano's issue. IMO, any opaque >> (distributed) system that acts like a host can follow the host (node) >> requirements. >> >> The instant that system is not opaque or fails to act like a single >> host, it becomes noncompliant. >> > > That's the point. That's why the 6man WG shot down proposals to play > intra-domain tricks with the flow label a few years ago, and they > didn't even break PMTUD or IPsec/AH. > > In another form, the answer to John is that there are no protocol police, > so what consenting adults do inside their own networks simply isn't an > issue that an Internet-wide spec can or should address. And for sure, the > spec for IPvN for any value of N is an Internet-wide spec. > > If Stefano and colleagues describe how private domains can perform tricks > that MUST NOT be exported to the Internet, that is fine. Whether that > becomes a standards track document or an Independent Submission RFC is > another question. But IMHO it is completely orthogonal to the rough > consensus on 2460bis. > > +1, xing > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --------------030700070707020503000404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian E Carpenter 写道: 
    On 16/03/2017 07:14, Joe Touch wrote:
  
    On 3/15/2017 9:33 AM, Leddy, John wrote:
    
    Does this mean that only middle boxes, not covered by the architecture could insert an extension header for use within the domain?
      
    Please see my recent post about Stefano's issue. IMO, any opaque
(distributed) system that acts like a host can follow the host (node)
requirements.

The instant that system is not opaque or fails to act like a single
host, it becomes noncompliant.
    
    
That's the point. That's why the 6man WG shot down proposals to play
intra-domain tricks with the flow label a few years ago, and they
didn't even break PMTUD or IPsec/AH.

In another form, the answer to John is that there are no protocol police,
so what consenting adults do inside their own networks simply isn't an
issue that an Internet-wide spec can or should address. And for sure, the
spec for IPvN for any value of N is an Internet-wide spec.

If Stefano and colleagues describe how private domains can perform tricks
that MUST NOT be exported to the Internet, that is fine. Whether that
becomes a standards track document or an Independent Submission RFC is
another question. But IMHO it is completely orthogonal to the rough
consensus on 2460bis.

    +1, xing

        Brian

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

    --------------030700070707020503000404-- From nobody Thu Mar 16 01:12:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22D2126DC2; Thu, 16 Mar 2017 01:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 D5K_FmcqlljU; Thu, 16 Mar 2017 01:11:53 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id AE46F126D74; Thu, 16 Mar 2017 01:11:53 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 16 Mar 2017 08:11:53 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 20418D788D; Thu, 16 Mar 2017 01:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=f5Stg+JQioF3tqQnqPXCD9XVPzA=; b= We5tm+PMLgR9GatR5VNCd7gp8glhbPrnj1hPYTmLBMQim7jpn6WDntgyXmMFhPdG zkFA6ROZTMvQLp9F5hdvyQlOsPww3dgF5/sXS32qtYwUbZom8woDOoIuGIe8zteR uFBgqOQlt0tydcy2vr2dteYF8fwU/KJdRAnACCyz3bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=MvfZcjKojiq/M/qe+utmmzX f4OqQnREX/vBqx7VotxvchfISldBe+PIK4t48neP8tkdIWFKQPpRaY+tJala7dWw AG2EV3tn6HDdQwJneoW5ap8F39VAdgHE4WV/osv0vPhXkPj8hMdBAhHNLEprcGdy NbpOmXtPlbMSBTdJhPkI= Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B6A54D788B; Thu, 16 Mar 2017 01:11:52 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A66EE9EFB05D; Thu, 16 Mar 2017 09:11:49 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_28D39F10-C370-4AEF-AE52-948019DCA92E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Date: Thu, 16 Mar 2017 09:11:48 +0100 In-Reply-To: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" , Suresh Krishnan To: "ietf@ietf.org" , 6man WG References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 08:11:56 -0000 --Apple-Mail=_28D39F10-C370-4AEF-AE52-948019DCA92E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Guys, Please hold your horses. The AD has made the call. I don't think we need = to have a poll on that. Cheers, Ole > On 15 Mar 2017, at 03:47, Suresh Krishnan = wrote: >=20 > Thanks to everyone who commented during the IETF Last Call of = draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this = draft was mainly focused around the text in Section 4 that discusses the = handling of extension headers. The biggest concern raised was that the = current text is ambiguous on whether header insertion is allowed on = intermediate nodes or not. There were some people arguing that an = explicit prohibition is not necessary as the text is already clear, = while others believed that explicitly listing the prohibitions will = minimize any misunderstandings in the future. There was also a small = number of people who wanted to explicitly allow header insertion and = describe how to do it, but this was clearly out of scope for this draft = (but may be in scope for future work in 6man). Overall, no one argued = against the fact that the intent of the text in RFC2460 was to forbid = insertion of extension headers on any other node but the source of the = packet. The only argument made against adding clarifying text was that = the text was already clear. Given this, I believe there is consensus to = add explicit text about header insertion into the draft before it = progresses further. I have discussed this with the editor and the = document shepherd and would like to propose the following text change. >=20 > OLD (from -08): >=20 > The insertion of Extension Headers by any node other than the source > of the packet causes serious problems. Two examples include breaking > the integrity checks provided by the Authentication Header Integrity > [RFC4302], and breaking Path MTU Discovery which can result in ICMP > error messages being sent to the source of the packet that did not > insert the header, rather than the node that inserted the header. >=20 > One approach to avoid these problems is to encapsulate the packet > using another IPv6 header and including the additional extension > header after the first IPv6 header, for example, as defined in > [RFC2473] >=20 > With one exception, extension headers are not processed by any node > along a packet's delivery path, until the packet reaches the node (or > each of the set of nodes, in the case of multicast) identified in the > Destination Address field of the IPv6 header... >=20 > NEW: >=20 > With one exception, extension headers are not examined, processed, > inserted, or deleted by any node along a packet's delivery path, > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field of > the IPv6 header... >=20 > Please feel free to comment either privately or on list if you have = any concerns with this resolution going forward. >=20 > Regards > Suresh >=20 > P.S.: There were also other editorial issues that were raised during = last call and they should be addressed in the next version of the = draft-------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_28D39F10-C370-4AEF-AE52-948019DCA92E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYykjFAAoJEL7aWKiYQt92ANkQAIG+LC51vSPBg1F6Sk25s2MM 8hOj40Od5dZqSJ0J5D9dJNA+SPg4N7nuy/Pu/3hPeMITwkr46dn2BaUMoNPEFu8z 3p8RGFLbcrlf7rUJJojrfGLy54ceU6K7VnVsbiJGOUBrLgvGh1DgGTt+u8XBXs2Q c+3zFHsFhXi2hNORohSzDcGbreQFsp07nQEzfIw/rGttU/ciCP6m7+fooxsXxKYf 1NRNqYlsfstrX3FUboY3Jo5Of8OCEoJ60Vb55rvigCoWV2v8x2TnU0PhCFIoDyy8 E3txO5eHvYumNSU0pgS7kjvVum19Fyzyjr3sn/WpfxjptfU9ircK6AxNfLygbM4X ScdjbT/ynJQ8iXKGbZhxQ5kns17piqgBNF1zsjeqUq+uYkhRbvPAF04vgTtvWgcv x1Zlaob1F4VY/d681NcNQN1YPT2r3frEJo5TyCV50yqUBXFn+BswxMYI0+IPTn6B X4F6OKLafjmezYoJ8cpvHWDxm1XdUrM0tVZvPTp44L8DWPqIBoDGj/tid6OxktXn v5DFqmni83fWjeqK4RwUwxlWnop+a9qs+YTqi9aH37shqj4L9yar6Lp3G9oYp+7n emhJBH8NjFvC0RA6FMNMkNEALc+Sdzs2HIqEWBlNjd7a07sQcDfLtAFezicaGWCD 0ikeWS30msTvni5aP1vj =J14L -----END PGP SIGNATURE----- --Apple-Mail=_28D39F10-C370-4AEF-AE52-948019DCA92E-- From nobody Thu Mar 16 03:44:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16435127444; Thu, 16 Mar 2017 03:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 h3tDprjE1uiX; Thu, 16 Mar 2017 03:44:37 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC861273E2; Thu, 16 Mar 2017 03:44:37 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id n11so108386372wma.1; Thu, 16 Mar 2017 03:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=6Hle2NEUjspCa6SAq+Wf3RpZV4sBgRqnRhmyya9oUf4=; b=ut6DwppRkeuwP/WuU+0hhpcqS/Le7LGogcU7+Qld/eDQdIsBD963sPM7mhOBxEInAR 7ZZTr5TNTcLCZUvPQV6AJI1B32uQykl+0F6pyEwLTT9MaXoeWRHoC+I/M0nyBjNVW5+Y ExDW4if7YU1nDOhQEInaaKoS32s4xad98s/uvgcaI4bosic7IWXSk3ORr5xXQSCW47RC zr3wgkcYAbSzXR/66w/zRM6bnTJRrRSyHle7dI6w46CvfG7kXgpmNtYyn//OWeAEd1/j rIZRYTl+bQJMdxtEqp4FKC7T7RjdckOc/dKVOv6aSLzQblZS4NtQz4khHxTRCJDa9iDw 4MXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=6Hle2NEUjspCa6SAq+Wf3RpZV4sBgRqnRhmyya9oUf4=; b=ZCKx+heEJRDFD3btE4SUKbRq339w8AimprSKURC4J9f/8SO6VzxONdCdn4bmDRXV5m sxatBz41eSdcMDa02Fq+LH16WkebpakZp2JFEO+LQKhScc7nywn972gGZ5KEHs4jVUC2 huw3KyKQ+wuX2Ij4+9MPG37Eif0Q5M4laUk55NQGSNoPOqthteA9ukyACJnnCq1rITk8 /rz8t0TTQmTos0l2f4Kd1E0UcJHSyzMWlGL/R1QXxeIZzeFlf+8RVSkvgbVLzg6m0pj/ k/3aLhS/pJZGVN8BwyhX9y9ELdU7zGiTj10CeP8mjQzM5O5m13BKh5C4Iw3vn+gDS0lM 9hkQ== X-Gm-Message-State: AFeK/H1ErMCOv1iDtjDhe3fvAn+UWX4+YuOBavugVdVMK/aSd6Ln5TD/T0/+Gr45tuxpYA== X-Received: by 10.28.230.83 with SMTP id d80mr8419999wmh.18.1489661076045; Thu, 16 Mar 2017 03:44:36 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id b199sm3828273wmb.13.2017.03.16.03.44.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 03:44:35 -0700 (PDT) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Tim Chown , Brian E Carpenter References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> Cc: 6man WG , "ietf@ietf.org" , "Leddy, John" , "Stefano Previdi (sprevidi)" , "draft-ietf-6man-rfc2460bis.all@ietf.org" From: Stewart Bryant Message-ID: <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> Date: Thu, 16 Mar 2017 10:44:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:44:39 -0000 > In another form, the answer to John is that there are no protocol police, > so what consenting adults do inside their own networks simply isn't an > issue that an Internet-wide spec can or should address. That is not quite true, the inability to gain an IANA allocated codepoint can make long term private deployments very difficult, either for the protocol squatting on a codepoint because they could not get one allocated, or to the deployment of a new protocol legitimately allocated a conflicting codepoint. - Stewart From nobody Thu Mar 16 04:03:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F6D127097 for ; Thu, 16 Mar 2017 04:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 KpI91H7BGlmr for ; Thu, 16 Mar 2017 04:03:06 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4DA12708C for ; Thu, 16 Mar 2017 04:03:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v2GB31bg018291; Thu, 16 Mar 2017 12:03:01 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C0937208693; Thu, 16 Mar 2017 12:03:01 +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 B1E9B20820E; Thu, 16 Mar 2017 12:03:01 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2GB31lY008372; Thu, 16 Mar 2017 12:03:01 +0100 Subject: Re: a draft about on-link and subnet prefixes To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> Cc: IPv6 IPv6 List From: Alexandre Petrescu Message-ID: <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> Date: Thu, 16 Mar 2017 12:02:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:03:08 -0000 Le 15/03/2017 à 01:08, 神明é”哉 a écrit : > At Tue, 14 Mar 2017 09:47:49 +0100, > Alexandre Petrescu wrote: > >> I suggest adding the following upfront: >> >> "The onlink|SLAAC dichotomy MAY be applied; if it is applied, then the >> routing towards that subnet MUST use the shortest plen of the two" >> >> E.g. if the on-link prefix is 48 and the SLAAC prefix is 64 then the 48 >> (not the 64) must be in the rt tables of routers with routes towards >> that subnet. > > Thanks for the feedback. I'm not sure how to interpret this, but in > any event, adding a new MAY or MUST is clearly out of scope of this > draft. It only intends to explain what the current specifications try > to specify in case it may no be very clear. The explanation may be better if it also illustrated some of the side-effects. One side-effect of using distinct on-link|SLAAC prefixes is that the routing towards that subnet has a particular plen. >>> I've submitted a new individual draft on the separation between >>> on-link and (SLAAC) subnet prefixes, at the risk of stating the >>> obvious: >>> https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix-clarify/ >> >> I have read the draft. It was a good read, thank you. It clarifies the >> difference between on-link prefixes and SLAAC prefixes. >> >> Here are my comments in summary: >> >> 1. It does not resolve the question of whether or not the 64bit IID >> should be required in the IPv6 Addressing Architecture. > > No it doesn't, and it's intentional. Ok, this is good to know. It is the most important point why I got in this discussion. So, it is not because the onlink|SLAAC prefixes may be distinct that the 4291 would recommend 64bit IIDs. There may be other reason. >> 2. The explanation of the dichotomy onlink|SLAAC should be accompanied >> by a recommendation of using the shortest plen of the two (even when >> that plen is not 64) in the Internet routing setup towards that >> subnet. This is the crux of it. > > I'm not sure what this means. It means that in order to have distinct onlink|SLAAC prefixes one has to have distinct routing towards that subnet too. >> This recommendation should acknowledge that when that plen is larger >> than 64, SLAAC/Ethernet can not work. > > There's no recommendation in this draft; it only talks about facts. > Anyway, it's true that if (SLAAC subnet) plen is larger (or shorter) > than 64 SLAAC over Ethernet does not work. Ok > It's already covered in > bit more generalized text: > > [...] This means that, for example, if the length of > interface identifiers for the link is specified as 63, 64, or 65, > then the SLAAC subnet prefix length must be 65, 64, or 63, > respectively; otherwise the PIO is ignored for the purpose of SLAAC. But this text does not say what is the plen of routes towards that subnet. >> This recommendation should acknowledge that when that plen is smaller >> than 64, SLAAC/Ethernet can work by using 64 for SLAAC and plen for >> on-link determination. > > I'm not sure what this means. But, as long as the current > specifications go, SLAAC doesn't work on Ethernet if the subnet prefix > is smaller (or larger for that matter) than 64. If you are trying to > propose loosening it, that's fine - please write a proposal in a > separate draft. But that's out of scope of this draft, which only > talks about what current standards state. Noted. [...] >> However, this dichotomy has very many consequences. >> >> A number of RFCs and I-Ds misunderstand this dichotomy "on-link"|"SLLAC" >> and make wrong recommendations. Maybe you want this draft to clarify >> all these RFCs? > > Which RFCs are they? I don't intend to update any existing RFCs in > this draft, but I could refer to those RFCs as example cases if and > when I revise the draft. I think of the following: RFC4887 "Home network models with NEMO" (it is a stretch, but HA config is impacted), RFC4903 "Multi-Link Subnet Issues", RFC7278 "64share", various RFCs of Proxy Mobile IP, and other recent Internet Drafts. >> One of the worst consequence is the allocation of single /64 prefix for >> an end user. Many drafts and their respective deployments only give a >> /64 to the end user: it is used both for SLAAC _and_ for on-link >> determination. If they agreed the dichotomy then they would give at >> least two distinct prefixes to the end-user: one for SLAAC and one for >> on-link determination. > > Perhaps, but such a discussion is out of scope of this draft. But if nobody allocates two distinct prefixes, what are the users of two distinct prefixes going to use? Or is it just theory? >> Another consequence is the possibility to make wrong configurations. >> >> A wrong configuration is the following: in a subnet where plen1 is for >> on-link determination and plen2 is for SLAAC, it is easily possible to >> make a Host believe a Neighbor is on-link whereas the routing system to >> which that subnet is connected routes to another subnet for same Neighbor. >> >> If somebody plays too much with this plen1 and plen2 configurations >> (onlink|SLAAC) on a subnet one can easily make mistakes. There is no >> recommendation how to avoid these mistakes. >> >> Recommendations about how to play with this onlink|SLAAC dichotomy will >> need to take into account how routing is based on longest-prefix match. >> >> Also these recommendations must make sure that allocating a >> single /64 to an end user does not get into widespread use. > > Ditto. Well... ok. >>> Perhaps the administrator of the link wanted to force most of on-link >>> communication to 2001:db8:1:2::/64 to be first sent to a default >>> router, while allowing a particular set of hosts (those using the >>> address that match the on-link prefix) to communicate directly. >> >> I agree with the use-case. >> >> But maybe the administrator should know too that the default router will >> reply back with an ICMP Redirect leading to an end result where the >> on-link prefix is same as the SLAAC prefix in the rt table. > > Yes (although the admin would disable sending redirects if this is > really the operation they want and their router supports the knob), > that's why the draft says "first sent to a default router". Anyway, > as admitted this is an imaginary use case. I didn't intend to insist > that's necessarily realistic. Ok. >>> An on-link prefix could be longer than an SLAAC subnet prefix. For >>> example, when the latter is 2001:db8:1:2::/64, the former could be >>> 2001:db8:1:2:3:4::/80. >> >> I agree it could be. >> >> But in this case, one also must make sure the routing towards that >> subnet is the SLAAC's /64 (not the 'onlink's /80). > > I don't see why. Because if the routing is not towards the SLAAC's /64 then the following bad situation may occur: A computer configures an address with SLAAC /64, address that is actually found on another subnet. At that point, neighbors in that other subnet will not be able to reach this computer - their ND process fails and they dont ask their default router. In this sense the computer in question forms an address that is actually not allowed to use, because there is no routing to it. On another hand, if the routing towards our subnet where this computer is found is the /64 then the situation is better. onlink /80 Router -----------Router -------------- Computer /64 in rt | SLAAC /64 | | +----------(another subnet) ----Neighbor1 | +-Neighbor2 >>> An on-link prefix could also be shorter than an SLAAC subnet prefix. >>> For example, when the latter is 2001:db8:1:2::/64, the former could >>> be 2001:db8:1::/48. >> >> I agree it could be. >> >> In this case, one also must make sure the routing towards that subnet is >> the onlink's /48, and not the SLAAC's /64. > > Implementation specifics (whether it's implemented as a "route") aside, > an RFC4861-compliant host implementation should already do so. What I am asking stems not from implementation specifics (implemented as route, or otherwise), but stems from bidirectional reachability requirements. The draft currently talks exclusively what happens on a link, in a subnet. But it misses to tell that whatever happens on a link, or in a subnet, must ensure bidirectional rechability to and from the Internet. >> Lacking of saying so leads to the undesirable situation of operators >> allocating a /64 for a ptp link. >> >> To combine the two, a recommendation would be: >> >> "The onlink|SLAAC dichotomy may be applied only if the routing towards >> that subnet uses the shortest plen of the two; that could be a value >> less than 64." > > (Aside from whether this makes sense or not) again, there's no > recommendation in this draft. It only explains what current protocol > specifications state, just more explicitly. Ok, noted. Alex From nobody Thu Mar 16 05:41:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79589129482; Thu, 16 Mar 2017 05:41:00 -0700 (PDT) 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 autolearn_force=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 ApmzxNyddbHB; Thu, 16 Mar 2017 05:40:59 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC39C129464; Thu, 16 Mar 2017 05:40:57 -0700 (PDT) X-AuditID: 60721c4b-93fff700000006b0-67-58ca87d6b9bc Received: from VAADCEX48.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id 86.69.01712.7D78AC85; Thu, 16 Mar 2017 08:40:56 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX48.cable.comcast.com (147.191.103.225) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Mar 2017 08:40:54 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Thu, 16 Mar 2017 08:40:53 -0400 From: "Leddy, John" To: Stewart Bryant , Tim Chown , Brian E Carpenter CC: 6man WG , "ietf@ietf.org" , "Stefano Previdi (sprevidi)" , "draft-ietf-6man-rfc2460bis.all@ietf.org" Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Index: AQHSnaSAxRLtjcu1EUaNXmYCyEu8g6GWVuWAgAABTAD//8BKAIAAXywAgAAMrICAAEuugIAAvF6A///dbwA= Date: Thu, 16 Mar 2017 12:40:53 +0000 Message-ID: References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> In-Reply-To: <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.252] Content-Type: text/plain; charset="utf-8" Content-ID: <9DBCF6E95FD0C846BD8BD6D2A9CC8E6C@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsWSUOxpoXuj/VSEwaaV6hZtF/cxWbx6e43N 4tnG+SwWL8++Z7JYv/sRk8WpB4kWfT8fszmwe0z5vZHVY+esu+weS5b8ZPJY+fsKWwBLFJdN SmpOZllqkb5dAlfG2ju7GAveiFa8/yTVwLhEtIuRg0NCwETi1AueLkYuDiGBmUwSU1/8YINw DjFKLLjzjAXCOckocbN5D3MXIycHm4COxIxp11hBEiICTYwSn8/3MIM4zAInGCWm3WtlBKkS FvCQmLTpGguILSLgKbFu42EWkH0iAkkSL/5Wg4RZBFQlXi97xgZi8wq4SHTebWMCsYUE7jNL LH8oDGJzCthKbG/aCjaSUUBM4vupNWA1zALiEreezAezJQQEJJbsOc8MYYtKvHz8jxXEFhXQ k3h47yYrRFxH4uz1J4wQtoHE1qX7WCBsRYl/s9eDncYsoCmxfpc+xHgHiZs9DewQtqLElO6H 7BBnCkqcnPkEqlVc4vCRHawTGKVnIbloFsKkWUgmzUIyaRaSSQsYWVcxypUlJqYk52bkl5YY GOolJyblpOol5+cmJxaXgOhNjKAUUSTjvYNx3U/3Q4wCHIxKPLzu4acihFgTy4orc4FRxcGs JMLrlgoU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzntJZHWEkEB6YklqdmpqQWoRTJaJgxOYFswj i/SdJU9Nn23r0PItfdP12y9XxG5zjjVvP1X7ZR6joHx3wGTVbSVSe+fIpoTsC+h+XsW/Z7nd /wP266f/YZL+P/vchXV3PeIrnjREbvLZ2j9XJnvpk5rlz1gu/mncc/jjpOTCkhchjOcOaUvd Wit52knOdaP51/0skwo2X499orC08vm/x0FKLMUZiYZazEXFiQAS/JsdDQMAAA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:41:00 -0000 VGhhbmtzIFN0ZXdhcnQsDQoNClRoaXMgcmVhbGx5IHN1cHBvcnRzIG15IHBvaW50IGFuZCBob3Bl ZnVsbHkgbm90IHRoZSBpbnRlbnQgb3IgcmVzdWx0IG9mIHRoZSBkaXNjdXNzaW9ucyBoZXJlLg0K DQpXZSBhcmUgdHJ5aW5nIHRvIHdvcmsgdGhyb3VnaCB0aGUgSUVURiBwcm9jZXNzIHRvIGNvbWUg dXAgd2l0aCBzdGFuZGFyZHMgYW5kIHNvbHV0aW9ucyB0aGF0IGFkZHJlc3MgcmVhbCBvcGVyYXRp b25hbCBjaGFsbGVuZ2VzIGZhY2VkIGluIGRlcGxveW1lbnRzLiAgRm9yIG9wZXJhdG9ycywgZGVh bGluZyB3aXRoIGxlZ2FjeSBhbmQgbWlncmF0aW9ucyBhcmUgYSBiaWcgY2hhbGxlbmdlLg0KDQpX aXNoaW5nIHRoZXNlIGlzc3VlcyBhd2F5IGFuZCBhcyBhIHJlc3VsdCBoYXZpbmcgbm9uLXN0YW5k YXJkIGZ1bmN0aW9uYWxpdHkgaW4g4oCcbWlkZGxlIGJveGVz4oCdIHRoYXQgYXJlIGlnbm9yZWQg aW4gdGhlIGFyY2hpdGVjdHVyZSBpcyBub3QgcHJvZHVjdGl2ZS4gIE5BVHMgYXJlIGEgd2F5IG9m IGxpZmUsIGRhcmsgc3BhY2UgaXMgYmVpbmcgZGVwbG95ZWQgYnkgb3RoZXIgb3BlcmF0b3JzLCDi gJxDbG91ZOKAnS9ORlYvU2VydmljZUNoYWluaW5nIGFyZSBhY3RpdmUgYXJlYXM7IHR1bm5lbHMs IHR1bm5lbHMgZXZlcnl3aGVyZSAtIFBNVFUgaXMgYWx3YXlzIGFuIGlzc3VlLiAg4oCcVHVydGxl cyBhbmQgVHVubmVscyBhbGwgdGhlIHdheSBkb3du4oCdLg0KDQpXZSBhcmUgdmVyeSBhZ2dyZXNz aXZlbHkgbWlncmF0aW5nIHRvIGEgVjYgaW5mcmFzdHJ1Y3R1cmUsIGJ1dCB0aGVyZSBpcyBhIGxh cmdlIGFtb3VudCBvZiBvbGQgbGVnYWN5IHN5c3RlbXMvYXBwbGljYXRpb25zL3NlcnZpY2VzIHRo YXQgbmVlZCB0byBiZSBhZGRyZXNzZWQuICBBdCB0aGUgc2FtZSB0aW1lIHRoZSBhbGx1cmUgb2Yg 4oCcQ2xvdWTigJ0gYXR0cmFjdHMgc3lzdGVtcyB0aGF0IHNob3VsZCBuZXZlciBiZSBtb3ZlZCB3 aXRob3V0IGJlaW5nIHJlLWFyY2hpdGVjdGVkIGFuZCB0aGUgdmlydHVhbGl6YXRpb24gZW52aXJv bm1lbnRzIGZ1bGx5IHN1cHBvcnRpbmcgVjYgKGJvdGggVmVuZG9ycyBhbmQgT3BlblNvdXJjZSkg 4oCTIGJ1dCB0aGV5IGRvIG1vdmUgYW5kIHZlbmRvcnMgaGVscCBtYWtlIHRoYXQgcG9zc2libGUu DQoNCkhvcGVmdWxseSB3ZSBjYW4ga2VlcCB0aGUgZGlzY3Vzc2lvbnMgZ29pbmcgYW5kIGtlZXAg dG9vbHMgYXZhaWxhYmxlIHVudGlsIHdlIGtub3cgd2UgaGF2ZSBzb2x1dGlvbnMgdG8gZGVhbCBh bGwgdGhlIGFjdGl2aXR5IGhhcHBlbmluZyBvdXRzaWRlIGEgY2xlYW4gZW5kLXRvLWVuZCBBcmNo aXRlY3R1cmUsDQoNCkpvaG4NCg0KDQoNCk9uIDMvMTYvMTcsIDY6NDQgQU0sICJTdGV3YXJ0IEJy eWFudCIgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAgICA+IEluIGFub3Ro ZXIgZm9ybSwgdGhlIGFuc3dlciB0byBKb2huIGlzIHRoYXQgdGhlcmUgYXJlIG5vIHByb3RvY29s IHBvbGljZSwNCiAgICA+IHNvIHdoYXQgY29uc2VudGluZyBhZHVsdHMgZG8gaW5zaWRlIHRoZWly IG93biBuZXR3b3JrcyBzaW1wbHkgaXNuJ3QgYW4NCiAgICA+IGlzc3VlIHRoYXQgYW4gSW50ZXJu ZXQtd2lkZSBzcGVjIGNhbiBvciBzaG91bGQgYWRkcmVzcy4NCiAgICANCiAgICBUaGF0IGlzIG5v dCBxdWl0ZSB0cnVlLCB0aGUgaW5hYmlsaXR5IHRvIGdhaW4gYW4gSUFOQSBhbGxvY2F0ZWQgDQog ICAgY29kZXBvaW50IGNhbiBtYWtlIGxvbmcNCiAgICB0ZXJtIHByaXZhdGUgZGVwbG95bWVudHMg dmVyeSBkaWZmaWN1bHQsIGVpdGhlciBmb3IgdGhlIHByb3RvY29sIA0KICAgIHNxdWF0dGluZyBv biBhIGNvZGVwb2ludA0KICAgIGJlY2F1c2UgdGhleSBjb3VsZCBub3QgZ2V0IG9uZSBhbGxvY2F0 ZWQsIG9yIHRvIHRoZSBkZXBsb3ltZW50IG9mIGEgbmV3IA0KICAgIHByb3RvY29sDQogICAgbGVn aXRpbWF0ZWx5IGFsbG9jYXRlZCBhIGNvbmZsaWN0aW5nIGNvZGVwb2ludC4NCiAgICANCiAgICAt IFN0ZXdhcnQNCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCg0K From nobody Thu Mar 16 10:14:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C304B1296C4 for ; Thu, 16 Mar 2017 10:14:10 -0700 (PDT) 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_PASS=-0.001] autolearn=ham autolearn_force=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 ipwSPV5zGaCp for ; Thu, 16 Mar 2017 10:14:07 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E58912948B for <6man@ietf.org>; Thu, 16 Mar 2017 10:14:07 -0700 (PDT) Received: from [IPv6:2001:1291:200:42e::2] (cl-1071.udi-01.br.sixxs.net [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 43F3A81A40; Thu, 16 Mar 2017 18:14:00 +0100 (CET) From: Fernando Gont Subject: Re: "Recommendation on Temporary IPv6 Interface Identifiers" (revised I-D) (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-01.txt) To: Mark Smith References: <148942937853.9227.2944252822855237301.idtracker@ietfa.amsl.com> Cc: "6man@ietf.org" <6man@ietf.org>, draft-gont-6man-non-stable-iids@tools.ietf.org X-Enigmail-Draft-Status: N1110 Message-ID: <4deb5200-0f4f-d3d1-b164-e70fabc77d86@si6networks.com> Date: Thu, 16 Mar 2017 13:35:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:14:11 -0000 Hi, Mark, Thanks so much for your feedback! Please find my comments in-line... On 03/15/2017 05:19 PM, Mark Smith wrote: > Hi, > > Firstly, I really like this draft. Thanks! > Suggestions/comments: > > > o 3.3. Requirements for Temporary IPv6 Addresses > > " Temporary addresses MUST have a limited lifetime, which should be > different for different addresses." > > For clarity, I'd suggest adding: > > "This includes when a node has different addresses from within the same prefix." > > > just to be very clear that there is a requirement of individual > addresses, and that it doesn't change if they happen to be from within > the same prefix. (I assume this is the case?) Will do. Actually, this scenario is probably the most important one,... so it's better be crystal clear. > " 4. The resulting interface identifiers MUST NOT embed layer-2 > identifiers (e.g. MAC addresses)." > > perhaps add, > > "to prevent correlation between IPv6 IIDs and MAC addresses, when an > outside entity has been able to record both." Yes, there's also the fact that: 1) We cannot be assured that the randomization of the underlying MAC address is good enough 2) if the IIDs are 64-bit long, and the mac addresses are 48-bit long, you still need to randomize those remaining 16 bits... so there's no point in setting pieces of the IID differently 3) Another way to think about this is "compartmentalization": if you embed an ID from a layer below 8when you don't need to), if you screw up with how you generate it, the problem is exacerbated. 4) etc. I'm not sure whether to delve into all these details here, or just simply provide references to the reader, as we're currently doing. That is, the reuse of identifiers is well-covered in e.g. draft-gont-predictable-numeric-ids-00... and if we start to elaborate the reasons, the discussion will be incomplete or we will end up embedding such I-D into this one... Thoughts? > "This is > in contrast with e.g. stable addresses [RFC7217], that do not have > have a limited lifetime." > > I think this is technically not true, the standard IPv6 preferred and > valid lifetimes could cause a stable address to expire, so in those > terms stable addresses, as do all IPv6 addresses, have a "lifetime" > which may be limited (static addresses could be considered an > exception, however it is only convention that when they're configured > they have a infinite preferred and valid lifetime.) > > Perhaps this would be more accurate: > > "This is in contrast with e.g. stable addresses [RFC7217], who's > values do not change in response to a privacy event or the expiration > of a timer, such as the address's preferred or valid lifetime." You're right. The current text is not really accurate. We'll certainly add something along these lines (what you've suggested)... > "Having a variable maximum lifetime prevents > an observer from synchronizing with the temporary address > regeneration; that is, from being able to expect when address will be > regenerated, and thus infer that one newly observed addresses is the > result of regenerating a previously observed one." > > This draft seems to be going a bit further in this direction (in a > good way) than RFC4941 does (based on my brief reading of "3.5. > Regeneration of Randomized Interface Identifiers") RFC4941 seems to > have either host or interface universal values > (TEMP_PREFERRED_LIFETIME: 1day, TEMP_VALID_LIFETIME:1 week) for the > maximum lifetimes of temporary addresses. It looks to be focusing on > avoiding synchronised address changes across clients rather than > across addresses within a client. We're certainly going further than RFC4941: that's intentional. The goal of this requirement is to avoid the regeneration of a temporary address to become obvious to an observer -- because if it is obvious, there's no point in regenerating the temporary addresses. > "That is, a host that de- > attaches from a network and subsequently re-attaches to a (possibly > different) network should regenerate all of its temporary addresses." > > RFC4941 only very briefly deals with this scenario. IIRC, research had found that RFC4941 implementations were failing in this area. > I agree with doing > it, however I think there is a risk of a DoS on the link or similar if > an interface starts failing, and disconnects/re-connects rapidly. I > think there should be some prevention against this e.g., multiple > disconnects/connects within 3 seconds indicates the interface is > failing and regeneration of temporary addresses should not take place > if this occurs. I agree with you. There should certainly be some sort of limit. The specific value (e.g., multiple disconnects in X time) is less important... but the document should probably at least mention this and suggest some limit here. > "Besides, a node that generates an IPv6 address by embedding > a link-layer address in the IPv6 address will, when configuring > addresses for different prefixes, result in the same IID being used > for such prefixes, thus allowing the corresponding traffic to be > correlated." > > An example of significance might be correlation between internal ULA > address traffic and external GUA address traffic if the IIDs are > shared and the foreign entity has managed to capture both. ULA would > tend to have greater privacy expectations or semantics because they're > not global addresses and not intended to be exposed to global parties. This is certainly worth incorporating. Thanks! > "The resulting Interface Identifier SHOULD be compared against the > reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] > and against those Interface Identifiers already employed in an > address of the same network interface and the same network > prefix." > > Also against addresses on different network interfaces attached to the > same network. Perhaps this IID comparison should really be taking > place across all addresses from within and across prefixes independent > of interfaces? Actually, I think that is really saying that there is > no IID duplication across any of the addresses used by the host. Agreed. We'll clarify this. > "The algorithm in [RFC7217] can be augmented for the generation of > temporary addresses. The benefit of this would be that a node could > employ a single algorithm for generating stable and temporary > addresses, by employing appropriate parameters. > > Nodes would employ the following algorithm for generating the > temporary IID:" > > A brief mention of what is changed verses RFC7217 before presenting > the algorithm would be useful. It seems MAC_Address and Time are the > differences? Yes. Essentially "Time" is what makes the resulting address change over time. For Temp address, the secret_key *could* be randomized e.g. upon system bootstrap. > Regarding using the MAC_Address, > > "Employing the MAC address in this expression (in replacement of the > Net_Iface parameter of the expression in RFC7217) means that the > re-generation of a randomized MAC address will result in a different > temporary address." > > it isn't clear to me whether randomised MAC addresses is a requirement > or a recommendation when using this algorithm. With it replacing > Net_Iface, it seems to be leaning towards a requirement. Your question/concern is certainly valid. Rationale: In RFC7217, you want a Net_Iface that is as stable as possible (and the MAC address might not be the best choice in such case). For temporary addresses, as long as Net_Iface uniquely identifies an interface, it's okay. You could certainly use anything (e.g., still use the interface name or interface index) for the generation of temporary addresses. However, if you use the MAC address, one property comes for free: if you happen to implement mac address randomization, you can be assured that whenever you regenerate an IPv6 address (after the mac address has been regenerated), the ipv6 address is going to change. FWIW, so far the I-D does not say much regarding whether you should do mac address randomization or not... > nits: > > - " a > node may want to use only Temporary address (e.g., a temporary > address)." > > This text seemed a little confusing because it seemed the temporary > address text was being repeated. I realised that the capital T > "Temporary" was a special word, perhaps the parenthesis text is > unnecessary here. e.g. > > " a node may want to use only Temporary address ." Oops, this is an editorial error. The original text (previous rev of the I-D) was: While the use of stable addresses (only) or mixed stable and temporary addresses can be desirable in a number of scenarios, there are other scenarios in which, for security and privacy reasons, a node may want to use only non-stable address (e.g., a temporary address). But when we changed the use of "non-stable" to "temporary", the parenthesis remained. We'll fix this. Thanks! > - In the terminology section, it might be worth quoting a few of the > repeatedly used terms from RFC7721 for the convenience of the reader. > "Temporary address" would be an example. Agreed. We'll copy&paste, and provide a reference to the RFC7721. > - Should "stable address" be capitalised throughout as it too is a > term defined in RFC7721? > > - With both "Temporary address" and "temporary address" terms both > being used, it seems like there is some sort of difference between > what these terms mean. It's not really obvious to me what that > difference is. It would seem to me that "Temporary address" (and > "Stable address") should always be being used, as their definitions in > RFC7721 would seem to apply universally. The I-D currently has inconsistent use of Capitalization for these terms, I guess the "Capitalized" version is useful to indicate that we're employing the term defined in RFC7721, rather than simply referring to a property of the address? Thoughts? > - "3.3. Requirements for Temporary IPv6 Addresses > > The requirements for temporary IPv6 addresses are as follows:" > > -"t","+"T" > > "The requirements for Temporary IPv6 addresses are as follows:" Will do. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Mar 16 10:44:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D615F1296CB for ; Thu, 16 Mar 2017 10:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 40NdzEFYvb5p for ; Thu, 16 Mar 2017 10:44:00 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CEE1296DB for ; Thu, 16 Mar 2017 10:44:00 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id v127so45696912qkb.2 for ; Thu, 16 Mar 2017 10:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fZqpBa+gWeVGhYtH+VcdYyO4Ykg+e8z03ZniAnP04X4=; b=PBIJWURcAMnx859iAfS5hmAMXoySobL+I/tMErlPqY2Yrl/CtzCC//PXXJSnSzX2VP XfH+w1X9+4dnXTzzXpt2quQKENEXbaNolXLXpsLyNUZHRXtx5UDoMXqMyGF0ZzoJZJ+F +tp8ycjktkHBHjh0KWE3akH26GviClMkZ7GuMu17xa+q+jgiBvqb+4GEtYqZeiu0zG5H K5jWAjpl/xaGCtYKgG4HMv3ZTvYO2jZx0/RiARM4CW5IAcvwY3S2XFTlbjKAiX+ojJTq 4jSq1zMvyQeAVlMEYjk+hZb7NJfHBDwYUDka+xcYh4zCp3XjnEvL0et4oqZ6bwuceQRW m+gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fZqpBa+gWeVGhYtH+VcdYyO4Ykg+e8z03ZniAnP04X4=; b=PJdM2sETIT3UBAGiqGyV06i0LyyUMxSmPw486Z6m+287pfreAYArePEKkkcuSKiksg 4D7gI8cVPpzugHtVHw+egOrnx9cVnZcnki6TWrx4RxJlHKxVEUVEJ9xlV4ftikJRUI+x Xas872i9IHs1HoTWxRN995+9nv2t8sZgnoeYxF/vF27WSXTdrY3h7U82AU5LPe3zflKI O2I2MBdnm2Fp69sRe3K0dOArI9AVEYvpQBLrBfTS1RQ00tYbJONLVUsWzOXC6zHH1C46 fIDxFf68nolMSn8oVm/AooV594whF1e9OneYzvisBUbg8gJmGGqiHLk1wOqXm+jxYbnd 9MEA== X-Gm-Message-State: AFeK/H24LVqrxVg3hMCPBxBx0eGnCJBdpn6QOigqZ/UUOv3spRUf32qQu+Hy3v/yiheVLDDE3eIttMjrXNbd/A== X-Received: by 10.55.189.130 with SMTP id n124mr9628014qkf.235.1489686239387; Thu, 16 Mar 2017 10:43:59 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Thu, 16 Mar 2017 10:43:58 -0700 (PDT) In-Reply-To: <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 16 Mar 2017 10:43:58 -0700 X-Google-Sender-Auth: DUbfkG8RlgZINl2fCcurrgsjzdM Message-ID: Subject: Re: a draft about on-link and subnet prefixes To: Alexandre Petrescu Cc: IPv6 IPv6 List Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:44:03 -0000 At Thu, 16 Mar 2017 12:02:54 +0100, Alexandre Petrescu wrote: > >> 2. The explanation of the dichotomy onlink|SLAAC should be accompanied > >> by a recommendation of using the shortest plen of the two (even when > >> that plen is not 64) in the Internet routing setup towards that > >> subnet. This is the crux of it. > > > > I'm not sure what this means. > > It means that in order to have distinct onlink|SLAAC prefixes one has to > have distinct routing towards that subnet too. I'm still not sure how to interpret it, but I guess it's related to the discussion on cases of /64 SLLAC subnet and /80 on-link prefixes, below. So I'll defer it to that part. > > It's already covered in > > bit more generalized text: > > > > [...] This means that, for example, if the length of > > interface identifiers for the link is specified as 63, 64, or 65, > > then the SLAAC subnet prefix length must be 65, 64, or 63, > > respectively; otherwise the PIO is ignored for the purpose of SLAAC. > > But this text does not say what is the plen of routes towards that subnet. If "routes towards that subnet" means the SLAAC subnet prefix is to be considered on-link, that's not what the current specs allow. On that point RFC5942 would be a better reference. > >> However, this dichotomy has very many consequences. > >> > >> A number of RFCs and I-Ds misunderstand this dichotomy "on-link"|"SLLAC" > >> and make wrong recommendations. Maybe you want this draft to clarify > >> all these RFCs? > > > > Which RFCs are they? I don't intend to update any existing RFCs in > > this draft, but I could refer to those RFCs as example cases if and > > when I revise the draft. > > I think of the following: RFC4887 "Home network models with NEMO" (it is > a stretch, but HA config is impacted), RFC4903 "Multi-Link Subnet > Issues", RFC7278 "64share", various RFCs of Proxy Mobile IP, and other > recent Internet Drafts. I just took a quick look at RFC7278 (just as an example), but I don't find anything obvious in it that misunderstands the separation of on-link and SLAAC subnet prefixes (it certainly does something awkward if not non-compliant, like re-advertising a prefix learned from a 3GPP interface to a LAN interface, but such oddity is irrelevant to the separation of on-link and SLAAC subnet prefixes). Can you be more specific about specifically which text of RFC7278 misunderstand the separation? > But if nobody allocates two distinct prefixes, what are the users of two > distinct prefixes going to use? > > Or is it just theory? Perhaps. And I don't mind to see a discussion to challenge the need for the separation in the first place in case it's really only in theory. I didn't intend to defend the current specification - I just tried to make them correctly understood. > >>> An on-link prefix could be longer than an SLAAC subnet prefix. For > >>> example, when the latter is 2001:db8:1:2::/64, the former could be > >>> 2001:db8:1:2:3:4::/80. > >> > >> I agree it could be. > >> > >> But in this case, one also must make sure the routing towards that > >> subnet is the SLAAC's /64 (not the 'onlink's /80). > > > > I don't see why. > > Because if the routing is not towards the SLAAC's /64 then the following > bad situation may occur: > > A computer configures an address with SLAAC /64, address that is > actually found on another subnet. At that point, neighbors in that > other subnet will not be able to reach this computer - their ND process > fails and they dont ask their default router. > > In this sense the computer in question forms an address that is actually > not allowed to use, because there is no routing to it. > > On another hand, if the routing towards our subnet where this computer > is found is the /64 then the situation is better. > > onlink /80 > Router -----------Router -------------- Computer > /64 in rt | SLAAC /64 > | > | > +----------(another subnet) ----Neighbor1 > | > +-Neighbor2 In such a case, the admin should not advertise the /80 on-link prefix in the first place. If all hosts under a /64 are expected to communicate directly, the admin should advertise that /64 also as an on-link prefix (in the above diagram we'd also need something other fancy stuff like multi-link subnet, ND-proxy, etc, but that's a different matter). It's just that using different on-link and SLAAC subnet prefixes may not meet a particular operational requirement - it's the admin's responsibility to choose the right tool and configure it correctly. > >> In this case, one also must make sure the routing towards that subnet is > >> the onlink's /48, and not the SLAAC's /64. > > > > Implementation specifics (whether it's implemented as a "route") aside, > > an RFC4861-compliant host implementation should already do so. > > What I am asking stems not from implementation specifics (implemented as > route, or otherwise), but stems from bidirectional reachability > requirements. > > The draft currently talks exclusively what happens on a link, in a > subnet. But it misses to tell that whatever happens on a link, or in a > subnet, must ensure bidirectional rechability to and from the Internet. This is vague and I'm still not sure if I really understand it. But, if you mean that a site using a /48 on-link subnet should advertise that /48 prefix via a routing protocol or something outside of the site, then that's correct. But, to me, that's a totally different topic. -- JINMEI, Tatuya From nobody Thu Mar 16 16:59:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C2E129B69 for ; Thu, 16 Mar 2017 16:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CgjX3Q-AXDhr for ; Thu, 16 Mar 2017 16:59:32 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C172F129717 for ; Thu, 16 Mar 2017 16:59:32 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id x35so51279120qtc.2 for ; Thu, 16 Mar 2017 16:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=YZAz1bNJipv8HHGo+dmF1rdbj59baQen2qsYgLQi7n0=; b=AsKH4ab46iLFXZNDknT3ryZ/Y1vsMpHn0eqxbyoswrT7/rHCu0uucX3PxqswH8ykhv L0bX/RNjEZwNT49U/kgPfIXzKo6HLCWDWQIS/fa37ZW2uK3MyRssEUh9v60zHw/D9Pdw r7YMadN2QV5t63N6//4QU7YlgXLe0G0ckY3+RJZrwGLNtHE7/TdZxN3sYsFPqisXAsqg jRlXWIoiDnnU9zIja6nxZ+L8Ek3dSaeZ/Mki1KxaNE8YJkTN/DtNpqGPnrZznMy6dY21 JK0gqt25jXVez1dGuB2DrfqN815LAc7W7nwi5gB5X9OBt2uca65+MKhPkAYf8k6YbwJI FKrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=YZAz1bNJipv8HHGo+dmF1rdbj59baQen2qsYgLQi7n0=; b=tR4VCDjsHZL31USnh5JHbm+So1Jei0j9gkxOEgl5BurMGqBtU1q+NNSSJf/9kzg31c kSpMWBpQXOsTpe7ov/hTjx88uvgMtgaknaNmD3kmLNVgdNp74xtt9S5ZgswWYc0Nt1OH bhhtybY6MoTGMCfYCp9/E3tp9GT5Wt4/RtN3kZdgkQc2eDPSjMLW8LWarlfQJwDDH5ae DoUPcC6wjdJ47/cyWxhNK6wo61oTYZyTWKjR5P0GLNIWA0TZjniBOGRCvqZSFP+gFAph feSfMBOrakWYax36Cg+fZiD6YdehaWVYw31XltMp8Uhw5wIOthOBjMd0xQgveI1TIJxe Jisg== X-Gm-Message-State: AFeK/H2f5PI5PjDEaw4rrHCmZgfYojN5BAPD89MUNSWylv6DXh2bARzP9Ytc29M8vAaOxQ== X-Received: by 10.237.32.238 with SMTP id 101mr10859399qtb.162.1489708771973; Thu, 16 Mar 2017 16:59:31 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r189sm4749504qkf.58.2017.03.16.16.59.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 16:59:31 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_E20A4A7C-36EA-4D0D-A3D0-6FBCCAAB0E4F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: 6man IETF98 Agenda Message-Id: Date: Thu, 16 Mar 2017 16:59:28 -0700 Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= To: IPv6 List X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 23:59:34 -0000 --Apple-Mail=_E20A4A7C-36EA-4D0D-A3D0-6FBCCAAB0E4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft agenda can be found at https://www.ietf.org/proceedings/98/agenda/agenda-98-6man-01 We tried to accommodate all of the requests we received, hopefully we = did not miss any. Please let us know if that was the case. It is organized in three sections, Working Group drafts, Active = Individual drafts, and New Individual drafts. We priority to the = requests in that order. Active individual drafts are drafts that have = seen active discussion on the IPv6 list, and the New Individual drafts = are ones that are new and/or have not seen a lot of discussion. We also need a minute taker and a jabber scribe. Please volunteer. Thanks, Bob & Ole --Apple-Mail=_E20A4A7C-36EA-4D0D-A3D0-6FBCCAAB0E4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYyybhAAoJEK7rdBF357uo+j0H/0SWN3XCCbO73jIj1qjaCrlN +hyPPn7/jzCh7+f0iZ10IHhAf+yHzObk1b2IWldlnp8AdLT6Ofddgt3qnU/d2y93 GnQvKucFhK4TBfl2wrSgR3etRTVbJpxJqzspqnngE6XqyNbPlwCeBAtM8pVVG20y HkcyFIA4wLC5dVsQ23VRizo2snMLII/fWMzU+Hc/iaonBuMu9nPdOHwzVBmtDt7m pVSitstNzV5Kqkx0TKfGvE2Q3uhxiyUAlmJNiprGCvCcBNx/Piin0qKayQ/h1jic TNYfyyZJPgfcuTTec2Pw0QFDBY39x1R+uy8uWBBFYv95K4KG+O4a9PPsPBI7uNg= =vpmr -----END PGP SIGNATURE----- --Apple-Mail=_E20A4A7C-36EA-4D0D-A3D0-6FBCCAAB0E4F-- From nobody Thu Mar 16 17:03:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E3C129B74 for ; Thu, 16 Mar 2017 17:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 azoBKhIzYIhQ for ; Thu, 16 Mar 2017 17:03:36 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2466129B69 for ; Thu, 16 Mar 2017 17:03:36 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id i34so51580162qtc.0 for ; Thu, 16 Mar 2017 17:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=JOoA01KewilCUCwWAih7Ilnmrv0lxUK1sMRRmT7lRR8=; b=LgtHNRufU1lxClKNjAYmOiAYhJJXPpew/VslOPEqUmKfC40JghjRfF6ztK3m9yAfNT elNqNPmZZMDM8DMrH1j39ztIrRLMbUVXMbi/jfMujw5HoCjt+kZvgMVJ62CZHyPnmIUK XL4lO0/KYWlqoKuhsVzEiXrLAMQkfykd7x1xtWCu5hoKNnppYll572hCsDcHx4l96Ixq jGiBBbS6sXD28l31Hc8ZSTGoQ5TuHSCfRRpkF+lXEqF2Y/LeKDcvKgKPvUa9Rkp/73gy sQFDay37wL9dA6lADLZcy00o0qb8dkBp+r2YXgDfQD5W4osf6auOV00btsCWLA7rFADY 53fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=JOoA01KewilCUCwWAih7Ilnmrv0lxUK1sMRRmT7lRR8=; b=FYXIzsFgbZKXTiUURXLnQRJvCA5BWUfy6HPbtHs05SRx9klZOOY6AkWBoUwm4dlcJc 8mLnJEiVCyPz6utWxagI8NI2JiTxxKLZlgSWXir2Ke5wwWwLTV6dQg9Gc2TO6FARD+5E q7EG+jNue5USVN4lWwV7U1xBdNNsP8EZba/Rm5N/lvxqqnDQwa5Pg8GAPIn68fUNq22h YvBVWMzKO0yoHnrm9EDTzyDOnBGpF6XCAD2nei9xaYpN/twL54z58I3nCwDe8FFRleom qsMWU6L9EdvjlkQ85WZrMt8MnfXecXYaV5xHqB14f1eiHBHA0hQR8EmSQezhGyTwjXYS 19jA== X-Gm-Message-State: AFeK/H0RCv7qPl4HaOG8gcF9lMRBtsxijGyBikq7ZdJcUD2Pi7SDBov8sj62AF0DxDQv2g== X-Received: by 10.237.50.97 with SMTP id y88mr12250135qtd.104.1489709015736; Thu, 16 Mar 2017 17:03:35 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id q31sm4764214qta.22.2017.03.16.17.03.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 17:03:34 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_1EAEF5ED-BE69-4E1A-9F83-455B8945E768"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: 6man IETF98 Agenda (resend w/ correct URL) Message-Id: Date: Thu, 16 Mar 2017 17:03:33 -0700 Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= To: IPv6 List X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 00:03:38 -0000 --Apple-Mail=_1EAEF5ED-BE69-4E1A-9F83-455B8945E768 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft agenda can be found at https://datatracker.ietf.org/meeting/98/agenda/6man/ We tried to accommodate all of the requests we received, hopefully we = did not miss any. Please let us know if that was the case. It is organized in three sections, Working Group drafts, Active = Individual drafts, and New Individual drafts. We priority to the = requests in that order. Active individual drafts are drafts that have = seen active discussion on the IPv6 list, and the New Individual drafts = are ones that are new and/or have not seen a lot of discussion. We also need a minute taker and a jabber scribe. Please volunteer. Thanks, Bob & Ole --Apple-Mail=_1EAEF5ED-BE69-4E1A-9F83-455B8945E768 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYyyfVAAoJEK7rdBF357uoWycH/0Pdsx07DlqK7cqmsm0DFrRX Dfc+IGI0xMP2aVLM/dBuBIAmdadqwSGxnrLocDuM8KIdXYE5waL9D4kSEJTgsTW4 iDl8OcWleAeJGdLaOsZUQ/sLM100rKIIPo9Sf/HDzsizjUsRF4Fbay5W91Z0pleq ydZp3l/0srcfyRZU95D2d7E6kP1zKEGOgewpWcqfOkzwhYiMu5g+hTHowUItyw1E Ie+ta23w2kEhrkDjhyl7B7RLYxkozXrfMz436E/0T5ntyhQIK8SyICW9vyCRwbKV b5EZW2VNWOQzeo3RGT/iGOB2x5lws/fGbkPePkI/JzOWVwo1WIEL0pKbZPZudWM= =HWNW -----END PGP SIGNATURE----- --Apple-Mail=_1EAEF5ED-BE69-4E1A-9F83-455B8945E768-- From nobody Thu Mar 16 17:51:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD6A129B79 for ; Thu, 16 Mar 2017 17:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 17M7WB_uvdhB for ; Thu, 16 Mar 2017 17:51:17 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C6D129B35 for ; Thu, 16 Mar 2017 17:51:17 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1cog6t-0001gE-F3 for ipv6@ietf.org; Fri, 17 Mar 2017 01:51:16 +0100 Received: from internal.xmail07.myhosting.com ([10.5.2.17] helo=xmail07.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cog6s-0005Mt-80 for ipv6@ietf.org; Thu, 16 Mar 2017 20:51:14 -0400 Received: (qmail 6494 invoked from network); 17 Mar 2017 00:51:13 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.159]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Mar 2017 00:51:12 -0000 To: ipv6@ietf.org References: <148942937853.9227.2944252822855237301.idtracker@ietfa.amsl.com> <4deb5200-0f4f-d3d1-b164-e70fabc77d86@si6networks.com> From: Christian Huitema Message-ID: <70057719-4e20-4d71-e72a-caab6d0efe59@huitema.net> Date: Thu, 16 Mar 2017 17:51:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4deb5200-0f4f-d3d1-b164-e70fabc77d86@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: "Recommendation on Temporary IPv6 Interface Identifiers" (revised I-D) (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-01.txt) X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.29) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrHYYTVXlYan2QPMpELk3j4RcOb18WfxGyg6Om6u4YYm+rC/BlViQoZSa1e lw9ROuA5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQ3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0lGBqE9Gg c8Y4ZxuY0/fX17bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/hvxLqd67w5ZW6bZsK3PVhKr5jPEm1FO31NK RBlTUpu1GyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+eHzgtWshl+1i/+vbfwZ46yKe72V7y3QDXL8JTpxprEN X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 00:51:19 -0000 On 3/16/2017 9:35 AM, Fernando Gont wrote: > Hi, Mark, > > Thanks so much for your feedback! Please find my comments in-line... > > > On 03/15/2017 05:19 PM, Mark Smith wrote: >> Hi, >> >> Firstly, I really like this draft. > Thanks! Thanks for the feedback, Mark. As Fernando wrote, we are more than willing to improve the document. The general motivation here is that RFC 4941 was written 10 years ago, and we have learned a thing or two since that. In fact, while the current draft is written as an update to RFC 4941, we are wondering whether it would not be simpler to just evolve the draft into something like 4941bis. Among the dated parts of 4941, the first one is indeed the timing issues that you commented on. 4941 specified a simple periodic assignment. As we explain in the draft, we get better privacy characteristics if the temporary address generation is linked to "privacy events" such as a connection to a new network, a change in a MAC Address, or even a user request to "erase the web history". Keeping the same IID through such event enables "before and after" correlation, and that's not exactly good for privacy. Then, there is the cross-prefix correlation issue. In section 3.3., Generating Temporary Addresses, RFC 4941 specifies that "New temporary addresses MUST be created by appending the interface's current randomized interface identifier to the prefix that was received." That means that if different prefixes are configured, the temporary addresses for all these prefixes will use the same IID. Again, that is not the best way to protect privacy. Besides, 4941 requires running DAD on each temporary address, so there is little reason to mandate a single temporary IID per interface. The algorithm specifies the use of MD5, which is now a bit unfortunate. Using MD5 to generate random numbers in the specified way probably does not pose any serious security issue, but there is a global push to just get rid of MD5 everywhere. And in fact, there is no good reason to specify any particular hash function -- at least, no interoperability issue. SHA256, SHA512 or SHA3 would work just fine. There are probably a couple more details like that. -- Christian Huitema From nobody Thu Mar 16 18:00:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10374129B9B for ; Thu, 16 Mar 2017 18:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xIoLtr4m5s4j for ; Thu, 16 Mar 2017 18:00:28 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D2D129B9A for <6man@ietf.org>; Thu, 16 Mar 2017 18:00:28 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cogFm-0003ab-CT for 6man@ietf.org; Fri, 17 Mar 2017 02:00:27 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cogFg-0007ue-NE for 6man@ietf.org; Thu, 16 Mar 2017 21:00:25 -0400 Received: (qmail 21245 invoked from network); 17 Mar 2017 01:00:19 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.159]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <6man@ietf.org>; 17 Mar 2017 01:00:18 -0000 To: "6man@ietf.org" <6man@ietf.org> References: <148944356914.20433.4232955187735083255.idtracker@ietfa.amsl.com> <258547d4-eb2a-2257-b1a8-d37afcc2abd3@si6networks.com> From: Christian Huitema Message-ID: <2e2670d7-2319-efb8-d4f6-7403a5250e95@huitema.net> Date: Thu, 16 Mar 2017 18:00:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <258547d4-eb2a-2257-b1a8-d37afcc2abd3@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: IPv6 Address Usage Recommendations (revised I-D, Fwd: New Version Notification for draft-gont-6man-address-usage-recommendations-02.txt) X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpT8MD7NvwNY2AVY4/m0+nmRcOb18WfxGyg6Om6u4YYm5Pr7rG4hFWyICv8 chTpqCs5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+g3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK00MOwg390 YmgcgCNK3xHvfbbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/hvxLqd67w5ZW6bZsK3PVhIU0dltf0fLDt1k A1WJznBpGyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+UvKHNDjDnMFd1GXLLtIfqeKe72V7y3QDXL8JTpxprEN X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 01:00:30 -0000 On 3/15/2017 8:00 AM, Fernando Gont wrote: > Folks, > > We've posted a rev of our I-D "IPv6 Address Usage Recommendations". > > It is available at: > > > This one is closely related to draft-gont-6man-non-stable-iids and to > (the recently published) RFC8064. > > Your feedback will be highly appreciated. Let me second that request for feedback. Fernando asked me to work with him on this draft, and I believe that the WG should indeed do some work in that general area. My first concern is that while we do have well specified rules for address selection in RFC 6724, these rules only affect outgoing selection, we do not have any equivalent rule for "listening address selection". The default practice is to have "server apps" listen for all addresses available on all interfaces. That can create quite a few security and privacy issues, which we try to outline in the draft. Despite being in rev 02, this is still an early draft. And it would definitely benefit from some feedback, particularly regarding implementation experience. -- Christian Huitema From nobody Fri Mar 17 06:34:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72A4129431 for ; Fri, 17 Mar 2017 06:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 Usepp2gt6vXD for ; Fri, 17 Mar 2017 06:34:47 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2273912941C for ; Fri, 17 Mar 2017 06:34:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2HDYi8k047608; Fri, 17 Mar 2017 14:34:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4B526203034; Fri, 17 Mar 2017 14:34: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 39997209557; Fri, 17 Mar 2017 14:34:44 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2HDYi6A026018; Fri, 17 Mar 2017 14:34:44 +0100 Subject: Re: a draft about on-link and subnet prefixes To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> Cc: IPv6 IPv6 List From: Alexandre Petrescu Message-ID: Date: Fri, 17 Mar 2017 14:34:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 13:34:49 -0000 Le 16/03/2017 à 18:43, 神明é”哉 a écrit : [...] >>> It's already covered in bit more generalized text: >>> >>> [...] This means that, for example, if the length of interface >>> identifiers for the link is specified as 63, 64, or 65, then the >>> SLAAC subnet prefix length must be 65, 64, or 63, respectively; >>> otherwise the PIO is ignored for the purpose of SLAAC. >> >> But this text does not say what is the plen of routes towards that >> subnet. > > If "routes towards that subnet" means the SLAAC subnet prefix is to > be considered on-link, that's not what the current specs allow. By "routes towards that subnet" I mean the entries in a routing table of a Router that is in the path from the Internet towards that link. > On that point RFC5942 would be a better reference. I read this RFC 5942 "IPv6 Subnet Model". But, just as this draft, this RFC does not talk about the routing table entries presented in the Routers on the path from the Internet towards that link. Just as this draft, that RFC talks only about the Router that is immediately connected to that link. >>>> However, this dichotomy has very many consequences. >>>> >>>> A number of RFCs and I-Ds misunderstand this dichotomy >>>> "on-link"|"SLLAC" and make wrong recommendations. Maybe you >>>> want this draft to clarify all these RFCs? >>> >>> Which RFCs are they? I don't intend to update any existing RFCs >>> in this draft, but I could refer to those RFCs as example cases >>> if and when I revise the draft. >> >> I think of the following: RFC4887 "Home network models with NEMO" >> (it is a stretch, but HA config is impacted), RFC4903 "Multi-Link >> Subnet Issues", RFC7278 "64share", various RFCs of Proxy Mobile IP, >> and other recent Internet Drafts. > > I just took a quick look at RFC7278 (just as an example), but I > don't find anything obvious in it that misunderstands the separation > of on-link and SLAAC subnet prefixes (it certainly does something > awkward if not non-compliant, like re-advertising a prefix learned > from a 3GPP interface to a LAN interface, but such oddity is > irrelevant to the separation of on-link and SLAAC subnet prefixes). I agree. I would say that using 64share is incompatible with the capability of providing separation between onlink and SLAAC prefixes. A prefix that is '64shared' can not be further separated into 'onlink' and a 'SLAAC' prefix. Whereas a /63 prefix (not a 64shared prefix) could be divided into a /64 prefix for SLAAC, and another /64 for onlink determination. Moreover, a prefix allocated with DHCPv6-PD could be divided into a prefix for SLAAC and another for onlink determination. > Can you be more specific about specifically which text of RFC7278 > misunderstand the separation? For example this from RFC7278: > The LAN link is configured as a /64 and the 3GPP radio interface is > configured as a /128. Which one of those two prefixes is the on-link and which is the SLAAC? Maybe neither? Maybe the /64 is for SLAAC on the LAN interface (not on the 3GPP) and it is at the same time "on-link" for same LAN interface? Yet one of the addresses in the /64 is for the 3GPP interface, so it is not the entire /64 that is onlink and SLAAC. Another example is this: > The gateway routes the entire /64 to the UE and does not perform ND > or Neighbor Unreachability Detection (NUD) [RFC4861]. What kind of prefix is that for which there is neither NUD nor ND overall, yet an address is formed on the interface? Is it SLAAC? Is it onlink? Is it neither? >> But if nobody allocates two distinct prefixes, what are the users >> of two distinct prefixes going to use? >> >> Or is it just theory? > > Perhaps. And I don't mind to see a discussion to challenge the need > for the separation in the first place in case it's really only in > theory. I didn't intend to defend the current specification - I > just tried to make them correctly understood. And I appreciate the explanation. I think it is good to have this draft. If someone says again onlink|SLAAC dichotomy requires this or that, then we can come to this draft and clarify whether or not it is so. >>>>> An on-link prefix could be longer than an SLAAC subnet >>>>> prefix. For example, when the latter is 2001:db8:1:2::/64, >>>>> the former could be 2001:db8:1:2:3:4::/80. >>>> >>>> I agree it could be. >>>> >>>> But in this case, one also must make sure the routing towards >>>> that subnet is the SLAAC's /64 (not the 'onlink's /80). >>> >>> I don't see why. >> >> Because if the routing is not towards the SLAAC's /64 then the >> following bad situation may occur: >> >> A computer configures an address with SLAAC /64, address that is >> actually found on another subnet. At that point, neighbors in >> that other subnet will not be able to reach this computer - their >> ND process fails and they dont ask their default router. >> >> In this sense the computer in question forms an address that is >> actually not allowed to use, because there is no routing to it. >> >> On another hand, if the routing towards our subnet where this >> computer is found is the /64 then the situation is better. >> >> onlink /80 Router -----------Router -------------- Computer /64 in >> rt | SLAAC /64 | | +----------(another subnet) >> ----Neighbor1 | +-Neighbor2 > > In such a case, the admin should not advertise the /80 on-link > prefix in the first place. If all hosts under a /64 are expected to > communicate directly, the admin should advertise that /64 also as > an on-link prefix (in the above diagram we'd also need something > other fancy stuff like multi-link subnet, ND-proxy, etc, but that's a > different matter). It's just that using different on-link and > SLAAC subnet prefixes may not meet a particular operational > requirement - it's the admin's responsibility to choose the right > tool and configure it correctly. I agree. And for 64bit IIDs the correct configuration is to have /64 in the rt table, and /64 as both SLAAC and as onlink prefix. >>>> In this case, one also must make sure the routing towards that >>>> subnet is the onlink's /48, and not the SLAAC's /64. >>> >>> Implementation specifics (whether it's implemented as a "route") >>> aside, an RFC4861-compliant host implementation should already >>> do so. >> >> What I am asking stems not from implementation specifics >> (implemented as route, or otherwise), but stems from bidirectional >> reachability requirements. >> >> The draft currently talks exclusively what happens on a link, in a >> subnet. But it misses to tell that whatever happens on a link, or >> in a subnet, must ensure bidirectional rechability to and from the >> Internet. > > This is vague and I'm still not sure if I really understand it. But, > if you mean that a site using a /48 on-link subnet should advertise > that /48 prefix via a routing protocol or something outside of the > site, then that's correct. I agree and I set it aside for another thread. This is what is needed when considering dichotomy of onlink|SLAAC prefixes. ND and SLAAC allow for different plens for onlink determination and SLAAC. But routing must use the shortest of the two. And it is the shortest of the two that constitutes a problem at this time: it is the "/64"; those who establish routes dont make shorter than /64. Even if we have a concept of dichotomy onlink|SLAAC in a subnet, the admins of the Routers towards that subnet have a problem making shorter-than-64 plen routes. Simply because there is a dichotomy does not make people making routes make shorter-than-64 plen routes. _If_ we said that the dichotomy onlink|SLAAC was the possibility to have /48 as onlink and /60 as SLAAC, then the people making routes would take the smallest (/48) and make a /48 route towards the subnet. That comes down to the following paragraph in your draft: > If a link-type specification defines the interface identifier length > to be 64 bits, the SLAAC subnet prefix must be 128 - 64 = 64 bits. should rather say "the SLAAC subnet prefix could be for example 63bit". (that's how people do when specifying the fe80:: could be fe80:://10 in 4291 but for Ethernet to be fe80::/64 in 2464) Also in the place of this draft that says: > For example, when the latter is 2001:db8:1:2::/64, ^^^^ make it 63 For you, it may be totally clear, but for others it's the 64 that is too obvious. Especially for the people wondering what to put in the routing tables. Alex > But, to me, that's a totally different topic. > > -- JINMEI, Tatuya > From nobody Fri Mar 17 07:02:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56EB12943C for ; Fri, 17 Mar 2017 07:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 qbtS3atyPktF for ; Fri, 17 Mar 2017 07:02:38 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B90012943D for ; Fri, 17 Mar 2017 07:02:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2HE2ZvQ006609; Fri, 17 Mar 2017 15:02:35 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DBC812099DB; Fri, 17 Mar 2017 15:02:35 +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 D48FD2099CE; Fri, 17 Mar 2017 15:02:35 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2HE2Zsu028784; Fri, 17 Mar 2017 15:02:35 +0100 Subject: Re: a draft about on-link and subnet prefixes - onlink|SLAAC and larger than 63bit IIDs To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> Cc: IPv6 IPv6 List From: Alexandre Petrescu Message-ID: <80954d75-d07a-efe5-5906-dba8976dc563@gmail.com> Date: Fri, 17 Mar 2017 15:02:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:02:40 -0000 Le 16/03/2017 à 18:43, 神明é”哉 a écrit : [...] > But, if you mean that a site using a /48 on-link subnet should > advertise that /48 prefix via a routing protocol or something > outside of the site, then that's correct. But, to me, that's a > totally different topic. Let me say it is the same topic. Because at a point in the draft you say: > For example, the fact that the length of an on-link prefix can be > 48, 80 or other bits is not contradictory to the fact that [RFC4291] > states the interface identifiers (and therefore subnet) of a > particular set of addresses are 64 bits in length. Only SLAAC > subnet prefixes have an indirect implication with the addressing > architecture as noted in Section 2. To stress this agreement, it is possible to write it in relationship to 63. We agreed earlier that what's important for routing is the shortest prefix between the onlink and the SLAAC prefix. The dichotomy onlink|SLAAC could support a recommendation of larger than 63bit IIDs _only_ if the onlink prefix were shorter than or equal to 63. Something like: "When the dichotomy onlink|SLAAC is in place [ref], and the onlink prefix is shorter than or equal to 63, the Interface ID of unicast addresses can be longer than 63; also see IPv6-over-foo refs". Alex From nobody Fri Mar 17 07:18:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B643A12944E for ; Fri, 17 Mar 2017 07:18:39 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 D636WJ54WWmd for ; Fri, 17 Mar 2017 07:18:38 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212BE12944D for ; Fri, 17 Mar 2017 07:18:38 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id w124so24417724itb.1 for ; Fri, 17 Mar 2017 07:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=CA2C53Xnkam0/PkRmGaAbruU/9MD4d8+1EbD0cM8A80=; b=A3MHynQhllAGKsz8o3FDczZ2rw2rs2l63G+2/xVKLe+7ayDAtIM2Yfg+owkqM6YgqF eNcPNVvMv/Gu44UTCx6KW5fqN93oPXIHA0Fe6fGMGB/hxY4kDajPdbELCicH+y4RtQ/b HrbHTuPB5K0KTLpcdQGoVu1OE+vx/3IrME4ZW9AOGMH+ie9hnNf3OxEzzXm5fwRPQn1f 08EeUOuDX8y9/72rmIjXDlUKE1ZTnQ/cX0oDIxWrBT4yJCQUI7PN96WgMipVLGwXFjRh 6UA1GeLC8OQBl7iTGwCMDAE56Hv7BHJktY3Jvi2bwNJ+55U5Z9AKZs33diLS3m7ZBH38 1viA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=CA2C53Xnkam0/PkRmGaAbruU/9MD4d8+1EbD0cM8A80=; b=RY56l8f66Qv+T1QEMj0pvojD+1h+hCQf3drHiWd20KOZTQHHIdmwH14N23SYGIcy1K C9YcTBv6TDscP1ctB/ta6lc5O3Cw1RM2jBa9T806Mki4ALtiu/JlRsjWniW8k48Rn+Fj ljzBB54jEzzWOnOmzfRPOApG1Jfkr/96RUiXpaVIt2AKx97F3M+KrulHxb8uqdMB8XV7 IzkM4quzloncrguXdorYGY3amuQM/VuiSZK5O5dit2DPZOjzlj7ASxj/RK+SfATVpIBH vYfjlfSlSBA6lnX9jG75I1B+oJDig4Jdxye+Tk9ZnJ4tmaDZGhPgHwTG84NJ+rxwq+JC SczQ== X-Gm-Message-State: AFeK/H2pOntr+735xtZT58CrMAf1LhGX5NyFMHNvbZyjhC8cqEAG/Ap3fEjntfseBKrV5Q== X-Received: by 10.36.218.5 with SMTP id z5mr2854507itg.79.1489760234307; Fri, 17 Mar 2017 07:17:14 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id m63sm1722660ioa.15.2017.03.17.07.17.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 07:17:13 -0700 (PDT) Subject: Re: a draft about on-link and subnet prefixes - onlink|SLAAC and larger than 63bit IIDs To: ipv6@ietf.org References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> <80954d75-d07a-efe5-5906-dba8976dc563@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1ab36b80-ac73-abf2-0b6e-9f7e047d4963@gmail.com> Date: Sat, 18 Mar 2017 03:17:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <80954d75-d07a-efe5-5906-dba8976dc563@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:18:40 -0000 On 18/03/2017 03:02, Alexandre Petrescu wrote: > Le 16/03/2017 =C3=A0 18:43, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3=A9= crit : > [...] >> But, if you mean that a site using a /48 on-link subnet should >> advertise that /48 prefix via a routing protocol or something >> outside of the site, then that's correct. But, to me, that's a >> totally different topic. >=20 > Let me say it is the same topic. >=20 > Because at a point in the draft you say: >> For example, the fact that the length of an on-link prefix can be >> 48, 80 or other bits is not contradictory to the fact that [RFC4291] >> states the interface identifiers (and therefore subnet) of a >> particular set of addresses are 64 bits in length. Only SLAAC >> subnet prefixes have an indirect implication with the addressing >> architecture as noted in Section 2. >=20 > To stress this agreement, it is possible to write it in relationship to= 63. >=20 > We agreed earlier that what's important for routing is the shortest=20 > prefix between the onlink and the SLAAC prefix. >=20 > The dichotomy onlink|SLAAC could support a recommendation of larger tha= n > 63bit IIDs _only_ if the onlink prefix were shorter than or equal to 63= =2E >=20 > Something like: > "When the dichotomy onlink|SLAAC is in place [ref], and the onlink > prefix is shorter than or equal to 63, the Interface ID of unicast > addresses can be longer than 63; also see IPv6-over-foo refs". Why would you ever need to write that? *By definition*, (prefix length) += (IID length) =3D=3D 128. The so-called "dichotomy" doesn't affect this identity at all. Brian From nobody Fri Mar 17 07:58:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF49A129457 for ; Fri, 17 Mar 2017 07:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 whCgJZDSw14Y for ; Fri, 17 Mar 2017 07:58:11 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C9912944D for ; Fri, 17 Mar 2017 07:58:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2HEw984042571 for ; Fri, 17 Mar 2017 15:58:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 64054209F8B for ; Fri, 17 Mar 2017 15:58:09 +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 55C7D209BE8 for ; Fri, 17 Mar 2017 15:58:09 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2HEw8JQ015961 for ; Fri, 17 Mar 2017 15:58:09 +0100 Subject: Re: a draft about on-link and subnet prefixes - onlink|SLAAC and larger than 63bit IIDs To: ipv6@ietf.org References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> <80954d75-d07a-efe5-5906-dba8976dc563@gmail.com> <1ab36b80-ac73-abf2-0b6e-9f7e047d4963@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 17 Mar 2017 15:58:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1ab36b80-ac73-abf2-0b6e-9f7e047d4963@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:58:13 -0000 Le 17/03/2017 à 15:17, Brian E Carpenter a écrit : > On 18/03/2017 03:02, Alexandre Petrescu wrote: >> Le 16/03/2017 à 18:43, 神明é”哉 a écrit : [...] >>> But, if you mean that a site using a /48 on-link subnet should >>> advertise that /48 prefix via a routing protocol or something >>> outside of the site, then that's correct. But, to me, that's a >>> totally different topic. >> >> Let me say it is the same topic. >> >> Because at a point in the draft you say: >>> For example, the fact that the length of an on-link prefix can >>> be 48, 80 or other bits is not contradictory to the fact that >>> [RFC4291] states the interface identifiers (and therefore subnet) >>> of a particular set of addresses are 64 bits in length. Only >>> SLAAC subnet prefixes have an indirect implication with the >>> addressing architecture as noted in Section 2. >> >> To stress this agreement, it is possible to write it in >> relationship to 63. >> >> We agreed earlier that what's important for routing is the shortest >> prefix between the onlink and the SLAAC prefix. >> >> The dichotomy onlink|SLAAC could support a recommendation of larger >> than 63bit IIDs _only_ if the onlink prefix were shorter than or >> equal to 63. >> >> Something like: "When the dichotomy onlink|SLAAC is in place [ref], >> and the onlink prefix is shorter than or equal to 63, the Interface >> ID of unicast addresses can be longer than 63; also see >> IPv6-over-foo refs". > > Why would you ever need to write that? *By definition*, (prefix > length) + (IID length) == 128. prefix len + IID len == 128 does not mean a certain part must be 64, and that is good. It does however mean that when IID len is 63 the prefix len must be 65; that is not good because it does not consider "dichotomy" between onlink prefix and SLAAC prefix. > The so-called "dichotomy" doesn't affect this identity at all. The "dichotomy" concept implies that if the IID is 65, the SLAAC prefix must be 63 yet the onlink prefix could be 60. I.e. onlink plen < SLAAC plen && SLAAC plen + IIDlen == 128. Alex > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Mar 17 10:07:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440CC1294D7; Fri, 17 Mar 2017 10:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ci80OPErU3q3; Fri, 17 Mar 2017 10:06:52 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52BF1294E2; Fri, 17 Mar 2017 10:06:51 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id p64so69590993qke.1; Fri, 17 Mar 2017 10:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=huimbzT9igR/bgBFRaprpyktSNkywhaUOls6goEODII=; b=aYvZh/NEigMsn21ealOIviDnh2Jw4bqAs7w8ekDpX4CjYBgOzZ0qHKaQMvyxi0g04A goucK6da+ruFduj63TCb+vVC3iyY+x3sW4QPXC2UD79tstsH7g0f4biSWdos1REoGvyz xGBsEExDluTsw/1vSkRmpQnjBRVUpwXkhV7PR7Ke+nkbDtXOUD+RWpb0AY3YJ9i5lU2s geLemNQdnXdP9c1411eDsLK4M8AGNj1ljIiJiPBdqM2ffceClvTrUOKqsaZStlu3XdTW AQF8PQUHx23mLYxTIzdjfUl2YXPJN0t5n9YhoMwujynTtHi8m7D8j89F1BZJPId88CwL SiBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=huimbzT9igR/bgBFRaprpyktSNkywhaUOls6goEODII=; b=L5O0tEJnOwnRlKJchCNllTxI4BaBcD4XobYSAflDLWa5DreWp9+SW3lvm62rpyzvwZ Kt9FYexMhYGNMURznwgQ0xJy2baTkqcEwXIBVGhJKJIVweAY4vIAwe/X4dF8mmndFARN xxZjSZVtZtT4qa6oBSUxbUxftie9GJRtCs+bQJHuZ+RyUW5N5BlOHfMOvyFqXeM39xSs Ll7bp+daazwdku8ybtG3yEJsF1VJgu5g+WOhSuXTcHQFpwZzmlMOVUiMNqmRV5K9eojh 5dM0u3mI0PLQG0Xhh8Wv1T3+thV9i+0PNKSRDWmP7Ox852HPapMIfGelHOZULTVcBh2B iVPA== X-Gm-Message-State: AFeK/H3V3G8e2xy998Emhi7u0NOfwadGysqnXQ3ZJOxSwFe0vvYJ9XE5itZadPACt06/7QMAF/VXDPbVjGH44A== X-Received: by 10.55.18.158 with SMTP id 30mr15235848qks.123.1489770410840; Fri, 17 Mar 2017 10:06:50 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.42.181 with HTTP; Fri, 17 Mar 2017 10:06:50 -0700 (PDT) In-Reply-To: References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> From: Robert Raszuk Date: Fri, 17 Mar 2017 18:06:50 +0100 X-Google-Sender-Auth: yQdN172Lkto47_f-fiWIUpf3rA4 Message-ID: Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: "Leddy, John" Cc: Stewart Bryant , Tim Chown , Brian E Carpenter , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a1146f48222a79f054af03437 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:06:54 -0000 --001a1146f48222a79f054af03437 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, This is very interesting thread indeed. I think header insertion at *any* network element be it host, router, service chain device is highly desired. IPv6 deployments will be much more successful if we clear any obstacles which otherwise prevent it from delivering required by customers and operators functionality. And I would state that this should be not only limited to one's own IGP or BGP domain. It should be legal Internet wide. Today Internet as a entire system lacks tools to accomplish path engineering, fast connectivity restoration, p2mp delivery of content etc ... Some of those are possible with MPLS based tools however as we all know MPLS has no NNI and does not really work across domains. Here we stand very close to have a chance to fix it. And if one would forbid by spec the header insertion performed by network elements what's the alternative ... IPv6 in IPv6 encapsulation which may suffer with even more overhead yet will still require IANA allocation of SRH type as well as TLV codepoints as effectively encapsulating network element will be acting as IPv6 sender. Concluding I do hope that we can try to collectively make IPv6 protocol flexible enough to satisfy customer and operator's requirements what in turn will enrich and speed up IPv6 global adoption. Kind regards, Robert. On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John wrote= : > Thanks Stewart, > > This really supports my point and hopefully not the intent or result of > the discussions here. > > We are trying to work through the IETF process to come up with standards > and solutions that address real operational challenges faced in > deployments. For operators, dealing with legacy and migrations are a big > challenge. > > Wishing these issues away and as a result having non-standard > functionality in =E2=80=9Cmiddle boxes=E2=80=9D that are ignored in the a= rchitecture is not > productive. NATs are a way of life, dark space is being deployed by othe= r > operators, =E2=80=9CCloud=E2=80=9D/NFV/ServiceChaining are active areas; = tunnels, tunnels > everywhere - PMTU is always an issue. =E2=80=9CTurtles and Tunnels all t= he way > down=E2=80=9D. > > We are very aggressively migrating to a V6 infrastructure, but there is a > large amount of old legacy systems/applications/services that need to be > addressed. At the same time the allure of =E2=80=9CCloud=E2=80=9D attrac= ts systems that > should never be moved without being re-architected and the virtualization > environments fully supporting V6 (both Vendors and OpenSource) =E2=80=93 = but they > do move and vendors help make that possible. > > Hopefully we can keep the discussions going and keep tools available unti= l > we know we have solutions to deal all the activity happening outside a > clean end-to-end Architecture, > > John > > > > On 3/16/17, 6:44 AM, "Stewart Bryant" wrote: > > > In another form, the answer to John is that there are no protocol > police, > > so what consenting adults do inside their own networks simply isn't > an > > issue that an Internet-wide spec can or should address. > > That is not quite true, the inability to gain an IANA allocated > codepoint can make long > term private deployments very difficult, either for the protocol > squatting on a codepoint > because they could not get one allocated, or to the deployment of a n= ew > protocol > legitimately allocated a conflicting codepoint. > > - Stewart > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a1146f48222a79f054af03437 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    All,

    =
    This is very interesting thread indeed.=C2=A0

    I think header insertion at *any= * network element be it host, router, service chain device is highly desire= d. IPv6 deployments will be much more successful if we clear any obstacles = which otherwise prevent it from delivering required by customers and operat= ors functionality.=C2=A0

    And I would state that this should be not only limited to one's own = IGP or BGP domain. It should be legal Internet wide.=C2=A0

    Today Internet as a entire system lac= ks tools to accomplish path engineering, fast connectivity restoration, p2m= p delivery of content etc ... Some of those are possible with MPLS based to= ols however as we all know MPLS has no NNI and does not really work across = domains. Here we stand very close to have a chance to fix it.=C2=A0

    And if one would forbid by sp= ec the header insertion performed by network elements what's the altern= ative ... IPv6 in IPv6 encapsulation which may suffer with even more overhe= ad yet will still require IANA allocation of SRH type as well as TLV codepo= ints as effectively encapsulating network element will be acting as IPv6 se= nder.

    Concluding I do= hope that we can try to collectively make IPv6 protocol flexible enough to= satisfy customer and operator's requirements what in turn will enrich = and speed up IPv6 global adoption.

    Kind regards,
    Robert.


    On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John <= John_Leddy@comc= ast.com> wrote:
    Thanks Stew= art,

    This really supports my point and hopefully not the intent or result of the= discussions here.

    We are trying to work through the IETF process to come up with standards an= d solutions that address real operational challenges faced in deployments.= =C2=A0 For operators, dealing with legacy and migrations are a big challeng= e.

    Wishing these issues away and as a result having non-standard functionality= in =E2=80=9Cmiddle boxes=E2=80=9D that are ignored in the architecture is = not productive.=C2=A0 NATs are a way of life, dark space is being deployed = by other operators, =E2=80=9CCloud=E2=80=9D/NFV/ServiceChaining are active = areas; tunnels, tunnels everywhere - PMTU is always an issue.=C2=A0 =E2=80= =9CTurtles and Tunnels all the way down=E2=80=9D.

    We are very aggressively migrating to a V6 infrastructure, but there is a l= arge amount of old legacy systems/applications/services that need to be add= ressed.=C2=A0 At the same time the allure of =E2=80=9CCloud=E2=80=9D attrac= ts systems that should never be moved without being re-architected and the = virtualization environments fully supporting V6 (both Vendors and OpenSourc= e) =E2=80=93 but they do move and vendors help make that possible.

    Hopefully we can keep the discussions going and keep tools available until = we know we have solutions to deal all the activity happening outside a clea= n end-to-end Architecture,

    John



    On 3/16/17, 6:44 AM, "Stewart Bryant" <stewart.bryant@gmail.com> wrote:

    =C2=A0 =C2=A0 > In another form, the answer to John is that there are no= protocol police,
    =C2=A0 =C2=A0 > so what consenting adults do inside their own networks s= imply isn't an
    =C2=A0 =C2=A0 > issue that an Internet-wide spec can or should address.<= br>
    =C2=A0 =C2=A0 That is not quite true, the inability to gain an IANA allocat= ed
    =C2=A0 =C2=A0 codepoint can make long
    =C2=A0 =C2=A0 term private deployments very difficult, either for the proto= col
    =C2=A0 =C2=A0 squatting on a codepoint
    =C2=A0 =C2=A0 because they could not get one allocated, or to the deploymen= t of a new
    =C2=A0 =C2=A0 protocol
    =C2=A0 =C2=A0 legitimately allocated a conflicting codepoint.

    =C2=A0 =C2=A0 - Stewart







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

    --001a1146f48222a79f054af03437-- From nobody Fri Mar 17 14:12:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178A312957C for ; Fri, 17 Mar 2017 14:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FH7k3zTBpo9y for ; Fri, 17 Mar 2017 14:12:48 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42667129579 for ; Fri, 17 Mar 2017 14:12:48 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id p64so74715993qke.1 for ; Fri, 17 Mar 2017 14:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QWf+x+x6oCyjFwa7J5ZweptLr7aEdLGOi1W1Ky/Qw0U=; b=lhg9JAxuMb/L+ZDZJfLKgvLeQIoJ2tc9ztLlqwpL3CoB1stN3eE6DQG7mjRls/Fzgt Ly3w4lN4x9DEJAkZ3TTNnrBNPPD3x78mDlQSZ6JFe32eQzhnAtS2HNu4NTVmDA3TEiEk vY0tzy6AedOoVHmvOPQ2IUeKhkKlegDcRUZDreKm8L3wvyedtCv3n/pyx6yvA5M5ULyL 9qHfX4OhxsDTwUiOz9elTHD/vp1CGAi8zlwlAB+uoU/f4GMe9nLSIpGUAsysYQ+iLqGx yZpfRLiY550/tayvR0PIvzifTxppGJrVC8vqbVfYEUBgIV1kkc2YDLoqq118XPelYU0M mu5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QWf+x+x6oCyjFwa7J5ZweptLr7aEdLGOi1W1Ky/Qw0U=; b=qVFDTd4U6b8GOCKMavHy//+wbIpWMMkL11fmUcaFSPekPC7cv8saB1iUn1PjYTv16O 867PzUOtEP1qUYK3l4C+MoOuqoxXtNOEhCMDrIgXxwQHXKe23rNrN/Ut0mSQMkIPUOzr Ndh/jC0cwvS5Qe6T4QnB7LvJ5OCm/IlVidBo4MBOmfpFLXZKB+EisZxjAZk/M44BP1gY iBTE+OVuaa+F3lhGy2llgE9Lnxf+x+uZ564NUqtlBCMTTQH4G/XzI+MHkK3/+hCl+zhJ Za8FbBxhTq449/LPQMnqBNiHx0dVn60FzMJcwsv+adst1UB9v9BMwLtS1WoinjUimK+r Ud2A== X-Gm-Message-State: AFeK/H12ogKKlgGyuRrpgyFoHHcm+9fgU0ZKq5yAp3cFN9VkKf3tz9aAWPVlg5ACC6yCYY8B13/DSq67RfHqUQ== X-Received: by 10.55.189.130 with SMTP id n124mr15882811qkf.235.1489785167018; Fri, 17 Mar 2017 14:12:47 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Fri, 17 Mar 2017 14:12:46 -0700 (PDT) In-Reply-To: References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 17 Mar 2017 14:12:46 -0700 X-Google-Sender-Auth: JkNSdvEK-MerRh2m0zGiOqhGNFc Message-ID: Subject: Re: a draft about on-link and subnet prefixes To: Alexandre Petrescu Cc: IPv6 IPv6 List Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 21:12:50 -0000 At Fri, 17 Mar 2017 14:34:35 +0100, Alexandre Petrescu wrote: > >>> [...] This means that, for example, if the length of interface > >>> identifiers for the link is specified as 63, 64, or 65, then the > >>> SLAAC subnet prefix length must be 65, 64, or 63, respectively; > >>> otherwise the PIO is ignored for the purpose of SLAAC. > >> > >> But this text does not say what is the plen of routes towards that > >> subnet. > > > > If "routes towards that subnet" means the SLAAC subnet prefix is to > > be considered on-link, that's not what the current specs allow. > > By "routes towards that subnet" I mean the entries in a routing table of > a Router that is in the path from the Internet towards that link. I now understand you're more concerned about those configuration matters. But I have to say that's out of scope of my draft. It basically talks about host behaviors regarding on-link and subnet prefixes. You may not like the scope, but I have no plan to broaden it to that direction (I basically want to keep it focused). If you think that's an important topic, my last word on that point in this thread is this famous phrase: feel free to write your own draft on that topic. (Below I'm basically skipping points relevant to this particular point.) > > I just took a quick look at RFC7278 (just as an example), but I > > don't find anything obvious in it that misunderstands the separation > > of on-link and SLAAC subnet prefixes (it certainly does something > > awkward if not non-compliant, like re-advertising a prefix learned > > from a 3GPP interface to a LAN interface, but such oddity is > > irrelevant to the separation of on-link and SLAAC subnet prefixes). > > I agree. > > I would say that using 64share is incompatible with the capability of > providing separation between onlink and SLAAC prefixes. A prefix that > is '64shared' can not be further separated into 'onlink' and a 'SLAAC' > prefix. > > Whereas a /63 prefix (not a 64shared prefix) could be divided into a /64 > prefix for SLAAC, and another /64 for onlink determination. > > Moreover, a prefix allocated with DHCPv6-PD could be divided into a > prefix for SLAAC and another for onlink determination. I don't see how this is relevant to this draft. > > Can you be more specific about specifically which text of RFC7278 > > misunderstand the separation? > > For example this from RFC7278: > > The LAN link is configured as a /64 and the 3GPP radio interface is > > configured as a /128. This behavior (using an RA on an interface/link than the received one, re-advertising a received RA on the other link) itself is already quite peculiar, but I still don't see confusion between on-link and SLAAC subnet prefixes here. > Which one of those two prefixes is the on-link and which is the SLAAC? > Maybe neither? Ignoring the peculiarity, the UE performs SLAAC with the received /64 prefix and generates a 128-bit IPv6 address 2001:db8:ac10:f002:1234:4567:0:9. So this /64 is an SLAAC subnet prefix. The /128 notation simply means it's a 128-bit IPv6 address. When re-advertising the /64 to the LAN interface, while it's not really clear from the RFC text itself, but I guess it usually has both the L and A flags set, so they would be used both as an SLAAC subnet and on-link prefixes. > Another example is this: > > The gateway routes the entire /64 to the UE and does not perform ND > > or Neighbor Unreachability Detection (NUD) [RFC4861]. > > What kind of prefix is that for which there is neither NUD nor ND > overall, yet an address is formed on the interface? Is it SLAAC? Is it > onlink? Is it neither? neither. > _If_ we said that the dichotomy onlink|SLAAC was the possibility to have > /48 as onlink and /60 as SLAAC, then the people making routes would take > the smallest (/48) and make a /48 route towards the subnet. > > That comes down to the following paragraph in your draft: > > If a link-type specification defines the interface identifier length > > to be 64 bits, the SLAAC subnet prefix must be 128 - 64 = 64 bits. > > should rather say "the SLAAC subnet prefix could be for example 63bit". It couldn't, unless we update RFC4862 as such. I don't even understand how the external route setup affects the length of interface identifiers, but even if there's some sensible explanation of it, that doesn't change the fact that RFC4862 doesn't allow an SLAAC subnet prefix to be other than 64 when the length of IID is 64. If you don't like the current protocol limitation, that's fine - please write a new proposal to update RFC4862. But that's out of scope of this draft: it only explains what's current specified without stating that's good or bad. -- JINMEI, Tatuya From nobody Fri Mar 17 14:39:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C111295EB for ; Fri, 17 Mar 2017 14:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 43nFbdbncLCJ for ; Fri, 17 Mar 2017 14:39:16 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B149120025 for ; Fri, 17 Mar 2017 14:39:16 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id i34so73305774qtc.0 for ; Fri, 17 Mar 2017 14:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=f3Tb0qXWa63kCXjMB8SIe+5mFYE16OrK3CuAzRwaaBk=; b=XDRveQuDdjDqEsZInvxn3qF9myEBD8NeRMW8hYFQ4UeEp2hcNxYOwSUVBy7JRHi6K/ 9Jatt/Ldhxn/TJ2i0jeI3VuhKoSeG8hyrMW2zs72WrAvVw0ufaZpophmlzDsp749KTeu JfoNK2Ur0cwRe1sPE6IaxND+vE4zNKeUhW8ckZNW6nGmJe1vzS5nYzEpJrg6dcyCpBuo GDSZR8T9DFQmA77e+/oOp6E6vz0ayzkQtT1sWweWI0zT+C7BmjbEkWL52KlEAEs2FOUw W3IwAW/M7vUTL9QdmMksUtLX27gtm4pHmIN0D14yQMBdBVW8VT4G1D0ECfWSwNQEfia1 03ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=f3Tb0qXWa63kCXjMB8SIe+5mFYE16OrK3CuAzRwaaBk=; b=Pd2SG1995iYZTZ+uwI2eK/huh4BsBS5+QQgURF69QIuIlHoc5cRmakSYyipcFunlxb Hle6bcD8BEZ9dhY0NvgjwSVePWtgWaEh1SIHHxi0Edh01g8ARawhtgRoqUuTZ8rmRL8e YMtNQXhSUmXTA1bifnJVVwFnyNGBFTgOdPRpLTuIe0u4plEekGW6Cnm9+aG09z5Y/BAT NpsY552m6DfVYHyqHPKCf/3HWIJhdGyYWd5L+TaHm0rooj17fjMZ+lA/X7JCYjWjwJ9F fHFJlGGK6l0GO94xhV+ALrAwj+26+asOJRJi9WIjNIzho5elS48GfTAIb/Ue+53/vXQ5 xI8w== X-Gm-Message-State: AFeK/H1KFwbzmYyi7zGPGx8426aEv/iSiMQfT9YOBxJYYntXx1Ol40zq83ItN7Zwido4iNP9cDo0zbrym7gJVg== X-Received: by 10.200.42.151 with SMTP id b23mr15512916qta.163.1489786755069; Fri, 17 Mar 2017 14:39:15 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Fri, 17 Mar 2017 14:39:14 -0700 (PDT) In-Reply-To: References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> <80954d75-d07a-efe5-5906-dba8976dc563@gmail.com> <1ab36b80-ac73-abf2-0b6e-9f7e047d4963@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 17 Mar 2017 14:39:14 -0700 X-Google-Sender-Auth: OCEF2UzzJIDEm8KQmHiQSO2YHTg Message-ID: Subject: Re: a draft about on-link and subnet prefixes - onlink|SLAAC and larger than 63bit IIDs To: Alexandre Petrescu Cc: IPv6 IPv6 List Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 21:39:18 -0000 At Fri, 17 Mar 2017 15:58:00 +0100, Alexandre Petrescu wrote: > It does however mean that when IID len is 63 the prefix len must be 65; To be very precise: when IID len is 63, an "SLAAC subnet" prefix len must be 65 (but an on-link prefix len doesn't have to be so). > that is not good because it does not consider "dichotomy" between onlink > prefix and SLAAC prefix. I don't understand what this "consider" means, but the combination of IID len=63, SLAAC subnet prefix len=65, on-link prefix len=60 is totally valid (whether or not it's useful in practice). That's basically all my draft tries to explain. > > The so-called "dichotomy" doesn't affect this identity at all. > > The "dichotomy" concept implies that if the IID is 65, the SLAAC prefix > must be 63 yet the onlink prefix could be 60. Right, and that's valid as noted above. I'm feeling I now have to give up understanding what you're trying to say...I'll basically stop responding at this point. -- JINMEI, Tatuya From nobody Fri Mar 17 14:56:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA2D12961E; Fri, 17 Mar 2017 14:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AwfqNDeAW8SS; Fri, 17 Mar 2017 14:56:35 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7CE129626; Fri, 17 Mar 2017 14:56:34 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id y76so75354600qkb.0; Fri, 17 Mar 2017 14:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aaDJaIdB3AmHu1Z0+1Tg1YVMA1lfCjrYd7zUyOJbwZs=; b=DQVLFA6zli2AgkEM9gDRGrhoGm8SjqiHqIoz23E5IdvxlrN0mf1k2Drlb/jhEQyEFq 686tqSwuS3/8mQnO74j5mXiWqjzT4GKT4f2dKN8G2Mgn0L2QuB2QUtaMi5hhmLySo59G /GKJwoFn8ESN45IqPc8a0yTcZy4FFvlUU1J9TxMOk86N8BKlEVvWXhQRAEBKRktjx/WM MKNHZRUVg5Re424+ry7tFthq+u/gxw9isYZflmdR6xqxmVjgqj1oju5FbrNoyhy+WSdU f7gA3Sq/o/nDc9rWf/MDBZ6WTQ1+hFW+5r4xgA0amcYJQH6qq04AjNQ/2VJAwHDJchWk 3Z9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aaDJaIdB3AmHu1Z0+1Tg1YVMA1lfCjrYd7zUyOJbwZs=; b=VI0rG+Uiyds0uklVTFeLeInJeVX9Vyb+CBjPrlh7Y7TRM4MAq6Ysu5NxkcwkP3TtMs AUS79tG9IafDTL+Kity5kt6caG4qEpugYqTDok2v3ahQ6WU/zA2IOqTIeGRWn9ri99X7 91Goqd1vccqglhkJOma9vfQOD0G4RE3tgmGNylxEmPkJRJOhIMyxTbtwtVsyjzbYnXPX iYnvvDU0NVjZnRrR4xvjXFKJ8TT5PTyZrRlR6KlCY4V4tg0nSl3oja4KGUxJmwLV/nQS LWTjuETHWrjGqGmy1eQUUIzpp8dytWE18iCadCIdznOgLH2sskHYRCHvmomsHtqxl/Hq JDgQ== X-Gm-Message-State: AFeK/H2+gVr9eu8tiDqkaZUPwesoeSkCleYGR19WD6rhWfwwyBzP1ctqfKswEChMB2PsJw== X-Received: by 10.55.33.8 with SMTP id h8mr15192051qkh.223.1489787793386; Fri, 17 Mar 2017 14:56:33 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 44sm6840438qts.15.2017.03.17.14.56.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 14:56:31 -0700 (PDT) From: Bob Hinden Message-Id: <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E17C0248-7CD7-4F06-8996-DB275E127C05"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Fri, 17 Mar 2017 14:56:28 -0700 In-Reply-To: <58A33D08.4090505@erg.abdn.ac.uk> Cc: Bob Hinden , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF , "draft-ietf-6man-rfc1981bis@ietf.org" To: gorry@erg.abdn.ac.uk References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 21:56:38 -0000 --Apple-Mail=_E17C0248-7CD7-4F06-8996-DB275E127C05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gorry, Thanks for the detailed review. Several of the reviews have suggested significant changes to this = document. The working group was trying to make a few changes to bring = it into alignment with some changes to rfc2460bis (based on updating = documents). It was not attempting a major rewrite when advancing it to = Internet Standard. The alternative that the working group discussed was = to file errata on RFC1981 and leave it to a future document update. I don=E2=80=99t think many of these changes can be done and still = advance it to Internet Standard. If we can=E2=80=99t advance the current = document, then the w.g. may want to just do the errata and withdraw the = advancement request. Of course, if people want to work on a revision of = IPv6 Path MTU Discovery, it would be welcomed, but it won=E2=80=99t be = able to advanced to Internet Standard. Comments below. Thanks, Bob > On Feb 14, 2017, at 9:23 AM, Gorry Fairhurst = wrote: >=20 >=20 > I have some late transport comments on this ID. The update seems to = retain a lot of thinking that is really historical and I'd really = encourage people to look again to making the document uptodate. >=20 > Detailed comments follow. >=20 > Best wishes, >=20 > Gorry >=20 > ---- > The following text strikes me as a little odd in an update: > " Moreover, TCP implementations that follow the "slow- > start" congestion-avoidance algorithm [CONG] typically calculate and > cache several other values derived from the PMTU. It may be simpler > to receive asynchronous notification when the PMTU changes, so that > these variables may be updated.=E2=80=9D > - A modern TCP caches at least some path information in the TCB, why = start with this clause at all: > "Moreover, TCP implementations that follow the "slow start" = congestion-avoidance algorithm [CONG] typically calculate and=E2=80=9D > and simply replace this with something like: > "TCP implementations=E2=80=9D? > =E2=80=94=E2=80=94 To clarify, you are suggesting to replace it with: TCP implementations typically cache several other values derived from the PMTU. It may be simpler to receive asynchronous = notification when the PMTU changes, so that these variables may be updated. I think that is editorial, and OK to change. The paragraph will read: The TCP layer must track the PMTU for the path(s) in use by a connection; it should not send segments that would result in packets larger than the PMTU. A simple implementation could ask the IP layer for this value each time it created a new segment, but this could be inefficient. TCP implementation typically cache several other values derived from the PMTU. It may be simpler to receive asynchronous notification when the PMTU changes, so that these variables may be updated. >=20 > The following text also seems to not reflect a modern TCP stack: > " It is sufficient > to treat this as any other dropped segment, and wait until the > retransmission timer expires to cause retransmission of the = segment.=E2=80=9D > (and following 3 paras). > Could this be replaced by text that does not exclude modern = retransmission methods: > " It is sufficient > to treat this in the same way as any other dropped segment, and > will be recovered by normal retransmission methods.=E2=80=9D Yes, resulting in: When a Packet Too Big message is received, it implies that a packet was dropped by the node that sent the ICMP message. It is sufficient to treat this in the same way as any other dropped segment, and will be recovered by normal retransmission methods. If the Path MTU Discovery process requires several steps to find the PMTU of the full path, this could delay the connection by many round-trip times. > =E2=80=94 > There is a block of text that describes retransmission triggered by = ICMPv6. > Has this code been implemented in modern releases of TCP?: > " Alternatively, the retransmission could be done in immediate = response > to a notification that the Path MTU has changed, but only for the > specific connection specified by the Packet Too Big message.=E2=80=9D > - It seems to expose a number of attack vectors that really should not = be exposed!! Are you suggesting remove this text? Following this text, there are two = notes. > --- > The discussion of NFS may still be a reasonable historic example, but = to be current it should really refer also to NFSv4/TCP as utlising the = MTU discovery provided by TCP, since UDP-based NFS is no longer a key = application. > =E2=80=94 I was planning to update the reference to NFS to RFC7530. I could add = text that says something like: It is recommended that NFS running over TCP utilize the MTU discovery provided by TCP. Other suggestions? > There is no mention that paths including tunnels can eat ICMPv6 PTB = messages on the tunnel segment, blackholing them, which prevents = reaching the destination. As noted above, I think adding discussion about tunnels is out of scope = of this effort. > --- > I think the security consideration is naive! Suggestions? >=20 > This statement in particular seems to open DOS vulnerability: > " > When a node receives a Packet Too Big message, it MUST reduce its > estimate of the PMTU for the relevant path, based on the value of = the > MTU field in the message." > - Introdueces a significant vulnerability. A rogue PTB message that = reduces the PMTU to a minimum, can result in a path too small to carry = an encapsulated packet. (Recently noted by Fernando Gont). Suggestions? >=20 > Moreover, other layers view ICMP messages with suspicion and have long = noted the need to check ICMP payload and match only packets that relate = to actual 5-tuples in use (effectively reducing vulnerability to = off-path attacks). For example, the Guidelines for UDP, rfc5405bis, = state: >=20 > " Applications SHOULD appropriately validate the payload of ICMP > messages to ensure these are received in response to transmitted > traffic (i.e., a reported error condition that corresponds to a UDP > datagram actually sent by the application). =E2=80=A6=E2=80=9C > - clearly handling this in IP-layer tunnels can be troublesome, but = that's a problem that should be described, not obscured. I could add something like the following as a new second paragraph in = Section 4 Protocol Requirements: Protocols SHOULD appropriately validate the payload of ICMPv6 PTB messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition that corresponds to a UDP datagram actually sent by the application). or similar. > =E2=80=94=E2=80=94 >=20 > I=E2=80=99d finally like to add my concerns about the understatement = of the value of PLPMTUD, which seems to not reflect the recommendations = to use this method: > =E2=80=9C It defines a method for Packetization Layer Path > MTU Discovery (PLPMTUD) designed for use over paths where delivery = of > ICMP messages to a host is not assured.=E2=80=9D > This seems under-stating the value and recommendations to deploy = PLMTUD, compared with current transport-area recommendations, for = instance, the UDP Guidelines provide much more on this important design = consideration: The w.g. spent a lot of time on this paragraph. The intent was to point = to it, but not into detail of how it worked, nor make it a new = requirement. There was some discussion that adding more detail about = the relationship between PTMUD and PLPMTUD in the ongoing update to IPv6 = Node Requirements would be helpful. >=20 > " Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does = not > rely upon network support for ICMP messages and is therefore > considered more robust than standard PMTUD. It is not susceptible = to > "black holing" of ICMP message. To operate, PLPMTUD requires = changes > to the way the transport is used, both to transmit probe packets, = and > to account for the loss or success of these probes. This updates = not > only the PMTU algorithm, it also impacts loss recovery, congestion > control, etc. These updated mechanisms can be implemented within a > connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not a > part of UDP, but this type of feedback is not typically present for > unidirectional applications." >=20 > ---- >=20 > The examples used in the definition of "upper layer" and "link" also = makes this document appear as historic, rather than a new RFC! As noted above, I think there would be support for a rewrite if some = folks wanted to take that on. --Apple-Mail=_E17C0248-7CD7-4F06-8996-DB275E127C05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYzFuNAAoJEK7rdBF357uojAUH/09MvHP44Q3jQZ/TCpw4SSrH 7iQwuddxtEiaK2x1aFXdxsxPw9y0S7RqPyfo2gbMs03zgmg7Jqz0S2LpvPM/Pql1 Pm64clbqKPaWSiMOW5m3Z34aF0uZ94PkhQn7OtKN304bdXpw2u+yCTsKmtiQjcX7 z7wAW6v9407CWbmA4ZeMEVYw0vul8sxad4IWGIXLRqLkfeMSSuOFZimSFg5CDNpR jGgUA+GpSQc3IjpmqgJ9hQb1u3PfTKBRT1hiTWwgt8W1uKvr5UQqvc0O8gne6bKK bMGpWmuwvzUkOFgJXCyy86N9BE/YLFidK3luUJ4cNKc0bFETCSmUhOs7B2TZ+wQ= =mCAV -----END PGP SIGNATURE----- --Apple-Mail=_E17C0248-7CD7-4F06-8996-DB275E127C05-- From nobody Fri Mar 17 14:57:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E9D12961E; Fri, 17 Mar 2017 14:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xelQRPdz89TN; Fri, 17 Mar 2017 14:56:49 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54EF12962E; Fri, 17 Mar 2017 14:56:48 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id x35so73256646qtc.2; Fri, 17 Mar 2017 14:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VV/zRiqaKOTK3FoqUkNYsCUNj95vvTOF0DMGRtbeYD0=; b=j/GcySico+4veVdwWIKd1kEv994/CEmVPWESe1/m9Wt2Py0AoNR/NhgBp1o7Kz4QAB MDLqeIMssDpnwT/XCNHNgOZO1MSoGyo7bW6Sc7XHsOSoz6uRhkEmcN39oGc0afzcPTJM bMNB0ssy37BRJwaUABUNy1op6Bgze8LKAdDT8YkiC651NpJ9BgyZMBRLRKBlmbms9Job ui0T2HNvGaAe3zx/FG+PxzxQPEOrdLgFnGu1JlPMEBzyEEnBLUoyV92oLL/P+OoXTBVy GGsq5XMWRYZQbwplEvC3xi8QbzdllFLxbJj4xRy9pvzU7udXWQJK4QDNa46M1aqMCqOR u8/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VV/zRiqaKOTK3FoqUkNYsCUNj95vvTOF0DMGRtbeYD0=; b=gSE2H0mwHROmZr4uHxfY1C/RlF9aMVr3L9nqVaSt8nMjgdKoj0m21LS4oZ0i9ausLc OQ8g1ZcPTN4C0xlIFbILvASMWjBSblcEQXmOfwSKsvvCA+SiEOy0izrUZDn74xgX/PMd 4jIHHpSiCd/PBABp1cFNg5IM0m8yub3jCG1ZZ+C8j9xb0/GiI5gXzF2pHR19wjElNpGk afB4MmzqpYwYLUibFc5oAZhQCMIqrHZjLEYt4S1YxZPEOG/WgfKbEelOVTRWRcYq6eRF Uch7GxfRVfUdTkYa25WJH9uheh9Ieww06hEVX+f/QlUU7BaO8S0urpTlqpHUg3tkVl1g bssg== X-Gm-Message-State: AFeK/H3x2F9QT2Fwe3/VOrRX8rTw4HjbNhqOnaK1Pf9UMewk2ZK6ln8Trqj8+v+VdmEn2A== X-Received: by 10.237.38.194 with SMTP id q60mr17076314qtd.84.1489787807709; Fri, 17 Mar 2017 14:56:47 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 44sm6840438qts.15.2017.03.17.14.56.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 14:56:46 -0700 (PDT) From: Bob Hinden Message-Id: <5BABA19D-58F8-44AE-BF18-9A0B9CCADED4@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B4891142-9A32-490E-8AAE-8A8206A40649"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Review of draft-ietf-6man-rfc1981bis-04 Date: Fri, 17 Mar 2017 14:56:45 -0700 In-Reply-To: <148665359396.20513.9749548375095869760.idtracker@ietfa.amsl.com> Cc: Bob Hinden , gen-art@ietf.org, IPv6 List , IETF , draft-ietf-6man-rfc1981bis.all@ietf.org To: Stewart Bryant References: <148665359396.20513.9749548375095869760.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 21:57:02 -0000 --Apple-Mail=_B4891142-9A32-490E-8AAE-8A8206A40649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Stewart, Thanks for the detailed review. I am responding after reading the email = thread that resulted, some issues were closed. Several of the reviews have suggested significant changes to this = document. The working group was trying to make a few changes to bring = it into alignment with some changes to rfc2460bis (based on updating = documents). It was not attempting a major rewrite when advancing it to = Internet Standard. The alternative that the working group discussed was = to file errata on RFC1981 and leave it to a future document update. I don=E2=80=99t think many of these changes can be done and still = advance it to Internet Standard. If we can=E2=80=99t advance the current = document, then the w.g. may want to just do the errata and withdraw the = advancement request. Of course, if people want to work on a revision of = IPv6 Path MTU Discovery, it would be welcomed, but it won=E2=80=99t be = able to advanced to Internet Standard. Comments below. Thanks, Bob > On Feb 9, 2017, at 7:19 AM, Stewart Bryant = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-6man-rfc1981bis-04 > Reviewer: Stewart Bryant > Review Date: 9/Feb/2017 > IETF LC End Date: 1/Mar/2017 > IESG Telechat date: unknown >=20 > Summary: This draft is on the right track but has open issues, > described in the review. >=20 > This review together with the lengthy discussion on the IETF list > suggest that this draft has a number of issues that need to be > addressed before publication. >=20 > I wonder if we would best serve both our future and our heritage > if we declared RFC1981 as historic, and either left the idea there, > or declared it as historic and wrote a new text from a clean start? >=20 >=20 I think this was closed in the email thread. > Major issues: >=20 > Nits points out a number of faults with the document, but the only > one of substance is: >=20 > The text has a lot of RFC2119 language, but no RFC2119 declaration. >=20 > The document could use a thorough RFC2119 scrub Based on in an earlier another review, our AD suggested an update to = Shepard Writeup instead of adding something to the document. It says: This document is an update to RFC1981 that was published prior to RFC2119 being published. Consequently while it does use = "should/must" style language in upper and lower case, the document does not cite = the RFC2119 definitions. Since the changes in this update were very limited, the w.g. concluded to not change any of this language. >=20 > The document lists the three original authors one with an affiliation >=20 > change, but no email addresses. Has this been agreed with the > original > authors, and have arrangements been put in place for the RFC editor > to process auth48? I contacted the original authors and they didn=E2=80=99t express any = interest in being involved in this update. They haven=E2=80=99t = participated in the IETF for many years. I can contact them during = AUTH48, or the AD can override this requirement for this document. >=20 > It is concerning that the draft does not talk in any detail about > how modern ECMP works, i.e. using the five tuple, and noting that > the PMTU may be different depending on the transport layer port > numbers. >=20 I think this is out of scope. > Given that a very large fraction of packets will traverse an MPLS > network at some point, I am surprised that there is no text talking > about the importance of providing support for this feature in the > MPLS domain. RFC3988 talks to this point, but is only experimental. >=20 I think this was closed in the email thread. > =3D=3D=3D=3D=3D=3D >=20 > If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation > could use the flow id as the local representation of a path. > Packets > sent to a particular destination but belonging to different flows > may > use different paths, with the choice of path depending on the flow > id. This approach will result in the use of optimally sized > packets > on a per-flow basis, providing finer granularity than PMTU values > maintained on a per-destination basis. >=20 > SB> How widely is flow-id supported in networks? I thought that the > SB> current position was that it was unreliable as an ECMP indicator > SB> and thus routers tended to glean information from the packet > themselves. I think this was closed in the email thread. >=20 > =3D=3D=3D=3D=3D=3D >=20 > Note: if the original packet contained a Routing header, the > Routing header should be used to determine the location of the > destination address within the original packet. If Segments > Left > is equal to zero, the destination address is in the Destination > Address field in the IPv6 header. If Segments Left is greater > than zero, the destination address is the last address > (Address[n]) in the Routing header. >=20 > SB> So this has the effect that a traffic engineered packet and > SB> a non-traffic engineered packet will have the lower of the > SB> two PMTUs. This was all harmless when source routing was a > curiosity > SB> as far as mainstream networking was concerned, but may be > SB> more of a problem as a result of the SPRING work. I think the onus is on SPRING to make sure it doesn=E2=80=99t break = existing mechanisms. >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 >=20 > 5.3. Purging stale PMTU information >=20 > Internetwork topology is dynamic; routes change over time. While > the > local representation of a path may remain constant, the actual > path(s) in use may change. Thus, PMTU information cached by a > node > can become stale. >=20 > If the stale PMTU value is too large, this will be discovered > almost > immediately once a large enough packet is sent on the path. No > such > mechanism exists for realizing that a stale PMTU value is too > small, > so an implementation should "age" cached values. When a PMTU > value > has not been decreased for a while (on the order of 10 minutes), > the > PMTU estimate should be set to the MTU of the first-hop link, and > the > packetization layers should be notified of the change. This will > cause the complete Path MTU Discovery process to take place again. >=20 > SB> Should that be an RFC2119 SHOULD? > SB> The impact of this advice is going to be a disruption to what > might > SB> be a critical service every 10 mins. > SB> Should there be some advice along the lines of noting the > SB> importance of service delivery as part of deciding whether to > SB> test for bigger PMTU vs improving efficiency? >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 >=20 > Minor issues: >=20 > IPv6 defines a standard mechanism for a node to discover the > PMTU of an arbitrary path. >=20 > SB> Do you mean "This document defines ....."? Otherwise this needs > SB> a reference. Will fix. >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > An extension to Path MTU Discovery defined in this document can be > found in [RFC4821]. It defines a method for Packetization Layer > Path > SB> Rather than have the reader figure out what "It" is, perhaps > SB> s/It/RFC4821/ The w.g. noodled on this text for a long time. I think the =E2=80=9Cit=E2= =80=9D is clear, but will change to RFC4821. > =3D=3D=3D=3D=3D=3D=3D >=20 >=20 > Upon receipt of such a > message, the source node reduces its assumed PMTU for the path > based > on the MTU of the constricting hop as reported in the Packet Too > Big > message. >=20 > SB> We should perhaps state up front that this procedure > SB> hunts for the worst case of the ECMP set associated with the > SB> ingress nodes PMTU classifier. I think getting into ECMP is out of scope for moving this to IS. > =3D=3D=3D=3D=3D=3D=3D >=20 > If a node receives a Packet Too Big message reporting a next-hop > MTU > that is less than the IPv6 minimum link MTU, it should discard it. >=20 > SB> Should that be an RFC2119 SHOULD? See note above. > =3D=3D=3D=3D=3D=3D=3D >=20 > 5.2. Storing PMTU information >=20 > Ideally, a PMTU value should be associated with a specific path > traversed by packets exchanged between the source and destination > nodes. However, in most cases a node will not have enough > information to completely and accurately identify such a path. > Rather, a node must associate a PMTU value with some local > representation of a path. It is left to the implementation to > select > the local representation of a path. >=20 > SB> Is it worth noting the five tuple since that is how a lot of > SB> load balancers work? I think getting into ECMP is out of scope for moving this to IS. > =3D=3D=3D=3D=3D=3D=3D >=20 > The set of paths in use to a > particular destination is expected to be small, in many cases > consisting of a single path. >=20 > SB> I am not sure that remains true in modern networks. Do we have any data on this? I wonder if there will be much difference = in the PMTU in this case. > =3D=3D=3D=3D=3D=3D=3D >=20 > One approach to implementing PMTU aging is to associate a > timestamp > field with a PMTU value. This field is initialized to a > "reserved" > value, indicating that the PMTU is equal to the MTU of the first > hop > link. Whenever the PMTU is decreased in response to a Packet Too > Big > message, the timestamp is set to the current time. >=20 > Once a minute, a timer-driven procedure runs through all cached > PMTU > values, and for each PMTU whose timestamp is not "reserved" and is > older than the timeout interval: >=20 > - The PMTU estimate is set to the MTU of the first hop link. >=20 > - The timestamp is set to the "reserved" value. >=20 > - Packetization layers using this path are notified of the > increase. >=20 >=20 > SB> Such detailed implementation advice is uncommon in modern RFCs. It > has > SB> the disadvantage of de-facto standardizing something that should > be left to > SB> the innovation of the implementer. Can you point to any harm this has caused? It is very widely = implemented. >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > 5.4. TCP layer actions >=20 > SB> TCP implementations have moved on a lot since this section was > SB> written. Is this still current best practise? >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > 5.5. Issues for other transport protocols >=20 > Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed > to > repacketize when doing a retransmission. >=20 > SB> How much TP4 is there going over IPv6? Doesn't this example > SB> show the IETF as not being in the modern age? I have no information one way or another. I have heard there is some = TP4 on airplanes, may they will move it to IPv6 :-) >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > Nits/editorial comments: >=20 > upper layer a protocol layer immediately above IPv6. > Examples are transport protocols such as TCP > and > UDP, control protocols such as ICMP, routing > protocols such as OSPF, and internet or lower- > layer protocols being "tunneled" over (i.e., > encapsulated in) IPv6 such as IPX, AppleTalk, > or > IPv6 itself. >=20 > SB> Everything in the list above is in the well known list, except > SB> IPX, so technically it needs expansion. However it might be nice > SB> to use some modern example in common use. I will add a reference to IPX. The best reference I have found to IPX = is: Novell, Inc., "Advanced NetWare V2.1 Internetwork Packet Exchange Protocol (IPX) with Asynchronous Event Scheduler (AES)", October 1986. Please suggest something better. > =3D=3D=3D=3D=3D=3D=3D >=20 > link a communication facility or medium over which > nodes can communicate at the link layer, i.e., > the layer immediately below IPv6. Examples > are > Ethernets (simple or bridged); PPP links; > X.25, > Frame Relay, or ATM networks; and internet (or > higher) layer "tunnels", such as tunnels over > IPv4 or IPv6 itself. >=20 > SB> Technically X.25 needs a reference, since it is not "well known=E2=80= =9D Will add a reference, if you think it is necessary. > =3D=3D=3D=3D=3D=3D=3D >=20 > path the set of links traversed by a packet between > a > source node and a destination node. >=20 > SB> Is it a set of links, or a set of links and nodes? I think the current text is OK. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > the value of MMS_S, the "maximum send transport-message size". > SB> The modern convention is full-name(abbreviation) I don=E2=80=99t follow this. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > The Sun Network File System (NFS) uses a Remote Procedure Call > (RPC) > protocol [RPC] that, when used over UDP, in many cases will > generate > payloads that must be fragmented even for the first-hop link. > This > might improve performance in certain cases, but it is known to > cause > reliability and performance problems, especially when the client > and > server are separated by routers. >=20 > SB> Perhaps this should point to RFC7530 (the current NFS Spec), > assuming > SB> the behaviour description is still correct. Will do. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The former can be accomplished by associating a flag with the > path; > when a packet is sent on a path with this flag set, the IP layer > does > not send packets larger than the IPv6 minimum link MTU. >=20 > SB> We do not normally give this level of implementation advice I think it varies a lot. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 >=20 >=20 --Apple-Mail=_B4891142-9A32-490E-8AAE-8A8206A40649 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYzFudAAoJEK7rdBF357uoUyUH/2woOWoFtDbAFeegeqdFq1/g D0HY5duq6FJeM6TmjxNz7OsaQmfCjAhW9unQl4LR8ma384vFziqjt2S8XrYWFtSp s6L4WHXg8u47Xysft4sjSqK9CbqaERKFRFC8b+S6WsCfP6xHxwn2RvUGfD5S+4Ub G+dkzOpvnPstT+97rPFFCq3px5Ztl7kd7CKgp2z8zoHi5nbSV2adIH6Eciq4bo8d owk37ZrC22IuHLbjEHAKevTE/hsQSVnRR2TbO6IPP9Bt0T80ZtalDfVTg6OP/vuN V8cH+Ded8eKLti9WNaAerQxYeK9r0dBWTRqdTjAchLoqpnEvDT8tvJk5DhjNWh8= =0Tht -----END PGP SIGNATURE----- --Apple-Mail=_B4891142-9A32-490E-8AAE-8A8206A40649-- From nobody Fri Mar 17 14:57:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FA3129626; Fri, 17 Mar 2017 14:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9JhS43d9cVpy; Fri, 17 Mar 2017 14:57:33 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D8F12964B; Fri, 17 Mar 2017 14:57:26 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id y76so75366272qkb.0; Fri, 17 Mar 2017 14:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gvrXSvmqcDlquJ0BLz6Dn10E9+COA0RqNahhARl8YTA=; b=OsaarYT/E23XrBQAQ/56gQb8fTlPk1z5YyeFyXhV5hgG+/NRU6k5+MulAYXMA00irV asxmU0pZxLVl3BVKgiV0Oyp3JRO8IhauUfmT4BIiLbOVePhC6jQgYN7n6GJSPktvbhZl 2Sk6gQWIrPPOIrat42b+/GU+liH12A7hZtoq1jX4ZUOCrjvtR1ubzMNQJPZop/jKGB27 lbH1bZyJ3KnskSm94UVUaW3aebCjEbScY/vF62Z7ZIzeYxzx6//OK+6AHfupTzIl8u/o CYtBHCM3nOTruObu4KPTy1EBJQ1k0j+uKY79syGq4FmcVSKgewQdUHhlvwsN23jDweqU EYMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gvrXSvmqcDlquJ0BLz6Dn10E9+COA0RqNahhARl8YTA=; b=sgG7efm+idqnNhLJlUJZTb/AL2TuHSki6aNDjLll4NNU+g1owQdBycGPBLegMD3Y5P KGlIBXGGyjDbsz51j/p8DGcMZ/UgpY1Ol1eroM8ww58t+MShTMbtM6Sxh+msHzh0NmbE nnk8/XcdDnBE4pB/oQ7h8fn1lRcD7xglVKSmkdK47ZiTU5hr4Ss7KB3wGXzA51XE5934 vz8Ps1Lt+9QCi+NOiUfYbueip+CbkBxQ2vwtdSGrJSpdYoaKX68m8FOZAMjUxnxibQym bLnkBLZdeZWHABRdtbs0TtiGdRIIhAhggvQQLYJD/NScYrdmVCsNnKAOzMVoia1MBdUK Z+2w== X-Gm-Message-State: AFeK/H0roQTjfS1wmjA9bYpZAzQ4Ywwz5dCUe44t/evbLFKe3uP6N+VO9ZASn6L2geUQ3g== X-Received: by 10.55.176.135 with SMTP id z129mr11140882qke.308.1489787845442; Fri, 17 Mar 2017 14:57:25 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 44sm6840438qts.15.2017.03.17.14.57.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 14:57:24 -0700 (PDT) From: Bob Hinden Message-Id: <41A44496-F222-40D5-95FE-5CE142C3827F@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_38742971-3019-4F6C-B32C-25B01CAA4AB2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 Date: Fri, 17 Mar 2017 14:57:23 -0700 In-Reply-To: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> Cc: Bob Hinden , "tsv-art@ietf.org" , IESG , IPv6 List To: Joe Touch References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 21:57:36 -0000 --Apple-Mail=_38742971-3019-4F6C-B32C-25B01CAA4AB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joe, Thanks for the detailed review. Several of the reviews have suggested significant changes to this = document. The working group was trying to make a few changes to bring = it into alignment with some changes to rfc2460bis (based on updating = documents). It was not attempting a major rewrite when advancing it to = Internet Standard. The alternative that the working group discussed was = to file errata on RFC1981 and leave it to a future document update. I don=E2=80=99t think many of these changes can be done and still = advance it to Internet Standard. If we can=E2=80=99t advance the current = document, then the w.g. may want to just do the errata and withdraw the = advancement request. Of course, if people want to work on a revision of = IPv6 Path MTU Discovery, it would be welcomed, but it won=E2=80=99t be = able to advanced to Internet Standard. Comments below. Thanks, Bob > On Feb 15, 2017, at 1:51 PM, Joe Touch wrote: >=20 > Document: draft-ietf-6man-rfc1981bis-04 > Reviewer: Joe Touch > Review Date: February 15, 2017 > IETF LC End Date: March 3, 2017 > IESG Telechat date: February 28, 2017 >=20 > Review result: significant issues >=20 > NOTE: some of this review is informed by tracking some of the issues = raised by others on the IETF list, notably Gorry Fairhurst. In my response to Gorry, I proposed some changes to the document. >=20 > Major issues: >=20 > 1) the current text is insufficiently realistic about the (in)ability = of this mechanism to operate in current networks, regardless of the = support for generating ICMPs at routers or PMTUD support at endpoints, = due to ICMP filtering for security reasons. [this comment is already = being addressed by consensus text] As far as I can tell, we don=E2=80=99t have much much information on how = much ICMPv6 PTB messages is filter or not. It=E2=80=99s clearly a = problem with IPv4 ICMP PTB, but I haven=E2=80=99t see any recent data = regarding ICMPv6 PTB messages. IPv6 deployment has increased = significantly since the last data I saw and it may or may not be a = significant problem. >=20 > 2) the current text is insufficiently clear on on the difference = between the path MTU, which determines the largest supported IPv6 = fragment, vs. the effective MTU to receive (EMTU_R), which determines = the largest IP packet that can transit between the source and = destination. The document should be more explicit throughput about its = goal being to manage or avoid IPv6 source fragmentation rather than = about source to destination packet maximums, and in specific in clearly = referring to maximum fragments or atomic packets rather than maximum = packets. >=20 > E.g.: see the following text, which is incorrect in its current form: > Nodes not implementing Path MTU Discovery use the IPv6 minimum link > MTU defined in [ > I-D.ietf-6man-rfc2460bis > ] as the maximum packet size. >=20 > The value used by either Path MTU Discovery or its default represents = the path MTU, which is the largest IPv6 *fragment* (or atomic packet, = see RFC6864) that can be supported on the path between the endpoints. = The maximum IP packet size is limited by the effective MTU to receive = (EMTU_R) [RFC1122], which is at least 1500 bytes for IPv6 and not = necessarily related to the link MTUs. The text should also clearly = indicate that there is no ICMP mechanism for determining larger EMTU_R = support. >=20 > E.g., the following text is also incorrect in its current form: > The value sent in the TCP MSS option is independent of the PMTU. > This MSS option value is used by the other end of the connection, > which may be using an unrelated PMTU value. >=20 > The first sentence is correct because TCP MSS is related to EMTU_R = (and needs to account for headers, as per RFC6691), and EMTU_R is not = directly related to the PMTU (except that it would never be smaller than = the PMTU). The MSS option is calculated from EMTU_R, not PMTU. >=20 > In addition, it should be noted that ICMPv6 PTB messages are NOT sent = when source fragmentation is enabled. I think these are all good issues to cover in a rewrite, but I don=E2=80=99= t see how they can be done now. >=20 > 3. need verification of current support for some features, esp. = regarding TCP and NFS interactions > See Gorry's note of 2/14/17 Please see my responses to his review. >=20 > 4. the concept of a single path MTU value between two IP addresses = does not account for multipath routing, e.g., ECMP (as currently = deployed, noted in RFC7690, which should be cited) or BANANA (and its = solutions in development) See Fred Templin's posts on this on 2/15/17 >=20 > Minor issues: >=20 > - some of the updates and/or current text could be updated to reflect = current terminology or practice. See Gorry Fairhursts's post of 2/14/17 I suggest some changes to address some of the issues he raised. >=20 > - fragmentation, while considered harmful and costly, is absolutely = necessary to support tunnels even in the presence of PMTUD. The text on = this issue should reflect this reality. >=20 > - the requirement that transports be notified of PTB messages might = usefully cite the corresponding IPv4, TCP, and UDP sections of RFC1122 I think that is doable. Please suggest some specific text. > - section 5.4 should cite and include context from RFC6691, especially = including a discussion of the impact of variable IP EHs on the = interaction between TCP MSS and ICMP PTB >=20 Please suggest some specific text. > -- >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_38742971-3019-4F6C-B32C-25B01CAA4AB2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYzFvDAAoJEK7rdBF357uoSjkIAIjGKuseXIpuNUhVZAmaB1yx qbXo7IkDYJBxKV/m83MqPhK789nHnbsRGXQbCdijaDZAPWgDiaQDZTw5Cwn2jaLU US8CivNAdlnyOJDFaRiNZPa3M9jRorJxle2D4bTSKtskGCt2gH64+sM/HmY46xUe UBGfaVYjLsV2vNh1PDGKYUS6nNV8sfN83bR0/RqDxNi32mRb3kz70K/3AbJGsC6Q NXKVd7VrdcSxsX4vC+6zYp+OCJVO+1JUBnc0SyJ7Qquv8cIM2g9SjrqtcjncEe5f hL12J+tZ4btzQEQElqo8hEhsJVRCoCoCBjLJQLU8CoNbm587NR1EL9v7rSwtOUs= =4S38 -----END PGP SIGNATURE----- --Apple-Mail=_38742971-3019-4F6C-B32C-25B01CAA4AB2-- From nobody Fri Mar 17 15:20:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7FA12962E for ; Fri, 17 Mar 2017 15:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 mJAfnJAplTrI for ; Fri, 17 Mar 2017 15:20:21 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7EC12955D for ; Fri, 17 Mar 2017 15:20:21 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 17 Mar 2017 22:20:21 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id DA8A2D788B; Fri, 17 Mar 2017 15:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=cm0LP/AfcVPRws9TipqHKbawFyQ=; b= ri0LFb2Tl3fclnA29i3dkNDyQ+es/lliL2kOD0kRzL5Zz5OXrIcFoUc4BSoGHHQp eP0Gb6sN5A/AVLOfQhEGbhKQEI7hObEx6OW5Awobc9e6ZwMbe5foTfuQsaS5gsLL EvOQs0CqiMDPgh0ul7aJM9RgLAtTyYHvaY6QojKra/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=fv4NhQJYZvURZnO2jG5CnML 1BA02GSHxeV8uv+2EErWLxLjQMTPHOEtfG4OS4aeYjgSNZjVxK1GhIEe0UPoB8Kq doBoOXUKDFKciz0kre7i5WJBaTaAS630emKYblhFYrELch6Md/9+DwARU/VrWAuD p3nSci2/lBBvLknQnSSU= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id AF3BCD788E; Fri, 17 Mar 2017 15:20:20 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 70326A0C0838; Fri, 17 Mar 2017 23:20:18 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_248A060F-374D-4F19-B2EA-596E6A3E392C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: a draft about on-link and subnet prefixes - onlink|SLAAC and larger than 63bit IIDs Date: Fri, 17 Mar 2017 23:20:17 +0100 In-Reply-To: Cc: 6man WG To: Alexandre Petrescu References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> <80954d75-d07a-efe5-5906-dba8976dc563@gmail.com> <1ab36b80-ac73-abf2-0b6e-9f7e047d4963@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 22:20:23 -0000 --Apple-Mail=_248A060F-374D-4F19-B2EA-596E6A3E392C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alexandre, it is a little hard to understand what you want to achieve with your = messages. if you want something explained, perhaps we should sit down in Chicago. if you want to have something changed, please write a draft and explain = your proposal and your ideas. Best regards, Ole --Apple-Mail=_248A060F-374D-4F19-B2EA-596E6A3E392C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYzGEiAAoJEL7aWKiYQt92wIMP/0d4zeEHfC6/oyW4An8yWAYA xZQQ8MUbdL7cKEzB32Z2OtzJ2q8La48wbJORCu+2oyOAxLK2fK52sTKqTeRmtCsD 1XwCJH6Byy9wjsWjWaUinUaKqS2nFjchqY/01lol0ZTJa7EenlH2mqII3Ca77XvM 5gcx6F8If5sT0Ja2KF4i/KZHcxlCGNIGuXqhS4Kl0OdK7ivJd39aIKc5YOcWH3hj d9IxbUyn5xt2uws5KH7X3o6L2SIfrGvuzHFOdZXIheQVBm+r10a+g5Rt22IPtt0E ShNSbtT8mgGpaW4E8tB8cvwsLUmBPTjGwHiqCexhj2DLS0Ha7InVKGjtpEvMtY8S yJ7lQVD66AL3BO3PAayMrNPglOZ6ZfUY9l3Fl2NadBhRFkXKTjlMV+FQaS007dv9 uUPUB1GGipvA0mteFa+yxHxbpzAtaCyNensC14dLvn3/AAgG178wKivu5uxPXKxc rousB9cs9CrJvNdpQBgh+B9XA8aYydXQ3TPzQuzlldHBQZwgS+qSADx8GBXQv6XB xW8uAJY1DApNF5DoNwycj91NaDMahaIxUpxGctIax7STdHMCUKE8P6Z2Ac62Lrwy H9ScPFXecilko3JL6nfyp4HMaYWpXfwSCCMF0j7F9SKivkTIMOVzNVA+f59sklBg qIE82wrOqBp9B2cT4UyU =IBNt -----END PGP SIGNATURE----- --Apple-Mail=_248A060F-374D-4F19-B2EA-596E6A3E392C-- From nobody Fri Mar 17 15:24:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B389C129642 for ; Fri, 17 Mar 2017 15:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 d17FX420Dlbu for ; Fri, 17 Mar 2017 15:24:38 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94E7127011 for ; Fri, 17 Mar 2017 15:24:37 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id y76so75739315qkb.0 for ; Fri, 17 Mar 2017 15:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rzJMt3qYN0Zxroz+R984/4gCG3KgEtp0NU5dFTchpE8=; b=fraOXdY3PKt483Oo8d0tgAW32JcSk9jatCZ36h9y2JwdRS5A6cG8R1qq/tsl5z9QYk 4hsEM54iR7x8vVW7WQ6a96AHnRJD4PmTDcqTmp0F2ZjmEzA9xLak1vEH9ZiuMbk8R4Bz n3NeNKTrixJG0oumz8lOSXVD1TAnvFquWTyQ4LjQIGoZAnHtrwLEPOS3hzq32drh4PU3 Aswh8ox7/K0PPahicDzvEwwYPHegcQn9dOEfAvcip7YCWMXl9JGzvtespmQQepuk1647 yJDcNBjyPts9FGEEF5Dum99ryiL0L60DXrqqEadB6RDYgOEetqKGmYpc21qm/YKP4GBC xgHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rzJMt3qYN0Zxroz+R984/4gCG3KgEtp0NU5dFTchpE8=; b=VTHTE3SxBYg868dpBzcbRWnSbKOZT5gphmx0nZdwn11qCYtvNKW9fyP/nSlD5rIEGM K14foSWVzm6j5b/DU6qyWBS+vO6OcxTzuUfa+dWuXm7kI0e8LrlqjZV8aLCXRAHs0wAh 3fBVkgagU7o9hTmv2n9+oou1qFBhNmwQoE1LY2OUdzpsI5ALFPn5ZIPUbtSDTZS4FoHI 6mDV9EmXgIjfJUytxQn5lsBlELLCawyKUP6eV6hUDuW54gvilf2nY7bR2bo4Edxuv0/R Usz5uzvOw/en6EyUmeB1CgOrvtcjWjDxBBP15wpWqG0uKUPoJOhbv6hQC3FjCcKb4SVp pHaw== X-Gm-Message-State: AFeK/H1nnun1HcylAXqBbQaZYwXufinlPvpVCErPKRJJvjdmuh2ow3u2Odo3tUqVWxJFsNSey3zxQP6aIaWong== X-Received: by 10.55.60.137 with SMTP id j131mr13167598qka.19.1489789477046; Fri, 17 Mar 2017 15:24:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.143.10 with HTTP; Fri, 17 Mar 2017 15:24:06 -0700 (PDT) In-Reply-To: References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> <80954d75-d07a-efe5-5906-dba8976dc563@gmail.com> <1ab36b80-ac73-abf2-0b6e-9f7e047d4963@gmail.com> From: Mark Smith Date: Sat, 18 Mar 2017 09:24:06 +1100 Message-ID: Subject: Re: a draft about on-link and subnet prefixes - onlink|SLAAC and larger than 63bit IIDs To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Alexandre Petrescu , IPv6 IPv6 List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 22:24:40 -0000 On 18 March 2017 at 08:39, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Fri, 17 Mar 2017 15:58:00 +0100, > Alexandre Petrescu wrote: > >> It does however mean that when IID len is 63 the prefix len must be 65; > > To be very precise: when IID len is 63, an "SLAAC subnet" prefix len > must be 65 (but an on-link prefix len doesn't have to be so). > >> that is not good because it does not consider "dichotomy" between onlink >> prefix and SLAAC prefix. > > I don't understand what this "consider" means, but the combination of > IID len=3D63, SLAAC subnet prefix len=3D65, on-link prefix len=3D60 is > totally valid (whether or not it's useful in practice). That's > basically all my draft tries to explain. > >> > The so-called "dichotomy" doesn't affect this identity at all. >> >> The "dichotomy" concept implies that if the IID is 65, the SLAAC prefix >> must be 63 yet the onlink prefix could be 60. > > Right, and that's valid as noted above. > > I'm feeling I now have to give up understanding what you're trying to > say...I'll basically stop responding at this point. I too don't really understand the point of having an IID that is less bits than the prefix length. I'm also not quite sure what it actually would be in practice. In practice, would it be e.g.,? - router interface assigned 2001:db8::1/60 - RA PIO 2001:db8::/64, A=3D1, L=3D1 As far as I can see, the bits between the /60 and /64 are wasted, as they're serving no purpose. It would also cause the host to believe that destinations outside the /64 but within the /60 are off-link (if there actually are any destinations), where in reality they're probably directly reachable over the link, rather than the traffic having to be hair-pinned through the router. I'm not sure there is much value exploring and explaining valid but in practice configurations that would cause more confusion than any operational value they could provide. (I'm reminded of IPv4 subnet masks, prior to CIDR, that could have non-contiguous 1 bits. Interesting in theory, operationally terrible in practice.) Regards, Mark. From nobody Fri Mar 17 15:51:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3636E129551; Fri, 17 Mar 2017 15:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 otG_0Ef1bBwc; Fri, 17 Mar 2017 15:51:01 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6280124B0A; Fri, 17 Mar 2017 15:51:00 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m27so38002020iti.0; Fri, 17 Mar 2017 15:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bu0o5GFHnjd8ezR/cwUx8FZjWXQxj0VE5cHd9ZFXq5E=; b=duAQ+ZyzynSvD0n9s7c8DVR1N4zUHomqDOfLsDgmN1/op/pr1DCrGogxI21zuHXTSP JhRVaQIAYAS1/2DShke6umELsMFhIk8XR9aB6ZxS/g3fl+xhKSneuVHj+pB3G6uFp31M /y9S/LzTVI1Wm5Fg4pS1K9ZOOK3hTwBA8VVka4rv1eeZKEvP/bNDUYjb3yML32G30BY2 HE0QSmzYEUQouj5hySfS4+UDbOeNqabyEGnHT5knxdoapg5o5yvzYcBHwZ+gw2/B3GJ9 dS+R9KE7jJ0wHtpA6MWxcdhKG0UxQoWF9kMxRG1pbzCsh315XxXOnHN6PGRDV4D6Agpx 1LDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=bu0o5GFHnjd8ezR/cwUx8FZjWXQxj0VE5cHd9ZFXq5E=; b=iv0amkhXsdjQaDH3xivvshqDDe5nIMvqe8dKzfg0CykcyVIG1BQ2feoM/Ro1zE9J0A ZTM1EsIkK7PrwWFWV+iMLyfsCqEagL8IqdcSDb9splzs/GcZcuIvephHg0Ded8v6hxd7 Wbj+C/9xHpwbvIskOjbS++NS/CHpdWOnXQl+43g5lUB6lSmLs45JeffSozfv+mo4epJG WanIvrl6zv49+Ml3iKFC6z/xW3q75lHUvlbcDO36RmVAwhbhAR/9R+m/RsRzVNfj7cbm I+2WASKekUee9uPPaZuIhjbucBp84Ln7o0TLldLBdB8OwJyaNQ2QfPgwdkcN+rL7J39M 4Bmw== X-Gm-Message-State: AFeK/H2fekO7aiCAASmQEAoha+H3JG4/fWQkEQ7Mx2+fiHhhSTOLfG653wRvhMnD7jweBQ== X-Received: by 10.107.202.196 with SMTP id a187mr14893929iog.129.1489791060226; Fri, 17 Mar 2017 15:51:00 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id k68sm5044502iod.13.2017.03.17.15.50.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 15:50:59 -0700 (PDT) Subject: Manual PMTUD [was ...rfc2460bis-08] To: Robert Raszuk , "Leddy, John" References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> Cc: Stewart Bryant , Tim Chown , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> Date: Sat, 18 Mar 2017 11:51:12 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 22:51:03 -0000 Robert, (cc's trimmed) I remember well, back when serial modems were still the norm, sitting in hotel rooms manually cranking back the IPv4 MTU size on my laptop until it was possible to establish TCP connections. Fortunately, somebody had written a piece of freeware that made this possible on Windows 95. I seem to remember having to set the MTU to 256 in Vienna, for example. It is really unthinkable to me to allow header insertion on the Internet until we have a working solution to PMTUD in all circumstances, which we don't, due to operators misconfiguring middleboxes to drop ICMPv6/PTB, and due to RFC4821 being a rarity.=20 When this major operational problem has been solved, it will be time to seriously consider header insertion (including its very non-trivial security implementations). Regards Brian Carpenter On 18/03/2017 06:06, Robert Raszuk wrote: > All, >=20 > This is very interesting thread indeed. >=20 > I think header insertion at *any* network element be it host, router, > service chain device is highly desired. IPv6 deployments will be much m= ore > successful if we clear any obstacles which otherwise prevent it from > delivering required by customers and operators functionality. >=20 > And I would state that this should be not only limited to one's own IGP= or > BGP domain. It should be legal Internet wide. >=20 > Today Internet as a entire system lacks tools to accomplish path > engineering, fast connectivity restoration, p2mp delivery of content et= c > ... Some of those are possible with MPLS based tools however as we all = know > MPLS has no NNI and does not really work across domains. Here we stand = very > close to have a chance to fix it. >=20 > And if one would forbid by spec the header insertion performed by netwo= rk > elements what's the alternative ... IPv6 in IPv6 encapsulation which ma= y > suffer with even more overhead yet will still require IANA allocation o= f > SRH type as well as TLV codepoints as effectively encapsulating network= > element will be acting as IPv6 sender. >=20 > Concluding I do hope that we can try to collectively make IPv6 protocol= > flexible enough to satisfy customer and operator's requirements what in= > turn will enrich and speed up IPv6 global adoption. >=20 > Kind regards, > Robert. >=20 >=20 > On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John w= rote: >=20 >> Thanks Stewart, >> >> This really supports my point and hopefully not the intent or result o= f >> the discussions here. >> >> We are trying to work through the IETF process to come up with standar= ds >> and solutions that address real operational challenges faced in >> deployments. For operators, dealing with legacy and migrations are a = big >> challenge. >> >> Wishing these issues away and as a result having non-standard >> functionality in =E2=80=9Cmiddle boxes=E2=80=9D that are ignored in th= e architecture is not >> productive. NATs are a way of life, dark space is being deployed by o= ther >> operators, =E2=80=9CCloud=E2=80=9D/NFV/ServiceChaining are active area= s; tunnels, tunnels >> everywhere - PMTU is always an issue. =E2=80=9CTurtles and Tunnels al= l the way >> down=E2=80=9D. >> >> We are very aggressively migrating to a V6 infrastructure, but there i= s a >> large amount of old legacy systems/applications/services that need to = be >> addressed. At the same time the allure of =E2=80=9CCloud=E2=80=9D att= racts systems that >> should never be moved without being re-architected and the virtualizat= ion >> environments fully supporting V6 (both Vendors and OpenSource) =E2=80=93= but they >> do move and vendors help make that possible. >> >> Hopefully we can keep the discussions going and keep tools available u= ntil >> we know we have solutions to deal all the activity happening outside a= >> clean end-to-end Architecture, >> >> John >> >> >> >> On 3/16/17, 6:44 AM, "Stewart Bryant" wrote= : >> >> > In another form, the answer to John is that there are no protoco= l >> police, >> > so what consenting adults do inside their own networks simply is= n't >> an >> > issue that an Internet-wide spec can or should address. >> >> That is not quite true, the inability to gain an IANA allocated >> codepoint can make long >> term private deployments very difficult, either for the protocol >> squatting on a codepoint >> because they could not get one allocated, or to the deployment of = a new >> protocol >> legitimately allocated a conflicting codepoint. >> >> - Stewart >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >=20 From nobody Fri Mar 17 15:55:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5DC12955D; Fri, 17 Mar 2017 15:55:06 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0i2H_BtqcFfD; Fri, 17 Mar 2017 15:55:04 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA902127419; Fri, 17 Mar 2017 15:55:04 -0700 (PDT) Received: from [128.9.184.195] ([128.9.184.195]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2HMsj94026678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Mar 2017 15:54:46 -0700 (PDT) Subject: Re: TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 To: Bob Hinden References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> <41A44496-F222-40D5-95FE-5CE142C3827F@gmail.com> Cc: "tsv-art@ietf.org" , IESG , IPv6 List From: Joe Touch Message-ID: <46d7ae23-cf3d-570d-3d79-9d915663cf16@isi.edu> Date: Fri, 17 Mar 2017 15:54:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <41A44496-F222-40D5-95FE-5CE142C3827F@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MailScanner-ID: v2HMsj94026678 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 22:55:07 -0000 Hi, Bob (et al.), Although I appreciate the goal of avoiding a major rewrite, I cannot see how to advance this document with these substantive errors intact. Moving forward in its current state propagates these errors. Note that there are also two points below that you did not address: - item #4 about ECMP - the minor issue bullet point about the need for fragmentation I'll hold off suggesting text as requested below until you decide how to proceed. Joe On 3/17/2017 2:57 PM, Bob Hinden wrote: > Joe, > > Thanks for the detailed review. > > Several of the reviews have suggested significant changes to this docum= ent. The working group was trying to make a few changes to bring it into= alignment with some changes to rfc2460bis (based on updating documents).= It was not attempting a major rewrite when advancing it to Internet Sta= ndard. The alternative that the working group discussed was to file erra= ta on RFC1981 and leave it to a future document update. > > I don=E2=80=99t think many of these changes can be done and still advan= ce it to Internet Standard. If we can=E2=80=99t advance the current docum= ent, then the w.g. may want to just do the errata and withdraw the advanc= ement request. Of course, if people want to work on a revision of IPv6 P= ath MTU Discovery, it would be welcomed, but it won=E2=80=99t be able to = advanced to Internet Standard. > > Comments below. > > Thanks, > Bob > >> On Feb 15, 2017, at 1:51 PM, Joe Touch wrote: >> >> Document: draft-ietf-6man-rfc1981bis-04 >> Reviewer: Joe Touch >> Review Date: February 15, 2017 >> IETF LC End Date: March 3, 2017 >> IESG Telechat date: February 28, 2017 >> >> Review result: significant issues >> >> NOTE: some of this review is informed by tracking some of the issues r= aised by others on the IETF list, notably Gorry Fairhurst. > In my response to Gorry, I proposed some changes to the document. > >> Major issues: >> >> 1) the current text is insufficiently realistic about the (in)ability = of this mechanism to operate in current networks, regardless of the suppo= rt for generating ICMPs at routers or PMTUD support at endpoints, due to = ICMP filtering for security reasons. [this comment is already being addre= ssed by consensus text] > > As far as I can tell, we don=E2=80=99t have much much information on ho= w much ICMPv6 PTB messages is filter or not. It=E2=80=99s clearly a prob= lem with IPv4 ICMP PTB, but I haven=E2=80=99t see any recent data regardi= ng ICMPv6 PTB messages. IPv6 deployment has increased significantly sinc= e the last data I saw and it may or may not be a significant problem. > > >> 2) the current text is insufficiently clear on on the difference betwe= en the path MTU, which determines the largest supported IPv6 fragment, vs= =2E the effective MTU to receive (EMTU_R), which determines the largest I= P packet that can transit between the source and destination. The documen= t should be more explicit throughput about its goal being to manage or av= oid IPv6 source fragmentation rather than about source to destination pac= ket maximums, and in specific in clearly referring to maximum fragments o= r atomic packets rather than maximum packets. >> >> E.g.: see the following text, which is incorrect in its current form: >> Nodes not implementing Path MTU Discovery use the IPv6 minimum link= >> MTU defined in [ >> I-D.ietf-6man-rfc2460bis >> ] as the maximum packet size. >> >> The value used by either Path MTU Discovery or its default represents = the path MTU, which is the largest IPv6 *fragment* (or atomic packet, see= RFC6864) that can be supported on the path between the endpoints. The ma= ximum IP packet size is limited by the effective MTU to receive (EMTU_R) = [RFC1122], which is at least 1500 bytes for IPv6 and not necessarily rela= ted to the link MTUs. The text should also clearly indicate that there is= no ICMP mechanism for determining larger EMTU_R support. >> >> E.g., the following text is also incorrect in its current form: >> The value sent in the TCP MSS option is independent of the PMTU. >> This MSS option value is used by the other end of the connection, >> which may be using an unrelated PMTU value. >> >> The first sentence is correct because TCP MSS is related to EMTU_R (an= d needs to account for headers, as per RFC6691), and EMTU_R is not direct= ly related to the PMTU (except that it would never be smaller than the PM= TU). The MSS option is calculated from EMTU_R, not PMTU. >> >> In addition, it should be noted that ICMPv6 PTB messages are NOT sent = when source fragmentation is enabled. > I think these are all good issues to cover in a rewrite, but I don=E2=80= =99t see how they can be done now. > >> 3. need verification of current support for some features, esp. regard= ing TCP and NFS interactions >> See Gorry's note of 2/14/17 > Please see my responses to his review. > >> 4. the concept of a single path MTU value between two IP addresses doe= s not account for multipath routing, e.g., ECMP (as currently deployed, n= oted in RFC7690, which should be cited) or BANANA (and its solutions in d= evelopment) See Fred Templin's posts on this on 2/15/17 >> >> Minor issues: >> >> - some of the updates and/or current text could be updated to reflect = current terminology or practice. See Gorry Fairhursts's post of 2/14/17 > I suggest some changes to address some of the issues he raised. > >> - fragmentation, while considered harmful and costly, is absolutely ne= cessary to support tunnels even in the presence of PMTUD. The text on thi= s issue should reflect this reality. >> >> - the requirement that transports be notified of PTB messages might us= efully cite the corresponding IPv4, TCP, and UDP sections of RFC1122 > I think that is doable. Please suggest some specific text. > > >> - section 5.4 should cite and include context from RFC6691, especially= including a discussion of the impact of variable IP EHs on the interacti= on between TCP MSS and ICMP PTB >> > Please suggest some specific text. > > > > >> -- >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Fri Mar 17 16:10:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C99129664; Fri, 17 Mar 2017 16:10:32 -0700 (PDT) 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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6DP5fafcfI_P; Fri, 17 Mar 2017 16:10:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3214129671; Fri, 17 Mar 2017 16:10:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 18BD3B80D93; Fri, 17 Mar 2017 16:10:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 8106 on IPv6 Router Advertisement Options for DNS Configuration X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ipv6@ietf.org Message-Id: <20170317231004.18BD3B80D93@rfc-editor.org> Date: Fri, 17 Mar 2017 16:10:04 -0700 (PDT) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 23:10:33 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8106 Title: IPv6 Router Advertisement Options for DNS Configuration Author: J. Jeong, S. Park, L. Beloeil, S. Madanapalli Status: Standards Track Stream: IETF Date: March 2017 Mailbox: pauljeong@skku.edu, soohong.park@samsung.com, luc.beloeil@orange.com, smadanapalli@gmail.com Pages: 19 Characters: 43092 Obsoletes: RFC 6106 I-D Tag: draft-ietf-6man-rdnss-rfc6106bis-16.txt URL: https://www.rfc-editor.org/info/rfc8106 DOI: 10.17487/RFC8106 This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Mar 17 16:12:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A01124B0A; Fri, 17 Mar 2017 16:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ha1JL9c_hxDr; Fri, 17 Mar 2017 16:12:48 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141551296A4; Fri, 17 Mar 2017 16:11:51 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id w124so38753636itb.1; Fri, 17 Mar 2017 16:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9F3zUQU/lJrvO1QlYxMpZH8ah+JSZZEuWyLDvrcq8TM=; b=sadO/iGMS+DwNidtNLiCHW9/69KXU0HN21uE/tsSC988ES2lVB8hyAkAoBmjL1R7QX 0yecQ4Xx0QPl8hS1PMEZLW8lC5UhUC/y9VuM+hx8ni/VqA/LKGAh6J/a5SWpx5ZtIsor F04ZAcyS3ZfGIR5xpK7NoDNlmjLkZLgou3D09gC7vrdyM6MUT4pdk0sMb+ClolLpzw9U ogtUCsZbMWmnxdJegT+QwOKDt/9jctlDoG7kA4pQfSZ+iUeYOfSLidCMDrPiMyq1NQs0 rQg1oIIFe46NJQYGlzMDO5r79AfuHq1srauC4ChR+EYIODw1fZQQRWQ2+D21+obDBbDE 02DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9F3zUQU/lJrvO1QlYxMpZH8ah+JSZZEuWyLDvrcq8TM=; b=NVuBNyxs21NVoceog9lmTjuc6/GDHzsWLPfymP4N/Hpf1ayvuRuxcWzqtZVSETsSY9 hIL3U4gLQfTbEzEshUeNaA9ey97KFLrd2OYY/zVLuYszgSFfUeOWUpZwZjVNj4dK/ptN j5pLt3zP/f5F1ONUo/LSg5MYdxB2eD5EIfokbDeqFXPvVv4AqhWxatxVpUfJIIB07+F5 e3EEExYGooxY6m3/0KRiiK47mUdCcI6pey5YEsxRuI8sd/tyI2iFJ65Fe3NxafnO0yNy kT9xHvMIZ4Y0Kh6uTAGatriPdo22rxBkT+a6W9o/G8wXE8zVyO3QSjFJB39VVu2Aj+po o5LQ== X-Gm-Message-State: AFeK/H2vgIyaJTkYckbtAgddguZ6VZxCk+J/kBEXYY02o0yIAcIjtUpGV2Cv90cazO2IfSgIIGRWxT2n95d3Jg== X-Received: by 10.36.46.81 with SMTP id i78mr667836ita.39.1489792310377; Fri, 17 Mar 2017 16:11:50 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.35.207 with HTTP; Fri, 17 Mar 2017 16:11:49 -0700 (PDT) In-Reply-To: <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> From: Robert Raszuk Date: Sat, 18 Mar 2017 00:11:49 +0100 X-Google-Sender-Auth: V0rU-6c01-YlTpC0FLNxslQEX4Q Message-ID: Subject: Re: Manual PMTUD [was ...rfc2460bis-08] To: Brian E Carpenter Cc: "Leddy, John" , Stewart Bryant , Tim Chown , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG Content-Type: multipart/alternative; boundary=001a114a93ce7311f2054af54d52 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 23:12:52 -0000 --001a114a93ce7311f2054af54d52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Brian, I do suffer from MTU issues over both intranets and Internet the same way as you do ... or maybe even more. As example there are transit ISPs out there who provide now extra new fancy services of DDoS detection except they do not tell that to direct your data stream packets to screening devices they encapsulate it in another entire IP header to redirect it to this service. MPLS encapsulation is also another one. While other then 6PE it happily leaves v6 Internet alone there are active proposals in IETF to take it on target as well. However allowing or not allowing header insertion into IPv6 is IMHO orthogonal here. The fact that you forbid it will only result in bigger size encapsulation hence lower effective MTU. Services have moved to overlay and that requires decoupling them from transport. And in some networks service is not just fancy firewall or load balancer ... service is basic IPv4 lookup, basic VPN segmentation or tenant micro segmentation. And the last one even if it starts on end host it starts not in sourcing VM, but in the forwarding host OS kernel's RIB. MTU is a valid problem and we should work on it but I don't think it should stop IPv6 based services and IPv6 innovation till it is solved. I can use today SRv6 features in my data centers where I consistently know that all interfaces are set for jumbo frames and where hopefully I do not need to worry about MTU since hosts have much lower max MTU configured. Kind regards, Robert. On Fri, Mar 17, 2017 at 11:51 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Robert, > > (cc's trimmed) > > I remember well, back when serial modems were still the norm, sitting > in hotel rooms manually cranking back the IPv4 MTU size on my laptop > until it was possible to establish TCP connections. Fortunately, > somebody had written a piece of freeware that made this possible on > Windows 95. I seem to remember having to set the MTU to 256 in Vienna, > for example. > > It is really unthinkable to me to allow header insertion on the Internet > until we have a working solution to PMTUD in all circumstances, which we > don't, due to operators misconfiguring middleboxes to drop ICMPv6/PTB, > and due to RFC4821 being a rarity. > > When this major operational problem has been solved, it will be time to > seriously consider header insertion (including its very non-trivial > security implementations). > > Regards > Brian Carpenter > > > > On 18/03/2017 06:06, Robert Raszuk wrote: > > All, > > > > This is very interesting thread indeed. > > > > I think header insertion at *any* network element be it host, router, > > service chain device is highly desired. IPv6 deployments will be much > more > > successful if we clear any obstacles which otherwise prevent it from > > delivering required by customers and operators functionality. > > > > And I would state that this should be not only limited to one's own IGP > or > > BGP domain. It should be legal Internet wide. > > > > Today Internet as a entire system lacks tools to accomplish path > > engineering, fast connectivity restoration, p2mp delivery of content et= c > > ... Some of those are possible with MPLS based tools however as we all > know > > MPLS has no NNI and does not really work across domains. Here we stand > very > > close to have a chance to fix it. > > > > And if one would forbid by spec the header insertion performed by netwo= rk > > elements what's the alternative ... IPv6 in IPv6 encapsulation which ma= y > > suffer with even more overhead yet will still require IANA allocation o= f > > SRH type as well as TLV codepoints as effectively encapsulating network > > element will be acting as IPv6 sender. > > > > Concluding I do hope that we can try to collectively make IPv6 protocol > > flexible enough to satisfy customer and operator's requirements what in > > turn will enrich and speed up IPv6 global adoption. > > > > Kind regards, > > Robert. > > > > > > On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John > wrote: > > > >> Thanks Stewart, > >> > >> This really supports my point and hopefully not the intent or result o= f > >> the discussions here. > >> > >> We are trying to work through the IETF process to come up with standar= ds > >> and solutions that address real operational challenges faced in > >> deployments. For operators, dealing with legacy and migrations are a > big > >> challenge. > >> > >> Wishing these issues away and as a result having non-standard > >> functionality in =E2=80=9Cmiddle boxes=E2=80=9D that are ignored in th= e architecture is > not > >> productive. NATs are a way of life, dark space is being deployed by > other > >> operators, =E2=80=9CCloud=E2=80=9D/NFV/ServiceChaining are active area= s; tunnels, > tunnels > >> everywhere - PMTU is always an issue. =E2=80=9CTurtles and Tunnels al= l the way > >> down=E2=80=9D. > >> > >> We are very aggressively migrating to a V6 infrastructure, but there i= s > a > >> large amount of old legacy systems/applications/services that need to = be > >> addressed. At the same time the allure of =E2=80=9CCloud=E2=80=9D att= racts systems that > >> should never be moved without being re-architected and the > virtualization > >> environments fully supporting V6 (both Vendors and OpenSource) =E2=80= =93 but > they > >> do move and vendors help make that possible. > >> > >> Hopefully we can keep the discussions going and keep tools available > until > >> we know we have solutions to deal all the activity happening outside a > >> clean end-to-end Architecture, > >> > >> John > >> > >> > >> > >> On 3/16/17, 6:44 AM, "Stewart Bryant" wrote= : > >> > >> > In another form, the answer to John is that there are no protoco= l > >> police, > >> > so what consenting adults do inside their own networks simply > isn't > >> an > >> > issue that an Internet-wide spec can or should address. > >> > >> That is not quite true, the inability to gain an IANA allocated > >> codepoint can make long > >> term private deployments very difficult, either for the protocol > >> squatting on a codepoint > >> because they could not get one allocated, or to the deployment of = a > new > >> protocol > >> legitimately allocated a conflicting codepoint. > >> > >> - Stewart > >> > >> > >> > >> > >> > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > > > > --001a114a93ce7311f2054af54d52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello Brian,
    I do suffer from MTU issues over both intranets = and Internet the same way as you do ... or maybe even more.=C2=A0

    As example there are transit IS= Ps out there who provide now extra new fancy services of DDoS detection exc= ept they do not tell that to direct your data stream packets to screening d= evices they encapsulate it in another entire IP header to redirect it to th= is service.=C2=A0

    MPLS= encapsulation is also another one. While other then 6PE it happily leaves = v6 Internet alone there are active proposals in IETF to take it on target a= s well.=C2=A0

    However = allowing or not allowing header insertion into IPv6 is IMHO orthogonal here= . The fact that you forbid it will only result in bigger size encapsulation= hence lower effective MTU. Services have moved to overlay and that require= s decoupling them from transport. And in some networks service is not just = fancy firewall or load balancer ... service is basic IPv4 lookup, basic VPN= segmentation or tenant micro segmentation. And the last one even if it sta= rts on end host it starts not in sourcing VM, but in the forwarding host OS= kernel's RIB.=C2=A0

    MTU is a valid problem and we should work on it but I don't think it= should stop IPv6 based services and IPv6 innovation till it is solved. I c= an use today SRv6 features in my data centers where I consistently know tha= t all interfaces are set for jumbo frames and where hopefully I do not need= to worry about MTU since hosts have much lower max MTU configured.=C2=A0

    Kind regards,
    Robert.


    On Fri, Mar 17, 2017 at 11:51 PM, B= rian E Carpenter <brian.e.carpenter@gmail.com> wro= te:
    Robert,

    (cc's trimmed)

    I remember well, back when serial modems were still the norm, sitting
    in hotel rooms manually cranking back the IPv4 MTU size on my laptop
    until it was possible to establish TCP connections. Fortunately,
    somebody had written a piece of freeware that made this possible on
    Windows 95. I seem to remember having to set the MTU to 256 in Vienna,
    for example.

    It is really unthinkable to me to allow header insertion on the Internet until we have a working solution to PMTUD in all circumstances, which we don't, due to operators misconfiguring middleboxes to drop ICMPv6/PTB,<= br> and due to RFC4821 being a rarity.

    When this major operational problem has been solved, it will be time to
    seriously consider header insertion (including its very non-trivial
    security implementations).

    Regards
    =C2=A0 =C2=A0Brian Carpenter



    On 18/03/2017 06:06, Robert Raszuk wrote:
    > All,
    >
    > This is very interesting thread indeed.
    >
    > I think header insertion at *any* network element be it host, router,<= br> > service chain device is highly desired. IPv6 deployments will be much = more
    > successful if we clear any obstacles which otherwise prevent it from > delivering required by customers and operators functionality.
    >
    > And I would state that this should be not only limited to one's ow= n IGP or
    > BGP domain. It should be legal Internet wide.
    >
    > Today Internet as a entire system lacks tools to accomplish path
    > engineering, fast connectivity restoration, p2mp delivery of content e= tc
    > ... Some of those are possible with MPLS based tools however as we all= know
    > MPLS has no NNI and does not really work across domains. Here we stand= very
    > close to have a chance to fix it.
    >
    > And if one would forbid by spec the header insertion performed by netw= ork
    > elements what's the alternative ... IPv6 in IPv6 encapsulation whi= ch may
    > suffer with even more overhead yet will still require IANA allocation = of
    > SRH type as well as TLV codepoints as effectively encapsulating networ= k
    > element will be acting as IPv6 sender.
    >
    > Concluding I do hope that we can try to collectively make IPv6 protoco= l
    > flexible enough to satisfy customer and operator's requirements wh= at in
    > turn will enrich and speed up IPv6 global adoption.
    >
    > Kind regards,
    > Robert.
    >
    >
    > On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John <John_Leddy@comcast.com> wrote:
    >
    >> Thanks Stewart,
    >>
    >> This really supports my point and hopefully not the intent or resu= lt of
    >> the discussions here.
    >>
    >> We are trying to work through the IETF process to come up with sta= ndards
    >> and solutions that address real operational challenges faced in >> deployments.=C2=A0 For operators, dealing with legacy and migratio= ns are a big
    >> challenge.
    >>
    >> Wishing these issues away and as a result having non-standard
    >> functionality in =E2=80=9Cmiddle boxes=E2=80=9D that are ignored i= n the architecture is not
    >> productive.=C2=A0 NATs are a way of life, dark space is being depl= oyed by other
    >> operators, =E2=80=9CCloud=E2=80=9D/NFV/ServiceChaining are active = areas; tunnels, tunnels
    >> everywhere - PMTU is always an issue.=C2=A0 =E2=80=9CTurtles and T= unnels all the way
    >> down=E2=80=9D.
    >>
    >> We are very aggressively migrating to a V6 infrastructure, but the= re is a
    >> large amount of old legacy systems/applications/services that need= to be
    >> addressed.=C2=A0 At the same time the allure of =E2=80=9CCloud=E2= =80=9D attracts systems that
    >> should never be moved without being re-architected and the virtual= ization
    >> environments fully supporting V6 (both Vendors and OpenSource) =E2= =80=93 but they
    >> do move and vendors help make that possible.
    >>
    >> Hopefully we can keep the discussions going and keep tools availab= le until
    >> we know we have solutions to deal all the activity happening outsi= de a
    >> clean end-to-end Architecture,
    >>
    >> John
    >>
    >>
    >>
    >> On 3/16/17, 6:44 AM, "Stewart Bryant" <stewart.bryant@gmail.com> wrote:
    >>
    >>=C2=A0 =C2=A0 =C2=A0> In another form, the answer to John is tha= t there are no protocol
    >> police,
    >>=C2=A0 =C2=A0 =C2=A0> so what consenting adults do inside their = own networks simply isn't
    >> an
    >>=C2=A0 =C2=A0 =C2=A0> issue that an Internet-wide spec can or sh= ould address.
    >>
    >>=C2=A0 =C2=A0 =C2=A0That is not quite true, the inability to gain a= n IANA allocated
    >>=C2=A0 =C2=A0 =C2=A0codepoint can make long
    >>=C2=A0 =C2=A0 =C2=A0term private deployments very difficult, either= for the protocol
    >>=C2=A0 =C2=A0 =C2=A0squatting on a codepoint
    >>=C2=A0 =C2=A0 =C2=A0because they could not get one allocated, or to= the deployment of a new
    >>=C2=A0 =C2=A0 =C2=A0protocol
    >>=C2=A0 =C2=A0 =C2=A0legitimately allocated a conflicting codepoint.=
    >>
    >>=C2=A0 =C2=A0 =C2=A0- Stewart
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >> ------------------------------------------------------------<= wbr>--------
    >> IETF IPv6 working group mailing list
    >> ipv6@ietf.org
    >> Administrative Requests: https://www.ietf.org/mai= lman/listinfo/ipv6
    >> ------------------------------------------------------------<= wbr>--------
    >>
    >


    --001a114a93ce7311f2054af54d52-- From nobody Fri Mar 17 16:31:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE03C12955D; Fri, 17 Mar 2017 16:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 n92xgTLhk1yH; Fri, 17 Mar 2017 16:31:36 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F3C127419; Fri, 17 Mar 2017 16:31:36 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id i34so74652870qtc.0; Fri, 17 Mar 2017 16:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=P3kh5vmzno6W3bkaQjzPsLbPzLVzrDaccTzCh3Z/Puk=; b=Z5/8h26rd2OSNRjnEnu/Nam+wi7vLTamEumOT2T7L6z+5HtSNGeLRqdTH1JzRZJ4iJ bO4X/odOkBF/5fXRbwG76XHT4af9KwxTijWoPqxe91EWXrsUSVAt0w7qZIuLG9RV8W6J Zr9l3SpUi7XN1sfo4toKxk80Mu1DVOnNLwFwodMcg7NNLSpuuxa0IUn29G+m3gicE/c1 BDhyRnRO7ixm0dIzv9ZnpbbixNgK7HmuWslcNo4xnwDVrtHl6uQijF3YynzXfYal/VM6 TG+r1T3PzHSnFYgLDCBORDkHCyJbx/UoJbs8jPN5g6yW6mMFkZKyGRX9d5Y9mROGbkqW UwOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=P3kh5vmzno6W3bkaQjzPsLbPzLVzrDaccTzCh3Z/Puk=; b=JeURKBvFzff91FVV/F493zdlx16XFwfzoFNEyqr85bRVId2aOitgkSIETuKB8aa4qn 5p86O8vqLw7x/10GIt26Z/6w56TVI5jhuXXj6CkRmkAD79Bl5M/oORWWtTkXE0zyrg/n w2aobqvcfyteTFsm0OYyZd82XkcLEe9qp2+kVsV3pftx40ctwyh97gHHdtwoiZhho1FR agmp1gt0PU+GHtvtICCcCZYqKR5+sDRh7cutdCUeTyBJgjL1Y8a5mkG80IJRtOaaPaPG D0Y8rblk5/xmf7Eq863XCOz5sY8OlqzzVoEz/m+K1Gn3nORnoJS1mlZgEmiju6DqXPlw 835w== X-Gm-Message-State: AFeK/H1CSvWhF0aGlqXXLcE+F2HNtmSFTXNvkKiXfpCkiVjYswuzlYF8kmzycuMGlmMH/g== X-Received: by 10.200.55.82 with SMTP id p18mr10438020qtb.285.1489793495725; Fri, 17 Mar 2017 16:31:35 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id g143sm1292831qke.58.2017.03.17.16.31.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 16:31:34 -0700 (PDT) From: Bob Hinden Message-Id: <8D6CA1F7-CB01-4FCD-B81C-ECBEFC088EAE@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7CD741D0-B121-4CF5-9FE3-E64C534B4913"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 Date: Fri, 17 Mar 2017 16:31:32 -0700 In-Reply-To: <46d7ae23-cf3d-570d-3d79-9d915663cf16@isi.edu> Cc: Bob Hinden , "tsv-art@ietf.org" , IESG , IPv6 List To: Joe Touch References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> <41A44496-F222-40D5-95FE-5CE142C3827F@gmail.com> <46d7ae23-cf3d-570d-3d79-9d915663cf16@isi.edu> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 23:31:39 -0000 --Apple-Mail=_7CD741D0-B121-4CF5-9FE3-E64C534B4913 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joe, I think this will be up to the AD and IESG. If you (and others) want to work on a major update, I am happy to share = the XML. I hope we don=E2=80=99t end up with can=E2=80=99t move the = current document forward, and no one wants to do a major update. Thanks, Bob > On Mar 17, 2017, at 3:54 PM, Joe Touch wrote: >=20 > Hi, Bob (et al.), >=20 > Although I appreciate the goal of avoiding a major rewrite, I cannot = see > how to advance this document with these substantive errors intact. > Moving forward in its current state propagates these errors. >=20 > Note that there are also two points below that you did not address: >=20 > - item #4 about ECMP >=20 > - the minor issue bullet point about the need for fragmentation >=20 > I'll hold off suggesting text as requested below until you decide how = to > proceed. >=20 > Joe >=20 >=20 > On 3/17/2017 2:57 PM, Bob Hinden wrote: >> Joe, >>=20 >> Thanks for the detailed review. >>=20 >> Several of the reviews have suggested significant changes to this = document. The working group was trying to make a few changes to bring = it into alignment with some changes to rfc2460bis (based on updating = documents). It was not attempting a major rewrite when advancing it to = Internet Standard. The alternative that the working group discussed was = to file errata on RFC1981 and leave it to a future document update. >>=20 >> I don=E2=80=99t think many of these changes can be done and still = advance it to Internet Standard. If we can=E2=80=99t advance the current = document, then the w.g. may want to just do the errata and withdraw the = advancement request. Of course, if people want to work on a revision of = IPv6 Path MTU Discovery, it would be welcomed, but it won=E2=80=99t be = able to advanced to Internet Standard. >>=20 >> Comments below. >>=20 >> Thanks, >> Bob >>=20 >>> On Feb 15, 2017, at 1:51 PM, Joe Touch wrote: >>>=20 >>> Document: draft-ietf-6man-rfc1981bis-04 >>> Reviewer: Joe Touch >>> Review Date: February 15, 2017 >>> IETF LC End Date: March 3, 2017 >>> IESG Telechat date: February 28, 2017 >>>=20 >>> Review result: significant issues >>>=20 >>> NOTE: some of this review is informed by tracking some of the issues = raised by others on the IETF list, notably Gorry Fairhurst. >> In my response to Gorry, I proposed some changes to the document. >>=20 >>> Major issues: >>>=20 >>> 1) the current text is insufficiently realistic about the = (in)ability of this mechanism to operate in current networks, regardless = of the support for generating ICMPs at routers or PMTUD support at = endpoints, due to ICMP filtering for security reasons. [this comment is = already being addressed by consensus text] >>=20 >> As far as I can tell, we don=E2=80=99t have much much information on = how much ICMPv6 PTB messages is filter or not. It=E2=80=99s clearly a = problem with IPv4 ICMP PTB, but I haven=E2=80=99t see any recent data = regarding ICMPv6 PTB messages. IPv6 deployment has increased = significantly since the last data I saw and it may or may not be a = significant problem. >>=20 >>=20 >>> 2) the current text is insufficiently clear on on the difference = between the path MTU, which determines the largest supported IPv6 = fragment, vs. the effective MTU to receive (EMTU_R), which determines = the largest IP packet that can transit between the source and = destination. The document should be more explicit throughput about its = goal being to manage or avoid IPv6 source fragmentation rather than = about source to destination packet maximums, and in specific in clearly = referring to maximum fragments or atomic packets rather than maximum = packets. >>>=20 >>> E.g.: see the following text, which is incorrect in its current = form: >>> Nodes not implementing Path MTU Discovery use the IPv6 minimum = link >>> MTU defined in [ >>> I-D.ietf-6man-rfc2460bis >>> ] as the maximum packet size. >>>=20 >>> The value used by either Path MTU Discovery or its default = represents the path MTU, which is the largest IPv6 *fragment* (or atomic = packet, see RFC6864) that can be supported on the path between the = endpoints. The maximum IP packet size is limited by the effective MTU to = receive (EMTU_R) [RFC1122], which is at least 1500 bytes for IPv6 and = not necessarily related to the link MTUs. The text should also clearly = indicate that there is no ICMP mechanism for determining larger EMTU_R = support. >>>=20 >>> E.g., the following text is also incorrect in its current form: >>> The value sent in the TCP MSS option is independent of the PMTU. >>> This MSS option value is used by the other end of the connection, >>> which may be using an unrelated PMTU value. >>>=20 >>> The first sentence is correct because TCP MSS is related to EMTU_R = (and needs to account for headers, as per RFC6691), and EMTU_R is not = directly related to the PMTU (except that it would never be smaller than = the PMTU). The MSS option is calculated from EMTU_R, not PMTU. >>>=20 >>> In addition, it should be noted that ICMPv6 PTB messages are NOT = sent when source fragmentation is enabled. >> I think these are all good issues to cover in a rewrite, but I = don=E2=80=99t see how they can be done now. >>=20 >>> 3. need verification of current support for some features, esp. = regarding TCP and NFS interactions >>> See Gorry's note of 2/14/17 >> Please see my responses to his review. >>=20 >>> 4. the concept of a single path MTU value between two IP addresses = does not account for multipath routing, e.g., ECMP (as currently = deployed, noted in RFC7690, which should be cited) or BANANA (and its = solutions in development) See Fred Templin's posts on this on 2/15/17 >>>=20 >>> Minor issues: >>>=20 >>> - some of the updates and/or current text could be updated to = reflect current terminology or practice. See Gorry Fairhursts's post of = 2/14/17 >> I suggest some changes to address some of the issues he raised. >>=20 >>> - fragmentation, while considered harmful and costly, is absolutely = necessary to support tunnels even in the presence of PMTUD. The text on = this issue should reflect this reality. >>>=20 >>> - the requirement that transports be notified of PTB messages might = usefully cite the corresponding IPv4, TCP, and UDP sections of RFC1122 >> I think that is doable. Please suggest some specific text. >>=20 >>=20 >>> - section 5.4 should cite and include context from RFC6691, = especially including a discussion of the impact of variable IP EHs on = the interaction between TCP MSS and ICMP PTB >>>=20 >> Please suggest some specific text. >>=20 >>=20 >>=20 >>=20 >>> -- >>>=20 >>>=20 >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >=20 >=20 --Apple-Mail=_7CD741D0-B121-4CF5-9FE3-E64C534B4913 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYzHHUAAoJEK7rdBF357uo3GcH/jgaDZirgLr/JBK0UOgCJ7ty f2eChUEe4LHSOCBbZetm1WKb+xC89MWmvCUEDjakAJ9eC36dXIIie5cGrCZl5Q8n eP4F9X4Xh2ROavU+o1CjP1XSfGCtbreY03j9ZiK4Pee32uJY+gj/edWIxvvoM8r+ 0xkECuLu+euYR6Yg/w/+Tu2AoYSWLaQH/pkxyUN+YKSaR1Hk5P2iCw3oxyslb5L9 8q830RMCgTaeUPynAm/jYV29iQYlGD6zGFVuYeDkQjbPdHcM2K2gX+s9mc616xzi GXxJjStgfhyKG5Gdn+UAXnHpOlJlGYUXluwgFxptbV/DFXwDAuiTGcPusudsvLA= =aTsp -----END PGP SIGNATURE----- --Apple-Mail=_7CD741D0-B121-4CF5-9FE3-E64C534B4913-- From nobody Fri Mar 17 17:36:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E571129630; Fri, 17 Mar 2017 17:36:36 -0700 (PDT) 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 autolearn_force=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 TlnkGvLfMqOs; Fri, 17 Mar 2017 17:36:35 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9755912966D; Fri, 17 Mar 2017 17:36:30 -0700 (PDT) Received: from [128.9.184.195] ([128.9.184.195]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2I0aEnw029134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Mar 2017 17:36:14 -0700 (PDT) Subject: Re: TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 To: Bob Hinden References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> <41A44496-F222-40D5-95FE-5CE142C3827F@gmail.com> <46d7ae23-cf3d-570d-3d79-9d915663cf16@isi.edu> <8D6CA1F7-CB01-4FCD-B81C-ECBEFC088EAE@gmail.com> Cc: "tsv-art@ietf.org" , IESG , IPv6 List From: Joe Touch Message-ID: Date: Fri, 17 Mar 2017 17:36:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8D6CA1F7-CB01-4FCD-B81C-ECBEFC088EAE@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: v2I0aEnw029134 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 00:36:37 -0000 On 3/17/2017 4:31 PM, Bob Hinden wrote: > Joe, > > I think this will be up to the AD and IESG. OK - I'll wait for them to respond. > If you (and others) want to work on a major update, I am happy to share the XML. I hope we don’t end up with can’t move the current document forward, and no one wants to do a major update. I'd certainly prefer to have this doc address these issues. One question - if a major update occurred, would that be at the same standard level? If so, and if these issues are of concern, I'd be glad to take that on. If a major rev is a standards-level setback, that would be less useful. I'd like to hear their views... Joe From nobody Fri Mar 17 18:18:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42B31298CF; Fri, 17 Mar 2017 18:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JwqA41V8Ul-E; Fri, 17 Mar 2017 18:18:49 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099731297EB; Fri, 17 Mar 2017 18:10:40 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id y76so77454695qkb.0; Fri, 17 Mar 2017 18:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PwM9JfHJlK+Bi7c2oGZPFz+dnzJAdtjcfgPzwdD6jF8=; b=i/AbgiwQ4Me98WlHHQmiGK7QenWojANYQyiiobc5BEFrgaB8g4ZJJyJUnJri6lGj9c V2EeEDfCrbs9cp15hQDuBtSjxgzkJquyvra4UFlwVgvIi2OwppEDRgUF7xkExmUjHIad KkUu/2WStp5/kGcAet1VbAU+xocNz+wDiM/kYBgzmw3Re+vmsQaULmFHTrcHkjJN8gl7 fGSK/VQcb78YzWKsoFAvKXa0X0B8dZyMk7rGTpH9vBxHd5pY8cFgX2oVl989c3arsGAP vzN9WyqYVTlmNY4iYBaq60qojgJggDmOP7q5x5E9quF1PC9BnJ4+kwqXv+CM4deAuVj0 PInQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=PwM9JfHJlK+Bi7c2oGZPFz+dnzJAdtjcfgPzwdD6jF8=; b=rZ4B7Y8Qt7nFfgpWn1OxrI+pOvPxJpD8Gqib1yV2az3vTXZisWuqU62UaYM36z9X0Z o175iEiZvns/3hr+hcgRieVh3zbMJ7ySpmNKvn8kWXsr6Z7VnDpVAyBENPCNJmUTDJam g4RPHCmK8u53cpxxSqxpKR0Z7VeZH1yiyY2G5LBPoc4LNhIibzWRa5nek4Z6NH1vC6J7 qjILmL/9jfiy5LNHpmIdasSha5NQ2ttH5AWo3AHpORhdmREke1/hhIg4+TKb+SHIc0h7 xloq03cUGEWC+KYLm8dPocMalzfNIYXxFKK6iAASjZTLSQnJgDPwhp6r9wKMaMpHCwUh 1ASg== X-Gm-Message-State: AFeK/H3d2yLL6T7msXkn9F0OAHEgIOIFK9bGaAWwb9rBcqB/1PZF89655V1fjQKPLyPC9g== X-Received: by 10.55.203.154 with SMTP id u26mr3799761qkl.220.1489799439080; Fri, 17 Mar 2017 18:10:39 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id q11sm7155649qkh.16.2017.03.17.18.10.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 18:10:38 -0700 (PDT) Subject: Re: Manual PMTUD [was ...rfc2460bis-08] To: Robert Raszuk References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> Cc: "Leddy, John" , Stewart Bryant , Tim Chown , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <618152cf-b097-6d39-e3eb-84b676fb56b7@gmail.com> Date: Sat, 18 Mar 2017 14:10:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 01:18:52 -0000 > I can use > today SRv6 features in my data centers where I consistently know that a= ll > interfaces are set for jumbo frames and where hopefully I do not need t= o > worry about MTU since hosts have much lower max MTU configured. Exactly. That's not the Internet. Internet Standards are for the Internet= , hence I believe that the AD's decision is the correct one. (How would you feel about an extension header that MAY be deleted by an intermediate node, and MUST be deleted if the next hop's link MTU is too small? That's the sort of complexity that allowing header insertion would require in order to be acceptable across the Internet with broken PMTUD that we have. Also PTB semantics would have to change from "PMTU is N bytes" to "Packet exceeded link MTU by X bytes", since the source has no idea how much has been added by intermediate systems. Or perhaps the intermediate systems would have to send back a new ICMPv6 message saying "I extended your packet by Y bytes." This is not straightforward.) Regards Brian On 18/03/2017 12:11, Robert Raszuk wrote: > Hello Brian, >=20 > I do suffer from MTU issues over both intranets and Internet the same w= ay > as you do ... or maybe even more. >=20 > As example there are transit ISPs out there who provide now extra new f= ancy > services of DDoS detection except they do not tell that to direct your = data > stream packets to screening devices they encapsulate it in another enti= re > IP header to redirect it to this service. >=20 > MPLS encapsulation is also another one. While other then 6PE it happily= > leaves v6 Internet alone there are active proposals in IETF to take it = on > target as well. >=20 > However allowing or not allowing header insertion into IPv6 is IMHO > orthogonal here. The fact that you forbid it will only result in bigger= > size encapsulation hence lower effective MTU. Services have moved to > overlay and that requires decoupling them from transport. And in some > networks service is not just fancy firewall or load balancer ... servic= e is > basic IPv4 lookup, basic VPN segmentation or tenant micro segmentation.= And > the last one even if it starts on end host it starts not in sourcing VM= , > but in the forwarding host OS kernel's RIB. >=20 > MTU is a valid problem and we should work on it but I don't think it sh= ould > stop IPv6 based services and IPv6 innovation till it is solved. I can u= se > today SRv6 features in my data centers where I consistently know that a= ll > interfaces are set for jumbo frames and where hopefully I do not need t= o > worry about MTU since hosts have much lower max MTU configured. >=20 > Kind regards, > Robert. >=20 >=20 > On Fri, Mar 17, 2017 at 11:51 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> Robert, >> >> (cc's trimmed) >> >> I remember well, back when serial modems were still the norm, sitting >> in hotel rooms manually cranking back the IPv4 MTU size on my laptop >> until it was possible to establish TCP connections. Fortunately, >> somebody had written a piece of freeware that made this possible on >> Windows 95. I seem to remember having to set the MTU to 256 in Vienna,= >> for example. >> >> It is really unthinkable to me to allow header insertion on the Intern= et >> until we have a working solution to PMTUD in all circumstances, which = we >> don't, due to operators misconfiguring middleboxes to drop ICMPv6/PTB,= >> and due to RFC4821 being a rarity. >> >> When this major operational problem has been solved, it will be time t= o >> seriously consider header insertion (including its very non-trivial >> security implementations). >> >> Regards >> Brian Carpenter >> >> >> >> On 18/03/2017 06:06, Robert Raszuk wrote: >>> All, >>> >>> This is very interesting thread indeed. >>> >>> I think header insertion at *any* network element be it host, router,= >>> service chain device is highly desired. IPv6 deployments will be much= >> more >>> successful if we clear any obstacles which otherwise prevent it from >>> delivering required by customers and operators functionality. >>> >>> And I would state that this should be not only limited to one's own I= GP >> or >>> BGP domain. It should be legal Internet wide. >>> >>> Today Internet as a entire system lacks tools to accomplish path >>> engineering, fast connectivity restoration, p2mp delivery of content = etc >>> ... Some of those are possible with MPLS based tools however as we al= l >> know >>> MPLS has no NNI and does not really work across domains. Here we stan= d >> very >>> close to have a chance to fix it. >>> >>> And if one would forbid by spec the header insertion performed by net= work >>> elements what's the alternative ... IPv6 in IPv6 encapsulation which = may >>> suffer with even more overhead yet will still require IANA allocation= of >>> SRH type as well as TLV codepoints as effectively encapsulating netwo= rk >>> element will be acting as IPv6 sender. >>> >>> Concluding I do hope that we can try to collectively make IPv6 protoc= ol >>> flexible enough to satisfy customer and operator's requirements what = in >>> turn will enrich and speed up IPv6 global adoption. >>> >>> Kind regards, >>> Robert. >>> >>> >>> On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John = >> wrote: >>> >>>> Thanks Stewart, >>>> >>>> This really supports my point and hopefully not the intent or result= of >>>> the discussions here. >>>> >>>> We are trying to work through the IETF process to come up with stand= ards >>>> and solutions that address real operational challenges faced in >>>> deployments. For operators, dealing with legacy and migrations are = a >> big >>>> challenge. >>>> >>>> Wishing these issues away and as a result having non-standard >>>> functionality in =E2=80=9Cmiddle boxes=E2=80=9D that are ignored in = the architecture is >> not >>>> productive. NATs are a way of life, dark space is being deployed by= >> other >>>> operators, =E2=80=9CCloud=E2=80=9D/NFV/ServiceChaining are active ar= eas; tunnels, >> tunnels >>>> everywhere - PMTU is always an issue. =E2=80=9CTurtles and Tunnels = all the way >>>> down=E2=80=9D. >>>> >>>> We are very aggressively migrating to a V6 infrastructure, but there= is >> a >>>> large amount of old legacy systems/applications/services that need t= o be >>>> addressed. At the same time the allure of =E2=80=9CCloud=E2=80=9D a= ttracts systems that >>>> should never be moved without being re-architected and the >> virtualization >>>> environments fully supporting V6 (both Vendors and OpenSource) =E2=80= =93 but >> they >>>> do move and vendors help make that possible. >>>> >>>> Hopefully we can keep the discussions going and keep tools available= >> until >>>> we know we have solutions to deal all the activity happening outside= a >>>> clean end-to-end Architecture, >>>> >>>> John >>>> >>>> >>>> >>>> On 3/16/17, 6:44 AM, "Stewart Bryant" wro= te: >>>> >>>> > In another form, the answer to John is that there are no proto= col >>>> police, >>>> > so what consenting adults do inside their own networks simply >> isn't >>>> an >>>> > issue that an Internet-wide spec can or should address. >>>> >>>> That is not quite true, the inability to gain an IANA allocated >>>> codepoint can make long >>>> term private deployments very difficult, either for the protocol= >>>> squatting on a codepoint >>>> because they could not get one allocated, or to the deployment o= f a >> new >>>> protocol >>>> legitimately allocated a conflicting codepoint. >>>> >>>> - Stewart >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------= >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> --------------------------------------------------------------------= >>>> >>> >> >> >=20 From nobody Fri Mar 17 18:33:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844681296AF; Fri, 17 Mar 2017 18:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EGk7NKwBD-5P; Fri, 17 Mar 2017 18:33:28 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457FC1296FD; Fri, 17 Mar 2017 18:31:43 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id x75so49394607vke.2; Fri, 17 Mar 2017 18:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vHDV1DtJ2rGlnio/wkb0FX1e4diPbG8vlXGL9DeXnT8=; b=XQjQsNlNOqnacY1WNSRCtyBbE+/l5cuoMmsDd0XsEYwtdci9eLzAzLmLRUSAfHn4el L62AfKJkCiUbkuo4XX3QmPRVuAzBTjNHzunxBwKsQWdRs94OKoJijNiDqomKaCNp1PGv 89i4VmdH6TLjWcjZTmG6MIoWKEUcm5Q573t1Bkr9YCHmLqAOWwPHmxuZ39708S0Qt2KK Be5GFN6xFAX6jpJcX1wQcVsWI8SKN3GzTO/SHqoV5gDugoh3Y1pGh61uGKvOnRiFex/d nvESiYNlaSYaqjL0JEx09RuWBJOKTWhVwBaHml3RFBKP4aAL3Ut6w5q9Jgx6AJwMBssw RcJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vHDV1DtJ2rGlnio/wkb0FX1e4diPbG8vlXGL9DeXnT8=; b=AmGlksZXFOHvXFx+QtvCbUj2NtjZXERbnaLLySI45zP1oFix042k33dz4Z8YhhOmDq 7XC+KkqNc056vkS2IBf5fDve8PZXvQkPL+pwtilgeUW5JqUf7hMKQqmHZ8NKCLv+O4yw hZJecXI1IztaU4n2XNkLklNhaXhJ76yxcbZw6DYXXHAoIHkfHJiQidcsUtJv6hUbLIFE 57G/NHtoOBQK8WEAY19bCS21uJrO+6fngUd5494ObuJzRQTCqJLWeW7ZtBWgnAuc8teH 1DOiShHwOis3btIKRzj0Tr8v/JM6jkaGCE+VUNRVlwrS0P94oAFFfzheg1hhB3FcHl8n +oLQ== X-Gm-Message-State: AFeK/H0PcSDv03aFohO3/yL6SGFVnibr4U0NxRnO46ngHrg2QVJyBcS6U6CbRy2LSmYFQ22b4aBFcrYPS6dKkg== X-Received: by 10.31.51.12 with SMTP id z12mr2623350vkz.69.1489800702232; Fri, 17 Mar 2017 18:31:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.144 with HTTP; Fri, 17 Mar 2017 18:31:11 -0700 (PDT) In-Reply-To: <618152cf-b097-6d39-e3eb-84b676fb56b7@gmail.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <618152cf-b097-6d39-e3eb-84b676fb56b7@gmail.com> From: Mark Smith Date: Sat, 18 Mar 2017 12:31:11 +1100 Message-ID: Subject: Re: Manual PMTUD [was ...rfc2460bis-08] To: Brian E Carpenter Cc: Robert Raszuk , "Leddy, John" , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" , Stewart Bryant Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 01:33:30 -0000 On 18 March 2017 at 12:10, Brian E Carpenter wrote: >> I can use >> today SRv6 features in my data centers where I consistently know that all >> interfaces are set for jumbo frames and where hopefully I do not need to >> worry about MTU since hosts have much lower max MTU configured. > > Exactly. That's not the Internet. Internet Standards are for the Internet, > hence I believe that the AD's decision is the correct one. > > (How would you feel about an extension header that MAY be deleted > by an intermediate node, and MUST be deleted if the next hop's link > MTU is too small? That's the sort of complexity that allowing header > insertion would require in order to be acceptable across the Internet > with broken PMTUD that we have. Also PTB semantics would have to change > from "PMTU is N bytes" to "Packet exceeded link MTU by X bytes", since > the source has no idea how much has been added by intermediate systems. > Or perhaps the intermediate systems would have to send back a new > ICMPv6 message saying "I extended your packet by Y bytes." This is > not straightforward.) And that may not work anyway, because some security people believe all ICMP is evil. The Linux kernel has had an implementation of PLPMTUD since 2006, so it is now literally in billions of devices, however it is switched off by default. I've commonly switched it on over the years* and never encountered a noticeable issue when I have (i.e., I've never had an issue that has made me suspect a PMTUD problem and caused me to investigate, and I've always been on a dumbell MTU PPPoE setup since getting broadband 15 years ago.) Would a BCP saying to implement it or enable it if already be implemented in hosts be a better approach to encourage its adoption, rather than just continuing to accept the status quo of hosts that can't perform PMTUD successfully because of broken networks? Regards, Mark. * # net.ipv4.tcp_mtu_probing sysctl #tcp_mtu_probing - INTEGER # Controls TCP Packetization-Layer Path MTU Discovery. Takes three # values: # 0 - Disabled # 1 - Disabled by default, enabled when an ICMP black hole detected # 2 - Always enabled, use initial MSS of tcp_base_mss. From nobody Sat Mar 18 02:15:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EF5124BFA; Sat, 18 Mar 2017 02:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Yw2S1CMyqQtj; Sat, 18 Mar 2017 02:15:56 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ADC1243FE; Sat, 18 Mar 2017 02:15:55 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m27so45452664iti.0; Sat, 18 Mar 2017 02:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=n1AaHx6sk3A6B/NvNTJIFI7OWP2IO3naczX1bMgWI6s=; b=NK2WLKDVwqnAN1z/2r067ikTKgQKaX60j3B4IEux+MNEv1hNEO9MV9hbJZ9nKXUpck IzFkHKKmci9mQS97YS8w+bqoe0XVJBk8aA/9aVcVXHqfwTenaFL3Z+5adLROgHbfPPjT QG+8Lc2frs1jFOR+67/LJEmDW4d+1bQVuOdaH/179u/YFGLfrDQjnUXFIiU9fPthZQsf trk1PP7To6zWqVnBZeWwyyr+WJkoLSZevgy4wSX511nXPWPp9jnfaJmGjp2j+V3wev/4 x7C5V6FohAOqDhw7drhOGmpYYr/zenV4f7JDrZjguXxUrecGocScFK7BHSjG9kthwFG1 ZVXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=n1AaHx6sk3A6B/NvNTJIFI7OWP2IO3naczX1bMgWI6s=; b=iGKTVrzy4MbVl8nCn+3YqHnf9I1vr9g+TxqUNEwoTApmTTafBBt6N9mrF3M9N7iOV9 PI/YgSJBuDWWa7IRemO6OM88eNwcPAGMiIKoz8eJw8z62kxd+Yu5dEYa8E8RLGefGn4R 7tDeencmYFbW/eBSPWBbnIM00vkDHE4kcP9rLwHAGPMUqvgnh0DX/y8vUB1UzYN4EKvK EAgq/LSF32cV0MhkY/G+t0kiXurD8iovHgp1G+H12Vpvk2pKzG/bTVVPToKz9oymqkNA PU/NDD0/BFC3raXPxE8k8id0oz3awpDwEibOGybCUOfJJEbFKuWw5cK/4Bo/UNQvasFs xLVw== X-Gm-Message-State: AFeK/H3Pqam3Iay1L1T4+ga3cXq06S42+A9P9v22KEw5ocGf35SkMu9pWQE2trNuVni13lHhpuE/Hp2fgj2Mzg== X-Received: by 10.107.7.29 with SMTP id 29mr19118277ioh.57.1489828555308; Sat, 18 Mar 2017 02:15:55 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.35.207 with HTTP; Sat, 18 Mar 2017 02:15:54 -0700 (PDT) In-Reply-To: <618152cf-b097-6d39-e3eb-84b676fb56b7@gmail.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <618152cf-b097-6d39-e3eb-84b676fb56b7@gmail.com> From: Robert Raszuk Date: Sat, 18 Mar 2017 10:15:54 +0100 X-Google-Sender-Auth: Q2oqUGQEA1mQkm8lgfpYRfkjdmE Message-ID: Subject: Re: Manual PMTUD [was ...rfc2460bis-08] To: Brian E Carpenter Cc: "Leddy, John" , Stewart Bryant , Tim Chown , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG Content-Type: multipart/alternative; boundary=001a113ea6f0d0ed54054afdbd03 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 09:15:58 -0000 --001a113ea6f0d0ed54054afdbd03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, On Sat, Mar 18, 2017 at 2:10 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > I can use > > today SRv6 features in my data centers where I consistently know that a= ll > > interfaces are set for jumbo frames and where hopefully I do not need t= o > > worry about MTU since hosts have much lower max MTU configured. > > Exactly. That's not the Internet. Internet Standards are for the Internet= , > hence I believe that the AD's decision is the correct one. > =E2=80=8BWell I don't know .. Protocols are used both in the open Internet = and in the contained =E2=80=8Benvironments. Hence IANA allocations and draft progr= ess should be encouraged regardless if something is to be deployed in the Internet or not. Now as customer I do encourage multi-vendor networks even for closed RFC1918 private WAN, MAN or DCs. If we just drop and position IETF to work on "Internet" only use cases where would interoperability of routing protocols and beyond fall under ? Which SDO ? (How would you feel about an extension header that MAY be deleted > by an intermediate node, and MUST be deleted if the next hop's link > MTU is too small? =E2=80=8BWell SRH can be applied both as a mission critical or optimization= . If it is an optimisation =E2=80=8Bindicated in the packet by a flag I would be fi= ne to remove it if it does not fit to the MTU of the link. If it is however "MUST HAVE" for a given flow I would rather see a packet drop then to continue forwarding without it. Both such events should indeed be signaled to the "owner" of the SRH or any other extension header either inbound via for example ICMPv6 or maybe by some other targeted message or indicated out of band (via logging to syslog) - applicable to single administration domain. =E2=80=8BKind regards, Robert.=E2=80=8B --001a113ea6f0d0ed54054afdbd03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Brian,

    On Sat, Mar 18, 2017 at 2:10 AM, Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:
    =
    > I can use
    > today SRv6 features in my data centers where I consistently know that = all
    > interfaces are set for jumbo frames and where hopefully I do not need = to
    > worry about MTU since hosts have much lower max MTU configured.

    Exactly. That's not the Internet. Internet Standards are for the= Internet,
    hence I believe that the AD's decision is the correct one.


    =E2= =80=8BWell I don't know .. Protocols are used both in the open Internet= and in the contained =E2=80=8Benvironments. Hence IANA allocations and dra= ft progress should be encouraged regardless if something is to be deployed = in the Internet or not.=C2=A0

    Now as customer I do encourage multi-vendor networks even for clos= ed RFC1918 private WAN, MAN or DCs.

    If we just drop and position IETF to work on "Internet&q= uot; only use cases where would interoperability of routing protocols and b= eyond fall under ? Which SDO ?=C2=A0


    (How would you feel about an extension header that M= AY be deleted
    by an intermediate node, and MUST be deleted if the next hop's link
    MTU is too small?


    =E2=80=8BWell SRH can be applied both as a mission critical or op= timization. If it is an optimisation =E2=80=8Bindicated in the packet by a = flag I would be fine to remove it if it does not fit to the MTU of the link= .=C2=A0

    If it is howev= er "MUST HAVE" for a given flow I would rather see a packet drop = then to continue forwarding without it.=C2=A0

    <= /div>
    Both such events should indeed be signaled to the &= quot;owner" of the SRH or any other extension header either inbound vi= a for example ICMPv6 or maybe by some other targeted message or indicated o= ut of band (via logging to syslog) - applicable to single administration do= main.=C2=A0

    =E2=80=8BKind regards,
    Robert.=E2=80=8B

    --001a113ea6f0d0ed54054afdbd03-- From nobody Sat Mar 18 02:41:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5EB126B71 for ; Sat, 18 Mar 2017 02:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 AZX6PwhcwK9V for ; Sat, 18 Mar 2017 02:41:39 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A83129542 for ; Sat, 18 Mar 2017 02:40:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2I9e0na034027; Sat, 18 Mar 2017 10:40:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9BF8F2012E7; Sat, 18 Mar 2017 10:40:00 +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 84B83200FA3; Sat, 18 Mar 2017 10:40:00 +0100 (CET) Received: from [132.166.84.69] ([132.166.84.69]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2I9e07k027299; Sat, 18 Mar 2017 10:40:00 +0100 Subject: Re: a draft about on-link and subnet prefixes - the 4291bis impact To: otroan@employees.org References: <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> <80954d75-d07a-efe5-5906-dba8976dc563@gmail.com> <1ab36b80-ac73-abf2-0b6e-9f7e047d4963@gmail.com> Cc: 6man WG From: Alexandre Petrescu Message-ID: <42a578fe-8992-2326-8245-660a00ad018f@gmail.com> Date: Sat, 18 Mar 2017 10:39:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 09:41:40 -0000 Supposedly, as we speak, there is some decision pondered over, about recommending (or not) 64bit IIDlens in 4291bis. In making that decision, the onlink|SLAAC distinction should have no role. It is not an indicator striking a balance either way. Alex Le 17/03/2017 à 23:20, otroan@employees.org a écrit : > Alexandre, > > it is a little hard to understand what you want to achieve with your messages. > if you want something explained, perhaps we should sit down in Chicago. > if you want to have something changed, please write a draft and explain your proposal and your ideas. > > Best regards, > Ole > From nobody Sat Mar 18 05:57:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ECA1270A3; Sat, 18 Mar 2017 05:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eud7enfHum2l; Sat, 18 Mar 2017 05:57:27 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC0F12708C; Sat, 18 Mar 2017 05:57:26 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id g138so54301446itb.0; Sat, 18 Mar 2017 05:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tkWc0b2ZChJRX8iiPTbYTmVafGyhpWKTMVl7y6FOvts=; b=eUlhcupRKHx4dLPeCJW6oyjZYs9OoYygSFpHV0lJCQ+XTrdcXAGXKNNNUp9qabO/Ds Dw/n3vGqDFR7FWURxkasQ9tcx8OaGMLyc7O5N1BRWC5XERLI0mGBknbMEyeSniARcFom 5Zau37K+NhtkE0f7rB/0cM7xkgJdSe75glVcIOG5yvN7oVtFJRtSealL7TWzofbHWqVZ 7rH7kNP4+eOGimOnI1zcBMuBHnOvJT+DEGkUYBltjpY4I554AIvh+ivO1iW4azsryPNm jLwZCa5VsuawMFcOfXNdeJ3KYIzcbkk8kXou99qXEwdonKEJOmzV3ADMTLHUTPt+6Ag4 qQRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=tkWc0b2ZChJRX8iiPTbYTmVafGyhpWKTMVl7y6FOvts=; b=YuZOWhtlBMmgIL8suNZOdztFkyMbw/gyc094MeLS5pRyJHK67nUywAi1EOnJOUglsM M+jN/IG1WSQKMrjOii9PK5DZ/ScPEXf4wb46IQYESCDgWP6itjXondHhOZBsztXw+GQO nUv30PHacLYMmCXq0jbaL4LahciXjFDQ03dUTEygOH9NR8J9IEtuss37uElRr6wnoLsS 8udzDZpcWfXmtTVQtcvucbK5D5y+JUWJg7EsFtfLhE5eJWIrsvhGkPXvXF0SyiuDcXpG VNgSYX1BZarKI2Xm7deEA7ymEXjoUpOq3OGA5sEEu9l2VIRRVc6B300l8pi7Z1X3ws5e wShQ== X-Gm-Message-State: AFeK/H1BwCL/NCxUQxk2J+YHMu46qerxvg/Es70VZ8FpWimYe0dCBnXEP1L7yApoDMFPhA== X-Received: by 10.107.25.208 with SMTP id 199mr18353464ioz.62.1489841846249; Sat, 18 Mar 2017 05:57:26 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id l19sm5778504ioe.51.2017.03.18.05.57.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Mar 2017 05:57:25 -0700 (PDT) Subject: Re: Manual PMTUD [was ...rfc2460bis-08] To: Robert Raszuk References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <618152cf-b097-6d39-e3eb-84b676fb56b7@gmail.com> Cc: "Leddy, John" , Stewart Bryant , Tim Chown , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 19 Mar 2017 01:57:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 12:57:29 -0000 On 18/03/2017 22:15, Robert Raszuk wrote: > Hi Brian, >=20 > On Sat, Mar 18, 2017 at 2:10 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >>> I can use >>> today SRv6 features in my data centers where I consistently know that= all >>> interfaces are set for jumbo frames and where hopefully I do not need= to >>> worry about MTU since hosts have much lower max MTU configured. >> >> Exactly. That's not the Internet. Internet Standards are for the Inter= net, >> hence I believe that the AD's decision is the correct one. >> >=20 >=20 > =E2=80=8BWell I don't know .. Protocols are used both in the open Inter= net and in > the contained =E2=80=8Benvironments. Hence IANA allocations and draft p= rogress > should be encouraged regardless if something is to be deployed in the > Internet or not. That's true, and that's why I'm very open to the idea of local-use allocations in general. But for the IP protocol above all, we need Internet-wide interoperability in the Internet Standard. Brian >=20 > Now as customer I do encourage multi-vendor networks even for closed > RFC1918 private WAN, MAN or DCs. >=20 > If we just drop and position IETF to work on "Internet" only use cases > where would interoperability of routing protocols and beyond fall under= ? > Which SDO ? >=20 >=20 > (How would you feel about an extension header that MAY be deleted >> by an intermediate node, and MUST be deleted if the next hop's link >> MTU is too small? >=20 >=20 >=20 > =E2=80=8BWell SRH can be applied both as a mission critical or optimiza= tion. If it > is an optimisation =E2=80=8Bindicated in the packet by a flag I would b= e fine to > remove it if it does not fit to the MTU of the link. >=20 > If it is however "MUST HAVE" for a given flow I would rather see a pack= et > drop then to continue forwarding without it. >=20 > Both such events should indeed be signaled to the "owner" of the SRH or= any > other extension header either inbound via for example ICMPv6 or maybe b= y > some other targeted message or indicated out of band (via logging to > syslog) - applicable to single administration domain. >=20 > =E2=80=8BKind regards, > Robert.=E2=80=8B >=20 From nobody Sat Mar 18 07:00:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030651279E5 for ; Sat, 18 Mar 2017 07:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu 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 Xf7Fo6hFrXKd for ; Sat, 18 Mar 2017 07:00:40 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250D5127775 for ; Sat, 18 Mar 2017 07:00:37 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id y76so83506662qkb.0 for ; Sat, 18 Mar 2017 07:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rLlwC9Ru2f0lIQnCjghW/3PXnSHfayyb62s2qnjEbYI=; b=Yz8NSxVxSvtlBJdSvvKDTsj0lRdkcq7VhzJWbQaeKhgQdKN8U3DqD2uASO6Wu/UPIU UOTVz6o66tdUE7kBhHDl+N70SGERIyG/gS+bTx8Z2OPIE0JWBdld9Ic0pLXKG3Gf4URz duLF/Sq4PQHKGXwcNyZpvBRdNkJ5xd5y7U4Mo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rLlwC9Ru2f0lIQnCjghW/3PXnSHfayyb62s2qnjEbYI=; b=A5UylMPSImWYYMOEHPXuaWi3q8HQ6nYv0QOwfodG4uCNTJoS9g6GiClLj2E90zDw3B 47BzLDSaNNIrdUEVbt3y63nPHy3Lm+G1uezYVe/p6cxg/gYDqhDNk3HSIPKHdSH4ox9X IPCYeSRt5tAL0j7meG9VOR69ESKhPRYERD8beeD+kMlj3xlHy81xoYwWJQaKof7KZaaw 16GOQ46nAykSW1J1v9XSLDb5BzEZSWZybODg7JpYO7zJFK639wzRJgXQeGt4CUstapnU zHGiwA8+v9OXe6PMYHyz4GBj40EZPaVYJvnMFlmFbssEK5eDx2rmQ33fa3PLl28+FCB0 woug== X-Gm-Message-State: AFeK/H3vf8X1qcx6Y36IHebXE6R9fDQ9q/HL9Ch7fIqhqLOCqRcXFxvgEA1Nt3/SzBZXtVn+9kYAkMS79Bw0BuHl X-Received: by 10.55.99.69 with SMTP id x66mr17224385qkb.317.1489845636243; Sat, 18 Mar 2017 07:00:36 -0700 (PDT) MIME-Version: 1.0 References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <618152cf-b097-6d39-e3eb-84b676fb56b7@gmail.com> In-Reply-To: From: Timothy Winters Date: Sat, 18 Mar 2017 14:00:25 +0000 Message-ID: Subject: Re: Manual PMTUD [was ...rfc2460bis-08] To: Brian E Carpenter , Mark Smith Cc: 6man WG , "Leddy, John" , Robert Raszuk , Stewart Bryant , "draft-ietf-6man-rfc2460bis.all@ietf.org" Content-Type: multipart/alternative; boundary=001a114814a0eb436c054b01b75b Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 14:00:51 -0000 --001a114814a0eb436c054b01b75b Content-Type: text/plain; charset=UTF-8 Hi Mark, We are working on an updated IPv6 node requirements, that might be a good place to put this type of suggestion. The current text says " One operational issue with Path MTU Discovery occurs when firewalls block ICMP Packet Too Big messages. Path MTU Discovery relies on such messages to determine what size messages can be successfully sent. "Packetization Layer Path MTU Discovery" [RFC4821] avoids having a dependency on Packet Too Big messages I'm guessing we might want to put something more the this? Tim On Fri, Mar 17, 2017 at 9:33 PM Mark Smith wrote: > On 18 March 2017 at 12:10, Brian E Carpenter > wrote: > >> I can use > >> today SRv6 features in my data centers where I consistently know that > all > >> interfaces are set for jumbo frames and where hopefully I do not need to > >> worry about MTU since hosts have much lower max MTU configured. > > > > Exactly. That's not the Internet. Internet Standards are for the > Internet, > > hence I believe that the AD's decision is the correct one. > > > > (How would you feel about an extension header that MAY be deleted > > by an intermediate node, and MUST be deleted if the next hop's link > > MTU is too small? That's the sort of complexity that allowing header > > insertion would require in order to be acceptable across the Internet > > with broken PMTUD that we have. Also PTB semantics would have to change > > from "PMTU is N bytes" to "Packet exceeded link MTU by X bytes", since > > the source has no idea how much has been added by intermediate systems. > > Or perhaps the intermediate systems would have to send back a new > > ICMPv6 message saying "I extended your packet by Y bytes." This is > > not straightforward.) > > > And that may not work anyway, because some security people believe all > ICMP is evil. > > The Linux kernel has had an implementation of PLPMTUD since 2006, so > it is now literally in billions of devices, however it is switched off > by default. I've commonly switched it on over the years* and never > encountered a noticeable issue when I have (i.e., I've never had an > issue that has made me suspect a PMTUD problem and caused me to > investigate, and I've always been on a dumbell MTU PPPoE setup since > getting broadband 15 years ago.) > > Would a BCP saying to implement it or enable it if already be > implemented in hosts be a better approach to encourage its adoption, > rather than just continuing to accept the status quo of hosts that > can't perform PMTUD successfully because of broken networks? > > Regards, > Mark. > > > * > # net.ipv4.tcp_mtu_probing sysctl > #tcp_mtu_probing - INTEGER > # Controls TCP Packetization-Layer Path MTU Discovery. Takes three > # values: > # 0 - Disabled > # 1 - Disabled by default, enabled when an ICMP black hole detected > # 2 - Always enabled, use initial MSS of tcp_base_mss. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a114814a0eb436c054b01b75b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Mark,

    We are working on an updated IPv6 no= de requirements, that might be a good place to put this type of suggestion.=

    The current text says=C2=A0
    " One operational issue with Path MTU Discov= ery occurs when firewalls
       blo=
ck ICMP Packet Too Big messages.  Path MTU Discovery relies on
   such messages to determine what size messages can be successfully
   sent.  "Packetization Layer Path MTU Discovery" [RFC4821] avoi=
ds
   having a dependency on Packet Too Big messages

    = I'm guessing we might want to put something more the this?
    Tim
    On Fri, Mar 17, 2017 at= 9:33 PM Mark Smith <markzzzsm= ith@gmail.com> wrote:
    On 18 = March 2017 at 12:10, Brian E Carpenter
    <brian.e.carpenter@gmail.com> wrote:
    >> I can use
    >> today SRv6 features in my data centers where I consistently know t= hat all
    >> interfaces are set for jumbo frames and where hopefully I do not n= eed to
    >> worry about MTU since hosts have much lower max MTU configured. >
    > Exactly. That's not the Internet. Internet Standards are for the I= nternet,
    > hence I believe that the AD's decision is the correct one.
    >
    > (How would you feel about an extension header that MAY be deleted
    > by an intermediate node, and MUST be deleted if the next hop's lin= k
    > MTU is too small? That's the sort of complexity that allowing head= er
    > insertion would require in order to be acceptable across the Internet<= br class=3D"gmail_msg"> > with broken PMTUD that we have. Also PTB semantics would have to chang= e
    > from "PMTU is N bytes" to "Packet exceeded link MTU by = X bytes", since
    > the source has no idea how much has been added by intermediate systems= .
    > Or perhaps the intermediate systems would have to send back a new
    > ICMPv6 message saying "I extended your packet by Y bytes." T= his is
    > not straightforward.)


    And that may not work anyway, because some security people believe all
    ICMP is evil.

    The Linux kernel has had an implementation of PLPMTUD since 2006, so
    it is now literally in billions of devices, however it is switched off
    by default. I've commonly switched it on over the years* and never
    encountered a noticeable issue when I have (i.e., I've never had an
    issue that has made me suspect a PMTUD problem and caused me to
    investigate, and I've always been on a dumbell MTU PPPoE setup since getting broadband 15 years ago.)

    Would a BCP saying to implement it or enable it if already be
    implemented in hosts be a better approach to encourage its adoption,
    rather than just continuing to accept the status quo of hosts that
    can't perform PMTUD successfully because of broken networks?

    Regards,
    Mark.


    *
    # net.ipv4.tcp_mtu_probing sysctl
    #tcp_mtu_probing - INTEGER
    # Controls TCP Packetization-Layer Path MTU Discovery.=C2=A0 Takes three # values:
    #=C2=A0 0 - Disabled
    #=C2=A0 1 - Disabled by default, enabled when an ICMP black hole detected #=C2=A0 2 - Always enabled, use initial MSS of tcp_base_mss.

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6= @ietf.org
    Administrative Requests: https://www.i= etf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --

    Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

    --001a114814a0eb436c054b01b75b-- From nobody Sat Mar 18 09:03:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079D31288B8; Sat, 18 Mar 2017 09:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HhLKRg6aFsOY; Sat, 18 Mar 2017 09:03:18 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66529127201; Sat, 18 Mar 2017 09:03:18 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id o4so69445853ywd.3; Sat, 18 Mar 2017 09:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CYd41GsBRU9bg4nbp8k6MK5Nn2nw0NHjuswljVs6zeA=; b=Tz/btiUWz1EgG1o9Mx1uIBEY6Rzrt3cxLJL8Fm1jW1kCs2uY4vQQuPUrN0ZBxWwVMo s09vALZmrnHi5k4fz8OOdMS7o2GpN9R2o8u/3OFjoe763vkh/zVkBVzGlRo/lK7fd2AF v/SDIqV28EqXdG9jGrKwnhil8wUXEeLyC2UaMEiVLDBlLFm9e+0iNPqITHAKFPj7Fs71 QnXoP50GlnS7E8ryoXA+hbki/PCIGzPqmsEouJW0DWNPqaZ0drtA1aNjX52W4Fc7PXO/ CqmFyXpbbkimBPlugWWK9sJb2nrGQEES7hq9ETfN7PKzF9qAUEeKoyA3VEHZ8qZwdWRt nVXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CYd41GsBRU9bg4nbp8k6MK5Nn2nw0NHjuswljVs6zeA=; b=TNDzWG6YFsGVLVlRKhYo2RHlF0Z8nxGG8Gt2C5fjvuu6kprY794eIOPjkySm6jM8oD NI8UXN+7VtPUxbCJtaalAwJuAPNa5rStWQIJw/4P1/UBjkQZFsk8xUfw0x8qRkoekFsV OKE0f+iHBF9HHVa6LT91id/6HUtP0i8559ulQisAXxEndTxrNgEFmJUVPpuG1MKmWQDb cDIiiHcQ/aSOU91z4s5jNeRU+jLuoRWWI91at8u9kO+CfaGiCWDBpwlXjjIao39Xs0jb yFzGyGzut/KSWST4F0/u8X+/6httRk7fuRAA3W1EpkfRpQwFVmw1/5baFRxvQ73Z3pb4 c68Q== X-Gm-Message-State: AFeK/H0+bOucIxMfI2TBFkXROxsLErNiLEF1+Rk3rgRqQCzOBh62BYD+9ApHxYLzvu94/SPwWbq6v2lghSfS7A== X-Received: by 10.37.125.196 with SMTP id y187mr8460939ybc.22.1489852997496; Sat, 18 Mar 2017 09:03:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.77.197 with HTTP; Sat, 18 Mar 2017 09:03:17 -0700 (PDT) Received: by 10.37.77.197 with HTTP; Sat, 18 Mar 2017 09:03:17 -0700 (PDT) In-Reply-To: References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> <41A44496-F222-40D5-95FE-5CE142C3827F@gmail.com> <46d7ae23-cf3d-570d-3d79-9d915663cf16@isi.edu> <8D6CA1F7-CB01-4FCD-B81C-ECBEFC088EAE@gmail.com> From: Spencer Dawkins at IETF Date: Sat, 18 Mar 2017 11:03:17 -0500 Message-ID: Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 To: Joe Touch Cc: ipv6@ietf.org, Bob Hinden , IESG , "tsv-art@ietf.org" Content-Type: multipart/alternative; boundary=001a114dd3c6aefbf8054b036e4c Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 16:03:21 -0000 --001a114dd3c6aefbf8054b036e4c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I may not be answering the question Joe asked, but ... On Mar 17, 2017 19:36, "Joe Touch" wrote: On 3/17/2017 4:31 PM, Bob Hinden wrote: > Joe, > > I think this will be up to the AD and IESG. OK - I'll wait for them to respond. > If you (and others) want to work on a major update, I am happy to share the XML. I hope we don=E2=80=99t end up with can=E2=80=99t move the curren= t document forward, and no one wants to do a major update. I'd certainly prefer to have this doc address these issues. One question - if a major update occurred, would that be at the same standard level? If so, and if these issues are of concern, I'd be glad to take that on. If a major rev is a standards-level setback, that would be less useful. I'd like to hear their views... So, RFC 1981 is a Draft Standard, which is theoretically a bigger deal than a Proposed Standard. If a replacement to RFC 1981 doesn't work the same way that RFC 1981 works, I don't see how it would also be a Draft Standard, based on the standards level of the RFC it would be replacing. Do others see something I'm missing? However. Assuming that a replacement for RFC 1981 Path MTU Discovery doesn't have the issues we've been talking about in these threads, I would hope that we could publish that replacement at Proposed Standard (not at Experimental). Given that we don't use the Draft Standard level for advancing standards track RFCs any more (post https://datatracker.ietf.org/doc/rfc6410/), would publishing a replacement that works better than RFC 1981 at Proposed Standard be a bad thing? Curiously yours, Spencer Joe _______________________________________________ Tsv-art mailing list Tsv-art@ietf.org https://www.ietf.org/mailman/listinfo/tsv-art --001a114dd3c6aefbf8054b036e4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I may not be answering the question Joe asked, but .= ..

    On Mar 17, = 2017 19:36, "Joe Touch" <touc= h@isi.edu> wrote:
    <= div class=3D"quoted-text">

    On 3/17/2017 4:31 PM, Bob Hinden wrote:
    > Joe,
    >
    > I think this will be up to the AD and= IESG.
    OK - I'll wait for them to respond.
    > If you (and others) want to work on a major= update, I am happy to share the XML.=C2=A0 I hope we don=E2=80=99t end up = with can=E2=80=99t move the current document forward, and no one wants to d= o a major update.
    I'd certainly prefer to have this doc address these issues.

    One question - if a major update occurred, would that be at the same
    standard level? If so, and if these issues are of concern, I'd be glad<= br> to take that on.

    If a major rev is a standards-level setback, that would be less useful.

    I'd like to hear their views...

    So, RFC 1981 is a Draft Standard, = which is theoretically a bigger deal than a Proposed Standard. If a replace= ment to RFC 1981 doesn't work the same way that RFC 1981 works, I don&#= 39;t see how it would also be a Draft Standard, based on the standards leve= l of the RFC it would be replacing. Do others see something I'm missing= ?

    However.

    Assuming that a replacement for RFC 1= 981 Path MTU Discovery doesn't have the issues we've been talking a= bout in these threads, I would hope that we could publish that replacement = at Proposed Standard (not at Experimental).

    Given that we don't use the Draft Standard level fo= r advancing standards track RFCs any more (post https://datatracker.ietf.org/doc/rfc6410/), = would publishing a replacement that works better than RFC 1981 at Proposed = Standard be a bad thing?

    Curiously yours,

    Spence= r


    Joe

    _______________________________________________
    Tsv-art mailing list
    Tsv-art@ietf.org
    https://www.ietf.org/mailman/listinfo/tsv-art<= br>

    --001a114dd3c6aefbf8054b036e4c-- From nobody Sat Mar 18 09:27:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05ABA1288B8; Sat, 18 Mar 2017 09:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 mPzjNrrtT4KO; Sat, 18 Mar 2017 09:27:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D2F1277BB; Sat, 18 Mar 2017 09:27:36 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2IGQgkX011175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 18 Mar 2017 09:26:44 -0700 (PDT) Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 To: Spencer Dawkins at IETF References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> <41A44496-F222-40D5-95FE-5CE142C3827F@gmail.com> <46d7ae23-cf3d-570d-3d79-9d915663cf16@isi.edu> <8D6CA1F7-CB01-4FCD-B81C-ECBEFC088EAE@gmail.com> Cc: ipv6@ietf.org, Bob Hinden , IESG , "tsv-art@ietf.org" From: Joe Touch Message-ID: <01fc4067-6825-9343-7735-86f9bf77bebe@isi.edu> Date: Sat, 18 Mar 2017 09:26:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6F495733573D7217B70CDADB" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 16:27:39 -0000 This is a multi-part message in MIME format. --------------6F495733573D7217B70CDADB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit FWIW, I was thinking of an update that focused on the description issue below. Nothing functionally would change. Joe On 3/18/2017 9:03 AM, Spencer Dawkins at IETF wrote: > I may not be answering the question Joe asked, but ... > > On Mar 17, 2017 19:36, "Joe Touch" > wrote: > > > > On 3/17/2017 4:31 PM, Bob Hinden wrote: > > Joe, > > > > I think this will be up to the AD and IESG. > OK - I'll wait for them to respond. > > If you (and others) want to work on a major update, I am happy > to share the XML. I hope we don’t end up with can’t move the > current document forward, and no one wants to do a major update. > I'd certainly prefer to have this doc address these issues. > > One question - if a major update occurred, would that be at the same > standard level? If so, and if these issues are of concern, I'd be glad > to take that on. > > If a major rev is a standards-level setback, that would be less > useful. > > I'd like to hear their views... > > > So, RFC 1981 is a Draft Standard, which is theoretically a bigger deal > than a Proposed Standard. If a replacement to RFC 1981 doesn't work > the same way that RFC 1981 works, I don't see how it would also be a > Draft Standard, based on the standards level of the RFC it would be > replacing. Do others see something I'm missing? > > However. > > Assuming that a replacement for RFC 1981 Path MTU Discovery doesn't > have the issues we've been talking about in these threads, I would > hope that we could publish that replacement at Proposed Standard (not > at Experimental). > > Given that we don't use the Draft Standard level for advancing > standards track RFCs any more (post > https://datatracker.ietf.org/doc/rfc6410/), would publishing a > replacement that works better than RFC 1981 at Proposed Standard be a > bad thing? > > Curiously yours, > > Spencer > > > Joe > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > > > --------------6F495733573D7217B70CDADB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    FWIW, I was thinking of an update that focused on the description issue below.

    Nothing functionally would change.

    Joe


    On 3/18/2017 9:03 AM, Spencer Dawkins at IETF wrote:
    I may not be answering the question Joe asked, but ...

    On Mar 17, 2017 19:36, "Joe Touch" <touch@isi.edu> wrote:


    On 3/17/2017 4:31 PM, Bob Hinden wrote:
    > Joe,
    >
    > I think this will be up to the AD and IESG.
    OK - I'll wait for them to respond.
    > If you (and others) want to work on a major update, I am happy to share the XML.  I hope we don’t end up with can’t move the current document forward, and no one wants to do a major update.
    I'd certainly prefer to have this doc address these issues.

    One question - if a major update occurred, would that be at the same
    standard level? If so, and if these issues are of concern, I'd be glad
    to take that on.

    If a major rev is a standards-level setback, that would be less useful.

    I'd like to hear their views...

    So, RFC 1981 is a Draft Standard, which is theoretically a bigger deal than a Proposed Standard. If a replacement to RFC 1981 doesn't work the same way that RFC 1981 works, I don't see how it would also be a Draft Standard, based on the standards level of the RFC it would be replacing. Do others see something I'm missing?

    However.

    Assuming that a replacement for RFC 1981 Path MTU Discovery doesn't have the issues we've been talking about in these threads, I would hope that we could publish that replacement at Proposed Standard (not at Experimental).

    Given that we don't use the Draft Standard level for advancing standards track RFCs any more (post https://datatracker.ietf.org/doc/rfc6410/), would publishing a replacement that works better than RFC 1981 at Proposed Standard be a bad thing?

    Curiously yours,

    Spencer


    Joe

    _______________________________________________
    Tsv-art mailing list
    Tsv-art@ietf.org
    https://www.ietf.org/mailman/listinfo/tsv-art


    --------------6F495733573D7217B70CDADB-- From nobody Sat Mar 18 09:29:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D216F128990; Sat, 18 Mar 2017 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BGtviaYnT_Lm; Sat, 18 Mar 2017 09:29:34 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7B8126C23; Sat, 18 Mar 2017 09:29:34 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id p77so69459934ywg.1; Sat, 18 Mar 2017 09:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QP7Ad3xw5AaIL8XecERqqwciyXhHBh/db/9NXreMeP8=; b=J44VsjLHUxEibJ+kwDAWenhRXZXFp/JlTHhtcpdNCKL27I+GoUr6u8/DyOHxlJ4q+G 42E1scEhPAflsiyn/fiHunMTVyIfaa/badVu2cDNgsJRaDxXSacKD2fEYSC27yj4obcL 7vY106qLmxsSwXr1U2Bk+fahSVKeqyT19oRlFP6UDpI5l1MxCnTGY4bTJQKni1aeOyiT uTHCxWXpDcYB6J75dQKpOV2b6JFcdJ8zUaI1uOp0jybj+zS1aRqhUDAHniGN0eGlERHS yEbCWzx8BngOvAsEmlZZ3Pr9o1mSnk33osYhM5FF25R2OsTXjxaJtn2D8xU8IqkTNQ+S fZeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QP7Ad3xw5AaIL8XecERqqwciyXhHBh/db/9NXreMeP8=; b=nFwQ6Es9PLj2S/wY4sorJSHKfmueavSVFL7eowt+i/eYldPyeN+S3TrKsQRImjSt3C C37BvJBEihLMy7/sq4fl35YmpTOqJnYR6VRSZoSg9RhFxMGtvqcCgf2OnBwnn+lM7Bu1 eODIIgDkjDaNuyqAXOdwy0e9biz/mu/SFXOziHnBUHTKYAa14PLgeQwfc5Ob44L0p2Mt ouWZZzSad/TPywqLrg5MXUXg4LfCVPr3iil+BPcp2gzrK9Ouvs8ESmYSsMSW6AYsbO13 d6v8VD2Yjpz6rrg+0IL3uDghFS9PRQi/0nk1fLcQC6ApDXNJFXNLZTZ/G7T5u+3MAfAh NK/g== X-Gm-Message-State: AFeK/H0RJYPKVJsOE/GPQ4czLYRXFYPXJy89io8OcjlLHpaS6i1iyE9NMODdctR46RX9AagPhYWDULpmXZUSWQ== X-Received: by 10.13.243.197 with SMTP id c188mr7737842ywf.248.1489854573543; Sat, 18 Mar 2017 09:29:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.77.197 with HTTP; Sat, 18 Mar 2017 09:29:32 -0700 (PDT) Received: by 10.37.77.197 with HTTP; Sat, 18 Mar 2017 09:29:32 -0700 (PDT) In-Reply-To: <01fc4067-6825-9343-7735-86f9bf77bebe@isi.edu> References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> <41A44496-F222-40D5-95FE-5CE142C3827F@gmail.com> <46d7ae23-cf3d-570d-3d79-9d915663cf16@isi.edu> <8D6CA1F7-CB01-4FCD-B81C-ECBEFC088EAE@gmail.com> <01fc4067-6825-9343-7735-86f9bf77bebe@isi.edu> From: Spencer Dawkins at IETF Date: Sat, 18 Mar 2017 11:29:32 -0500 Message-ID: Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 To: Joe Touch Cc: tsv-art@ietf.org, iesg@ietf.org, Bob Hinden , ipv6@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0356909f8a4b054b03ccd5 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 16:29:37 -0000 --94eb2c0356909f8a4b054b03ccd5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Joe, On Mar 18, 2017 11:27, "Joe Touch" wrote: FWIW, I was thinking of an update that focused on the description issue below. Nothing functionally would change. Ah - I'm glad I asked! Thanks, Spencer Joe On 3/18/2017 9:03 AM, Spencer Dawkins at IETF wrote: I may not be answering the question Joe asked, but ... On Mar 17, 2017 19:36, "Joe Touch" wrote: On 3/17/2017 4:31 PM, Bob Hinden wrote: > Joe, > > I think this will be up to the AD and IESG. OK - I'll wait for them to respond. > If you (and others) want to work on a major update, I am happy to share the XML. I hope we don=E2=80=99t end up with can=E2=80=99t move the curren= t document forward, and no one wants to do a major update. I'd certainly prefer to have this doc address these issues. One question - if a major update occurred, would that be at the same standard level? If so, and if these issues are of concern, I'd be glad to take that on. If a major rev is a standards-level setback, that would be less useful. I'd like to hear their views... So, RFC 1981 is a Draft Standard, which is theoretically a bigger deal than a Proposed Standard. If a replacement to RFC 1981 doesn't work the same way that RFC 1981 works, I don't see how it would also be a Draft Standard, based on the standards level of the RFC it would be replacing. Do others see something I'm missing? However. Assuming that a replacement for RFC 1981 Path MTU Discovery doesn't have the issues we've been talking about in these threads, I would hope that we could publish that replacement at Proposed Standard (not at Experimental). Given that we don't use the Draft Standard level for advancing standards track RFCs any more (post https://datatracker.ietf.org/doc/rfc6410/), would publishing a replacement that works better than RFC 1981 at Proposed Standard be a bad thing? Curiously yours, Spencer Joe _______________________________________________ Tsv-art mailing list Tsv-art@ietf.org https://www.ietf.org/mailman/listinfo/tsv-art --94eb2c0356909f8a4b054b03ccd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi, Joe,

    On Mar 18, 2017 11:27, "Joe Touch" <touch@isi.edu> wrote:
    =20 =20 =20

    FWIW, I was thinking of an update that focused on the description issue below.

    Nothing functionally would change.

    Ah - I'm glad I asked!
    =
    Thanks,

    Spencer

    =
    Joe
    On 3/18/2017 9:03 = AM, Spencer Dawkins at IETF wrote:
    I may not be answering the question Joe asked, but ...

    On Mar 17, 2017 19:36, "Joe Tou= ch" <touch@= isi.edu> wrote:


    On 3/17/2017 4:31 PM, Bob Hinden wrote:
    > Joe,
    >
    > I thi= nk this will be up to the AD and IESG.
    OK - I'll wait for them to respond.
    > If yo= u (and others) want to work on a major update, I am happy to share the XML.=C2=A0 I hope we don=E2=80=99t end up with can=E2=80= =99t move the current document forward, and no one wants to do a major update.
    I'd certainly prefer to have this doc address these issues.

    One question - if a major update occurred, would that be at the same
    standard level? If so, and if these issues are of concern, I'd be glad
    to take that on.

    If a major rev is a standards-level setback, that would be less useful.

    I'd like to hear their views...

    So, RFC 1981 is a Draft Standard, which is theoretically a bigger deal than a Proposed Standard. If a replacement to RFC 1981 doesn't work the same way that RFC 1981 works, I don't see how it would also be a Draft Standard= , based on the standards level of the RFC it would be replacing. Do others see something I'm missing?

    However.

    Assuming that a replacement for RFC 1981 Path MTU Discovery doesn't have the issues we've been talking = about in these threads, I would hope that we could publish that replacement at Proposed Standard (not at Experimental).

    Given that we don't use the Draft Standard le= vel for advancing standards track RFCs any more (post https://datatracke= r.ietf.org/doc/rfc6410/), would publishing a replacement that works better than RFC 1981 at Proposed Standard be a bad thing?

    Curiously yours,

    Spencer


    Joe

    _______________________________________________
    Tsv-art mailing list
    Tsv= -art@ietf.org
    https://www.ietf.org/mailman/lis= tinfo/tsv-art



    --94eb2c0356909f8a4b054b03ccd5-- From nobody Sun Mar 19 08:34:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7B51294D0 for ; Sun, 19 Mar 2017 08:34:32 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 kZ1k8hrD2zPW for ; Sun, 19 Mar 2017 08:34:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52761294EC for ; Sun, 19 Mar 2017 08:34:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 11630E1F6 for ; Sun, 19 Mar 2017 11:57:44 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BDB0E636BB for ; Sun, 19 Mar 2017 11:34:23 -0400 (EDT) From: Michael Richardson To: 6man WG Subject: Re: Manual PMTUD [was ...rfc2460bis-08] In-Reply-To: <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 15:34:32 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > It is really unthinkable to me to allow header insertion on the > Internet until we have a working solution to PMTUD in all > circumstances, which we don't, due to operators misconfiguring > middleboxes to drop ICMPv6/PTB, and due to RFC4821 being a rarity. In this debate we have seen essentially four arguments: 1) insertion is bad because 2) insertion is bad because PMTUD 3) insertion is bad because IPsec AH 4) insertion is bad because other ICMP issue/hard-to-diagnose weirdness Perhaps we will agree that (1) is not an argument. My claim is that (3) is irrelevant, IPsec AH has sadly (very very sadly from my point of view) failed. The PMTUD argument would be persuasive for me if PMTUD via ICMP really worked. My experience is that there are just way many problems. PLPMTUD has been the only way I've gotten IPv6 over IPsec tunnels (where there is an MTU constriction) to work consistently, and I had argued that 2460bis should standardize this rather than PMTUD. As for point (4), I think that we have a general problem here regardless of insertion. It would be nice to come up with some solutions to the problems of insertion, noting that insertion is just something that shines light on a fundamental problem. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljOpP8ACgkQgItw+93Q 3WUvTQf/dnvvMxCqKzKvuWhrnRcLYcJBi7x4N0OzOt024Vngtxf6FSj8eZm/qhDL EUkuNIopQbuz4UpKWmQdpWagmgQNvjtCS61W5bqxipyuli9tnGLE5Ds8/VlAiNTh kh+4fj4NkKyZAN2u81ommBLY39gCAYiE5Jkjn3cJFEFoCNR0L6sds2CtfXrU8jzj HhaAc79x+IArIPDvXQR/z4deiy+1TpzRJ4UfYsoNIy3cw1XBboPNUtB6EnDxs66c QCsV5kyAg2z9vhWhJuu/FDNcPIWg8yda/tA2y4WVrMyyHbkg2n85gLJwrl5itzH3 4pxYLgMzjIx2xF+LvxrFTi8e0SIRaQ== =mg8D -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 19 08:57:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD58A1289C3 for ; Sun, 19 Mar 2017 08:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZJ6OdIS-ZKvI for ; Sun, 19 Mar 2017 08:57:41 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5130127A90 for ; Sun, 19 Mar 2017 08:57:41 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id g138so72210621itb.0 for ; Sun, 19 Mar 2017 08:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=n4a3ebPxcQqCVg+YSE8FdagT/79tiFfwKNBNwJAC/cE=; b=McYEdyh+aVWZwfmqJKeNs4iwYNyXhbrfS+ioIAyW8rknKzoFi7yGmQJD65Z2X+jFzj Rs2Wd73JgQVkcZEVJw4bVn+pOMnNs7RceWGX7HBLaloHk1dnru50AI8yeO8jICiugeVp gZf1Q6FSzVZkpRuZkabazft4sM6Vbp7+Y/uyiq2F8XPQa7mk5uKOavWgxJDeBgVAeF+0 Z+wIP0NhB+ZOY8ul5qS7HGe3G9Sl82yx116zhHtNPR1DFsc9FS6Ll6DXDYAkjM6DiLJn 9n+yPxkA7HRRHWaTpVHy4lq2XUvtbmJZ/WfgQ7/969iIB3pDloCnP06suKQrEKrptd5G jxoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=n4a3ebPxcQqCVg+YSE8FdagT/79tiFfwKNBNwJAC/cE=; b=KZyDTd7LmV0gUX11jZ3TLnnzc3AbMc+06eQrSNRqYjDq68ST+8a9F6ANy4F5OqeFar HVR2XvS7AHOhRFtjDp8pb0ISOScifxx8rt9XPqkp5JbArhqwEibYvi08z8UiMtkxLQd3 D0FhbgtjOU0AEtq3/TjH9SXrBidx2oqYM3ETwrPokRHCzuPNmUn2YqOwG7yIKtkiRONi D6sokezDUV4tLc2l0chW1DdGZVTrkbNLXgIxVni+9mZ7YokVKdCj3mkZluCl2WGlAQGG 33+gYh0ciSzLIYsYifxD+JZANB6b5t/Y4KDCD+lqeHwtYdvA3b4nZKVFx7TcidqC3OtF l3aA== X-Gm-Message-State: AFeK/H2STZjc2mLWsV1xcaAI7ulvCX/NYMhXhiH7aDv9CDn1qnGBmbbo+AGIVxXYQzJs5w== X-Received: by 10.107.8.90 with SMTP id 87mr26412160ioi.111.1489939061114; Sun, 19 Mar 2017 08:57:41 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id j102sm7322391ioo.40.2017.03.19.08.57.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 08:57:40 -0700 (PDT) Subject: Re: Manual PMTUD [was ...rfc2460bis-08] To: Michael Richardson , 6man WG References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <32305.1489937663@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0e628656-f8b2-effb-9f93-2efe6b0ee4c5@gmail.com> Date: Mon, 20 Mar 2017 04:57:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <32305.1489937663@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 15:57:44 -0000 On 20/03/2017 04:34, Michael Richardson wrote: > > Brian E Carpenter wrote: > > It is really unthinkable to me to allow header insertion on the > > Internet until we have a working solution to PMTUD in all > > circumstances, which we don't, due to operators misconfiguring > > middleboxes to drop ICMPv6/PTB, and due to RFC4821 being a rarity. > > In this debate we have seen essentially four arguments: > > 1) insertion is bad because > 2) insertion is bad because PMTUD > 3) insertion is bad because IPsec AH > 4) insertion is bad because other ICMP issue/hard-to-diagnose weirdness > > Perhaps we will agree that (1) is not an argument. No, but the point is a bit more subtle. It's very clear to people who were there that the *intention* of RFC1883 and 2460 was to forbid insertion, so changing this (rather than clarifying it) during the promotion to Internet Standard would be against the IETF's process rules. You can claim that is a weak argument, but it is an argument. > My claim is that (3) is irrelevant, IPsec AH has sadly (very very sadly from > my point of view) failed. Yes. But if you want to leave the way clear for defining a non-failing alternative to AH, we would need inserted headers to be excluded from AHng, which means some new design, I think. > The PMTUD argument would be persuasive for me if PMTUD via ICMP really > worked. My experience is that there are just way many problems. PLPMTUD > has been the only way I've gotten IPv6 over IPsec tunnels (where there is an > MTU constriction) to work consistently, and I had argued that 2460bis should > standardize this rather than PMTUD. Right, but my understanding is that packets that grow in transit would break PLPMTUD as well (at least temporarily). > As for point (4), I think that we have a general problem here regardless of > insertion. It would be nice to come up with some solutions to the problems > of insertion, noting that insertion is just something that shines light > on a fundamental problem. Well, ICMP misrouting is kind of intrinsic in a connectionless datagram network with "transparent" middleboxes that mess with packets. I think you could spend the rest of your life failing to fix that. Writing local-use provisions for domains with very large internal MTUs is more practical, once we have 2460bis out of the way, IMHO. From nobody Sun Mar 19 10:18:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7723D1294FA for ; Sun, 19 Mar 2017 10:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 YVpmgSu8Gf7j for ; Sun, 19 Mar 2017 10:18:13 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814E2129501 for ; Sun, 19 Mar 2017 10:18:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 659531D2664; Sun, 19 Mar 2017 10:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1489943893; bh=Vf40U6sTkzgb/YrWHfN8ZLEhio7IVb94FImfqz29ahA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=h8VbrU1GEOj83HqfCjsSZ1Bu552g/J4JNpCVJVdx9DQCR2oiRzSLrBG0+Z94BllEo WT2fGkmUc06auqUwc+OmKXB0RzX48KT9e/mSUoiJFtXrT6OLs648/9SYg2LGUo7lL6 JVUF5+XkwjtWtKrGj2sts3YlUG3fAzX/9m/FYzzc= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id EFF4D1C0070; Sun, 19 Mar 2017 10:18:12 -0700 (PDT) Subject: Re: Manual PMTUD [was ...rfc2460bis-08] To: Michael Richardson , 6man WG References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <32305.1489937663@obiwan.sandelman.ca> From: "Joel M. Halpern" Message-ID: <730e8417-b88f-49a5-c8f5-39febc38dfa5@joelhalpern.com> Date: Sun, 19 Mar 2017 13:18:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <32305.1489937663@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 17:18:15 -0000 A) The AD has made the call. We should re-litigate on the ipv6 list a discussion and conclusion from the IETF list. B) My argument was not about whether insertion was in and of itself disastrous (although I do personally think it is a very bad idea). Rather, my argument has been that the current text is unclear. Some folks read it as permitting insertion. Other folks read it as prohibiting insertion. Unclear text, particularly for advancment to IS, is just not acceptable. I only include B in this note because you chose to describe the arguments being made. Yours, Joel On 3/19/17 11:34 AM, Michael Richardson wrote: > > Brian E Carpenter wrote: > > It is really unthinkable to me to allow header insertion on the > > Internet until we have a working solution to PMTUD in all > > circumstances, which we don't, due to operators misconfiguring > > middleboxes to drop ICMPv6/PTB, and due to RFC4821 being a rarity. > > In this debate we have seen essentially four arguments: > > 1) insertion is bad because > 2) insertion is bad because PMTUD > 3) insertion is bad because IPsec AH > 4) insertion is bad because other ICMP issue/hard-to-diagnose weirdness > > Perhaps we will agree that (1) is not an argument. > My claim is that (3) is irrelevant, IPsec AH has sadly (very very sadly from > my point of view) failed. > > The PMTUD argument would be persuasive for me if PMTUD via ICMP really > worked. My experience is that there are just way many problems. PLPMTUD > has been the only way I've gotten IPv6 over IPsec tunnels (where there is an > MTU constriction) to work consistently, and I had argued that 2460bis should > standardize this rather than PMTUD. > > As for point (4), I think that we have a general problem here regardless of > insertion. It would be nice to come up with some solutions to the problems > of insertion, noting that insertion is just something that shines light > on a fundamental problem. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sun Mar 19 11:39:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C08128D19 for ; Sun, 19 Mar 2017 11:39:30 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wANjMJjmLcrA for ; Sun, 19 Mar 2017 11:39:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A97F120326 for ; Sun, 19 Mar 2017 11:39:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B99C6E239; Sun, 19 Mar 2017 15:02:47 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 00F0A636BB; Sun, 19 Mar 2017 14:39:26 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: 6man WG Subject: Re: Manual PMTUD [was ...rfc2460bis-08] In-Reply-To: <0e628656-f8b2-effb-9f93-2efe6b0ee4c5@gmail.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <32305.1489937663@obiwan.sandelman.ca> <0e628656-f8b2-effb-9f93-2efe6b0ee4c5@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 18:39:31 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> My claim is that (3) is irrelevant, IPsec AH has sadly (very very >> sadly from my point of view) failed. > Yes. But if you want to leave the way clear for defining a non-failing > alternative to AH, we would need inserted headers to be excluded from > AHng, which means some new design, I think. The failure of AH across the Internet has nothing to do with the AH construct itself. It has to do with the failure to establish any kind of useable Internet-wide trust infrastructure anchored in ownership of IP addresses. You can't use AH to secure interesting headers across the Internet if you can't establish trust to do the key management. {IPsec ESP is equally a failure for Internet-wide usage, except that it is useful for VPNs and Remote access scenarios in which trust can be established in the small} Given that the alternative to header insertion is IPIP insertion, if one wants to protect headers, one can often use ESP equally well. The one advantage of AH was that one was sure that the stuff inside (after) the AH is unencrypted. This matters to firewalls and other auditing devices that wish to validate a flow, but not interfere with one. >> The PMTUD argument would be persuasive for me if PMTUD via ICMP really >> worked. My experience is that there are just way many problems. >> PLPMTUD has been the only way I've gotten IPv6 over IPsec tunnels >> (where there is an MTU constriction) to work consistently, and I had >> argued that 2460bis should standardize this rather than PMTUD. > Right, but my understanding is that packets that grow in transit would > break PLPMTUD as well (at least temporarily). Correct, but a path change also can cause such a thing, as can a lot of other things. >> As for point (4), I think that we have a general problem here >> regardless of insertion. It would be nice to come up with some >> solutions to the problems of insertion, noting that insertion is just >> something that shines light on a fundamental problem. > Well, ICMP misrouting is kind of intrinsic in a connectionless datagram > network with "transparent" middleboxes that mess with packets. I think > you could spend the rest of your life failing to fix that. My point is that we need tools that let us investigate problems that occur in the middle of the network. Particularly, in the middle of other people's networks. For instance, there are (have been?) bugs in some ECMP solutions that basically kill any TCP connection that lasts longer a few minutes. Nobody using HTTP ever notices... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljO0F4ACgkQgItw+93Q 3WWqIQf/WU5i0o0o15fg0Cjnj9XhJJ0gqBeIUCbv2xLb1E018ITt4jdAVUkIvpmV aGOlOR5MlWA6bHS7EgM3XRaJU+JOMhjGRIPkbZMoDBMYFLDIYrkaGBhWAKcP5ioY utl3jEEisuk+HfHnnDN98IwCKurwGyoebOLrMNOMLSH69kz5Sn3FhZumUQo+dVS4 pONfGljaoHCnAuGyYK+xwnaHbQ0RMEqpdW+gyOCNH3a+JBzWjWv9nG6foELajFqb KyyalzsJfZZeDFR/siSznQQBEBTbaxnVsIyX/3N9m5oqvHniqZz84nKzM2Y12TYP Ni19fDbzLuZaFB7j4x2ixwvEcrBb7w== =TUon -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 19 17:20:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1A7129434; Sun, 19 Mar 2017 17:20:02 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fZxX7H0ytN_g; Sun, 19 Mar 2017 17:20:00 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F6412702E; Sun, 19 Mar 2017 17:20:00 -0700 (PDT) X-AuditID: c6180641-c3fff70000000a06-a8-58ced9d3cf7f Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id ED.9F.02566.3D9DEC85; Sun, 19 Mar 2017 20:19:51 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0319.002; Sun, 19 Mar 2017 20:19:54 -0400 From: Suresh Krishnan To: "ietf@ietf.org" , 6man WG Subject: IETF Last Call conclusion for draft-ietf-6man-rfc4291bis-07 Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc4291bis-07 Thread-Index: AQHSoQ+vtzlHxC1V3kSVc+LLDJ9iTA== Date: Mon, 20 Mar 2017 00:19:49 +0000 Message-ID: <4892552B-1467-480C-8BFF-CE468D85221D@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/signed; boundary="Apple-Mail=_23B4D3B3-BFCD-4CCC-AC7E-9A57F4CFB460"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPoO71m+ciDM6uYLR4tnE+i8XLs++Z HJg8liz5yRTAGMVlk5Kak1mWWqRvl8CVcWPOA8aCNtOKu5MusDcwLjLqYuTkkBAwkWh9N5m9 i5GLQ0hgPaNEz7IlrCAJIYHljBKrZuaA2GxARRt2fmYCsUUEbCRm7uoFquHgEBZwkZh3Owwi 7CnR9vEIK4StJzH5ZScziM0ioCrRsr0RLM4rYC/xY/YUNhCbUUBM4vupNWAjmQXEJW49mc8E cY+IxMOLp9kgbFGJl4//sULYShJzXl9jBrmTWWAKo8TfhjvsEEMFJU7OfMIygVFwFpJZs5DV zUJSB1GkLbFs4WvmWUA/MAvoSExeyAgRNpV4ffQjlG0tMePXQTYIW1FiSvdD9gWMHKsYOUqL C3Jy040MNzECY+CYBJvjDsa9vZ6HGAU4GJV4eD/MORchxJpYVlyZe4hRBaj10YbVFxilWPLy 81KVRHiFeM5HCPGmJFZWpRblxxeV5qQWH2KU5mBREue9HnI/XEggPbEkNTs1tSC1CCbLxMEp 1cBYdPThd1sbr0PtXLsjsh1P/9KY6B50z2d6X6N47ZY8HcH/28Sr3BOYj0uv/uewrOqh69oH Ufvu9G1kUXJNCm5m7Squl114UsImy17lRXuz5hQmnm2VW/8LS5sqf2r/8iN0U4HkD9WrKRxy JYXMrq/cGn59X2XYcqz0AMNsvp3OThpnHx/236/EUpyRaKjFXFScCACaYNdfiQIAAA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 00:20:02 -0000 --Apple-Mail=_23B4D3B3-BFCD-4CCC-AC7E-9A57F4CFB460 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, Thanks to everyone who commented during the IETF Last Call of = draft-ietf-6man-rfc4291bis-07. The IETF last call discussion for this = draft was passionate (and sometimes heated). The discussion was mainly = focused on the 64-bit boundary in IPv6 addressing and the associated = text in Section 2.4. I have had a lot of private one to one and group = discussions with several folks who had commented and contributed text = suggestions to get a better idea of their concerns. There seems to be a = strong divide between parts of the community on whether this restriction = should stay or be relaxed. Looking at the viewpoints expressed and how = wide apart they are, it has become clear that there is a lack of = consensus to advance the current draft as Internet Standard. Based on = this lack of consensus, I have decided to return the draft back to the = working group to continue discussion. Thanks Suresh= --Apple-Mail=_23B4D3B3-BFCD-4CCC-AC7E-9A57F4CFB460 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzIwMDAxOTUxWjAjBgkqhkiG9w0B CQQxFgQUPhz5nZag4/gk0lDrGZlMqRjjhSMwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQBbTu3YBpc0rFVPfbnQaHoOtofzuXnc6IPL27rDVTnjAnDIhfptjYF24mLwDzrn Bv2jAWYEJdx8KMgH0s3A1IBmT1Ufzgljbz8e+XRSd3fr87Pa6ERqIGvt2DUyIuOfU3/utV+DQ9o6 OuW0FnmKGzJk35DR9a85j7sSrHR/MqjIafI4Di1QqGbDWidhx2n7ospVRTm1MODqXZrZQ9hB/sOC zg2WBxWz57KaSEll5G2wpGlgu4HfSKgSVmPulTkshGEPlf+gvAXMb9nzn2oXX2ibh/IHVwcYAD0s VuNmt92doGjVIzHW/r2bUpzxEiKWRSLDYcgC8yrFsF+B0kqWwEagAAAAAAAA --Apple-Mail=_23B4D3B3-BFCD-4CCC-AC7E-9A57F4CFB460-- From nobody Sun Mar 19 22:54:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6F412965E for ; Sun, 19 Mar 2017 22:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DsbzB1MypIzH for ; Sun, 19 Mar 2017 22:54:33 -0700 (PDT) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686B1129659 for ; Sun, 19 Mar 2017 22:54:33 -0700 (PDT) Received: by mail-yw0-x241.google.com with SMTP id h11so12809401ywa.2 for ; Sun, 19 Mar 2017 22:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CAOPJAUOdfH0VeezgXSliow3EQPeryONn7NOBMPxDho=; b=QUcLMZOVH8+MaJjPeLb2O3N5yjJnsw4uYV/hp4qrxl3Rw6C88t8AChynOF1hCMPVem MbXjYTYU6qDvRVKXVM3TsgGb86FknpjIy/CQXHIJWRuMvu2hC7O0APDEuGruEh9GaJ8z 9jLrATOY1C84RyShpWrb0Xu6BfrIizV8NFHW6daxByAmgo/HpknoioQDJIVifAX+hbA0 S1qAK+Ewz768eU4SM/e84B07abdWN7Nq/IZKJh0Xz6KA+CvccoaWPracd20NKTI2AV+d XKhg5QpYcIx3gHS/TrXoS9eX7YaNdkuSvGBr/tQF5j2cs3Ws7y3fezfEtvK0uGellidy nmpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CAOPJAUOdfH0VeezgXSliow3EQPeryONn7NOBMPxDho=; b=Ab3lAoloWcxL03+dZBNFqEshI0o7cOrHoabyDjXbIkUilOpw9uvmInV+6+YUWqWgtH yf8EaALGmh2zE3tmImrNMQSuIDHDKB83pI1CGoPR+ZDuuCjGh0XleeL2agG0uQ/mOS7e rb3zOc2zdzdEG21u+li2R04Mc2PPNyh2XZigoa3jcO53R96TA+Ls3Ruwtrr9q9G+ejTh CMCi92Olx8+othPA8LoQGBU6UEtLVT8AueqoQIE78Q0r/m0w0ayeyBmDPrHE8bJI4JSI IcGErbPJ+sfSw0Zm8rU+WvRDFxuWCEHN/9XhOZdxVZOfvUf132qEG/LdElsgwgDCPs30 4eng== X-Gm-Message-State: AFeK/H0ui9TJOjq5RWjl8zQablsEChxowKtuPA7z+5ziVihk3ehmy+F51SXOuR19caNRauAZkYP9i6Zs3ah5xA== X-Received: by 10.37.206.199 with SMTP id x190mr12198570ybe.129.1489989272525; Sun, 19 Mar 2017 22:54:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.248.194 with HTTP; Sun, 19 Mar 2017 22:54:02 -0700 (PDT) In-Reply-To: <20170317231004.18BD3B80D93@rfc-editor.org> References: <20170317231004.18BD3B80D93@rfc-editor.org> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 20 Mar 2017 14:54:02 +0900 Message-ID: Subject: Re: RFC 8106 on IPv6 Router Advertisement Options for DNS Configuration To: IETF IPv6 Mailing List Cc: RFC Editor , skku_secu-brain_all@googlegroups.com, "Mr. Jaehoon Paul Jeong" , "Soohong Daniel Park, Ph.D." , Luc Beloeil , Syam Madanapalli Content-Type: multipart/alternative; boundary=94eb2c18a2864f13c8054b2329e7 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 05:54:36 -0000 --94eb2c18a2864f13c8054b2329e7 Content-Type: text/plain; charset=UTF-8 Dear 6MAN WG People, We, the authors of RFC 8106, sincerely appreciate the inputs and comments by Robert Hinden, Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, Tony Cheneau, Fernando Gont, Jen Linkova, Ole Troan, Mark Smith, Tatuya Jinmei, Lorenzo Colitti, Tore Anderson, David Farmer, Bing Liu, and Tassos Chatzithomaoglou. We give sincere thanks to them for their contributions again. Specially, we authors sincerely appreciate the consistent guidance and generous help of our WG chairs, Bob and Ole, and also the document shepherd, Fernando. I hope the RA DNS options will be useful for IPv6 deployment in the world. Thanks. Best Regards, Paul, Daniel, Luc, and Syam -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php On Sat, Mar 18, 2017 at 8:10 AM, wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 8106 > > Title: IPv6 Router Advertisement Options for > DNS Configuration > Author: J. Jeong, > S. Park, > L. Beloeil, > S. Madanapalli > Status: Standards Track > Stream: IETF > Date: March 2017 > Mailbox: pauljeong@skku.edu, > soohong.park@samsung.com, > luc.beloeil@orange.com, > smadanapalli@gmail.com > Pages: 19 > Characters: 43092 > Obsoletes: RFC 6106 > > I-D Tag: draft-ietf-6man-rdnss-rfc6106bis-16.txt > > URL: https://www.rfc-editor.org/info/rfc8106 > > DOI: 10.17487/RFC8106 > > This document specifies IPv6 Router Advertisement (RA) options > (called "DNS RA options") to allow IPv6 routers to advertise a list > of DNS Recursive Server Addresses and a DNS Search List to IPv6 > hosts. > > This document, which obsoletes RFC 6106, defines a higher default > value of the lifetime of the DNS RA options to reduce the likelihood > of expiry of the options on links with a relatively high rate of > packet loss. > > This document is a product of the IPv6 Maintenance Working Group of the > IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c18a2864f13c8054b2329e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Dear 6MAN WG People,

    We, the autho= rs of RFC 8106, sincerely appreciate the inputs and comments by=C2=A0
    =
    Robert Hinden, Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim= Chown,=C2=A0
    Erik Nordmark, Dan Wing, Jari Arkko, Ben Campbell, = Vincent Roca, Tony Cheneau,=C2=A0
    Fernando Gont, Jen Linkova, Ole= Troan, Mark Smith, Tatuya Jinmei, Lorenzo Colitti,=C2=A0
    Tore An= derson, David Farmer, Bing Liu, and Tassos Chatzithomaoglou. =C2=A0
    We give sincere thanks to them for their contributions again.
    =
    Specially, we authors sincerely appreciate the consistent gu= idance and generous help of=C2=A0
    our WG chairs, Bob and Ole, and= also the document shepherd, Fernando.

    I hope the = RA DNS options will be useful for IPv6 deployment in the world.
    <= br>
    Thanks.

    Best Regards,
    Paul= , Daniel, Luc, and Syam
    --=C2=A0
    =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Mr. J= aehoon (Paul) Jeong, Ph.D.
    Assistant Professor
    Department of Software=
    Sungkyunkwan University
    Office: +82-31-299-4957
    Email:=C2=A0jaehoon.paul@gmail.c= om,=C2=A0pauljeong@skku.edu
    Personal Homepage:=C2=A0= http://iotlab.skku.edu/people-jaehoon-jeong.php
    =

    On Sat, Mar 18, 2017 at 8:10 AM, <rfc-editor@rfc-editor.org&= gt; wrote:
    A ne= w Request for Comments is now available in online RFC libraries.


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 8106

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 IPv6 Router Advertis= ement Options for
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS C= onfiguration
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0J. Jeong,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S. Pa= rk,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 L. Be= loeil,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S. Ma= danapalli
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Standards Track
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0March 2017
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 pauljeong@skku.edu,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 soohong.park@samsung.com,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 luc.beloeil@orange.com,
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 smadanapalli@gmail.com
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 19
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 43092
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Obsoletes:=C2=A0 RFC 6106

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-6man-rdnss-rfc6106bis-16.txt

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc8106

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 10.17487/RFC810= 6

    This document specifies IPv6 Router Advertisement (RA) options
    (called "DNS RA options") to allow IPv6 routers to advertise a li= st
    of DNS Recursive Server Addresses and a DNS Search List to IPv6
    hosts.

    This document, which obsoletes RFC 6106, defines a higher default
    value of the lifetime of the DNS RA options to reduce the likelihood
    of expiry of the options on links with a relatively high rate of
    packet loss.

    This document is a product of the IPv6 Maintenance Working Group of the IET= F.

    This is now a Proposed Standard.

    STANDARDS TRACK: This document specifies an Internet Standards Track
    protocol for the Internet community, and requests discussion and suggestion= s
    for improvements.=C2=A0 Please refer to the current edition of the Official=
    Internet Protocol Standards (https://www.rfc-editor.org/sta= ndards) for the
    standardization state and status of this protocol.=C2=A0 Distribution of th= is
    memo is unlimited.

    This announcement is sent to the IETF-Announce and rfc-dist lists.
    To subscribe or unsubscribe, see
    =C2=A0 https://www.ietf.org/mailman/listinf= o/ietf-announce
    =C2=A0 https://mailman.rfc-editor.org/m= ailman/listinfo/rfc-dist

    For searching the RFC series, see https://www.rfc-editor.org/s= earch
    For downloading RFCs, see https://www.rfc-editor.org/re= trieve/bulk

    Requests for special distribution should be addressed to either the
    author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
    specifically noted otherwise on the RFC itself, all RFCs are for
    unlimited distribution.


    The RFC Editor Team
    Association Management Solutions, LLC


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


    --94eb2c18a2864f13c8054b2329e7-- From nobody Sun Mar 19 23:05:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FCB129666 for ; Sun, 19 Mar 2017 23:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cTM_EnaSuG7G for ; Sun, 19 Mar 2017 23:05:01 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55448129664 for ; Sun, 19 Mar 2017 23:05:01 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cpqR9-0005HV-Es for ipv6@ietf.org; Mon, 20 Mar 2017 07:05:00 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cpqR6-0007hK-QW for ipv6@ietf.org; Mon, 20 Mar 2017 02:04:58 -0400 Received: (qmail 8316 invoked from network); 20 Mar 2017 06:04:56 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.159]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 20 Mar 2017 06:04:55 -0000 To: Michael Richardson , Brian E Carpenter References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <32305.1489937663@obiwan.sandelman.ca> <0e628656-f8b2-effb-9f93-2efe6b0ee4c5@gmail.com> <11502.1489948766@obiwan.sandelman.ca> Cc: 6man WG From: Christian Huitema Message-ID: <735862da-0e36-b36d-5f0f-0c25245c0f2a@huitema.net> Date: Sun, 19 Mar 2017 23:04:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <11502.1489948766@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: Failure of AH (was: Manual PMTUD [was ...rfc2460bis-08]) X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqtC9bX902CF4fHELku6QViRcOb18WfxGyg6Om6u4YYm4udeGBsmSplqZho lGIsXMM5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKXTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK012vqlI8f Y5fCKD8E3jmorbbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWHxcEeYXaEh7Ip8nBmIzXZwpqT8auRNlXQctohljUCg+q0j2kq6TK6p+e UaUg655eKhBaevb8pkwVq3+XN9bPyjRMyLUEno1frs9vZR0iI5iTGneI1cCMIcE6R6jtJ8btb7sy ltanepIHrA9+HqSAzfrQq23LWyXZeC7ahMm5trYQxK4Q6pnz1PG2i0Jcu7De X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 06:05:03 -0000 On 3/19/2017 11:39 AM, Michael Richardson wrote: > The failure of AH across the Internet has nothing to do with the AH construct > itself. It has to do with the failure to establish any kind of useable > Internet-wide trust infrastructure anchored in ownership of IP addresses. It also has to do with the undesirability of using IP addresses as long term identifiers. The concept of "trust infrastructure" implies some degree of stability in the identifiers. This is exactly what you don't want if you are concerned with privacy. -- Christian Huitema From nobody Mon Mar 20 07:18:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850BA1294B2 for ; Mon, 20 Mar 2017 07:17:59 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eXIi0TdkS2ts for ; Mon, 20 Mar 2017 07:17:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9138B13149A for ; Mon, 20 Mar 2017 07:17:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A7ED52009E; Mon, 20 Mar 2017 10:41:19 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 18446636BB; Mon, 20 Mar 2017 10:17:56 -0400 (EDT) From: Michael Richardson To: Christian Huitema cc: Brian E Carpenter , 6man WG Subject: Re: Failure of AH (was: Manual PMTUD [was ...rfc2460bis-08]) In-Reply-To: <735862da-0e36-b36d-5f0f-0c25245c0f2a@huitema.net> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <32305.1489937663@obiwan.sandelman.ca> <0e628656-f8b2-effb-9f93-2efe6b0ee4c5@gmail.com> <11502.1489948766@obiwan.sandelman.ca> <735862da-0e36-b36d-5f0f-0c25245c0f2a@huitema.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:17:59 -0000 --=-=-= Content-Type: text/plain Christian Huitema wrote: > On 3/19/2017 11:39 AM, Michael Richardson wrote: >> The failure of AH across the Internet has nothing to do with the AH >> construct itself. It has to do with the failure to establish any kind >> of useable Internet-wide trust infrastructure anchored in ownership of >> IP addresses. > It also has to do with the undesirability of using IP addresses as long > term identifiers. The concept of "trust infrastructure" implies some > degree of stability in the identifiers. This is exactly what you don't > want if you are concerned with privacy. That's a good additional reason why we can't build long-term trust on IP addresses. Short-term trust (for durations of minutes to a few hours) does not seem to be as big an issue. Afterall, we do this all the time with TCP SYN/ACK three way handshake. And, notice that I didn't actually say that... I said "in ownership of IP addresses"... I would prefer to be able to map IP address-->ASN, and then see how that could map to an operator's public key. And then throw in v6PD and homenet users, and... (hey, stop laughing! A crypto-geek can dream, can't he?) The point is that AH for protection of headers is dead because we don't have one of those. And if you aren't protecting headers, then you can/should use ESP. (or as people actually do: TLS) So I'm just not worried about breaking AH. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljP5JMACgkQgItw+93Q 3WWhKQf8C27wTE4GboSvtvTqxUCKREUxMOS5+2Ncbh6Rv9zATEKb8bAK4mhqI/yJ CRLq4CqdG498oTQDn2zUUi9MZbDuMhfWOdzZ0Od8iiEFDXClJeRV1vzbEWsX4Exs AiSjCqL/ys5gcwNS9UINCghnqcd24S228EyMrhZWAA+ZDPYXZ60IoVxHChm88C2k 32bz0yw+a/3av8jM+ULq465dVAIhU/mDubaUgtusz706C83lQ7fVjvY5hPuAgm3/ JL2VdoUmjtOxiYrY/UP48U0yeKghzZhbPne1NUjMCRxH191djUyfy+kaoS9Qxoix xtj/6nmdWOobRS0n2341m36hhYIb/g== =VCwW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 20 10:00:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488281314EA; Mon, 20 Mar 2017 10:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Atz5LKr1yITU; Mon, 20 Mar 2017 10:00:17 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BFF1314EB; Mon, 20 Mar 2017 10:00:10 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id u48so96587174wrc.0; Mon, 20 Mar 2017 10:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=vr7v4fxuJaoyAL9kXg13j+/wZL4Jazj4Po+eAS00wDs=; b=qRF3CLZ8NJAnEmrZlx6UAki6ZAhzuDIJCPyhKRaRh2l9H6CIh9SCeKdYBVi6pjjSq1 wvE9a0QjG/oq5l2ycOKupRiWdfmQjSQbqxKYt6yY/xgqxufXzvsG/6n8vJ45LFq97+jS hB3ZlGGPNT9E3IqChH+XKrEb0PYPJZR2iEuHXZfTGuxzZVD8Ro1QRgEa3aGZ108dkIqw DwDR7WSv2JQknlUoaDPk0Fj74KzTD9mFF0HSroaRhScjmDTdsBS6Yr4lFkGA0VgSVErb h6nHu+720u0cyqOTBr+EWi83SSZljqMwe7hKaco+Pgey8Yu+0NsU7awvC01SIVe1RLHM DxJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=vr7v4fxuJaoyAL9kXg13j+/wZL4Jazj4Po+eAS00wDs=; b=eYMEH4QsOUTGE2clzRLyEqVsEYZv/Pr8Gjpk7I3aNkVcEv3V+96ejuCPWq46G3SHcO 0wMa0Jw2Mq0fOkN7SHDUgNI42i/Wfjd/mkgxFteCDEpZjmF2HB53UYOEnbEmJuo6Ywav O25oYE1jD44T388pl1CBdhMHflRP2VTy3Q+nGq+XXr52hUfd5cX9yUQKkLmjODjOZHEa RtKxFoH/XxiGqGAMPjVvtIWsxYtZSVcYI4uDqWUT2wWeyyGQypcFEGnRGIT828dUJlhJ 12afR4sj7kEQEcUTKfMWVi/Cq+P90nFg7PyK8X8ZoFNWVkVca/J9OIuObQOhft+Rmp34 OKzw== X-Gm-Message-State: AFeK/H3ws7WzwniPcph4F+ZQiYaIOj/EuW4vUlB+xLuSBml7XQWYV3T9xW0knNh7ARQKKg== X-Received: by 10.223.172.101 with SMTP id v92mr29313481wrc.49.1490029208977; Mon, 20 Mar 2017 10:00:08 -0700 (PDT) Received: from [172.16.2.119] (91.75.134.77.rev.sfr.net. [77.134.75.91]) by smtp.gmail.com with ESMTPSA id r8sm21421475wrb.33.2017.03.20.10.00.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 10:00:08 -0700 (PDT) Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04 To: Bob Hinden , Stewart Bryant References: <148665359396.20513.9749548375095869760.idtracker@ietfa.amsl.com> <5BABA19D-58F8-44AE-BF18-9A0B9CCADED4@gmail.com> Cc: IPv6 List , gen-art@ietf.org, IETF , draft-ietf-6man-rfc1981bis.all@ietf.org From: Stewart Bryant Message-ID: Date: Mon, 20 Mar 2017 17:00:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5BABA19D-58F8-44AE-BF18-9A0B9CCADED4@gmail.com> Content-Type: multipart/alternative; boundary="------------D16124D1E89C620CFECE780A" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 17:00:23 -0000 This is a multi-part message in MIME format. --------------D16124D1E89C620CFECE780A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 17/03/2017 21:56, Bob Hinden wrote: > Hi Stewart, > > Thanks for the detailed review. I am responding after reading the email thread that resulted, some issues were closed. > > Several of the reviews have suggested significant changes to this document. The working group was trying to make a few changes to bring it into alignment with some changes to rfc2460bis (based on updating documents). It was not attempting a major rewrite when advancing it to Internet Standard. The alternative that the working group discussed was to file errata on RFC1981 and leave it to a future document update. That might be the way to go. At the end of the day it is an IESG decision, but I was somewhat disquieted by the number of issues and comments raised across the set of reviewers. When we elevate a document to standard we are saying that it represents a fully baked idea that has no significant defects. The question given the level of comments is does this meet that bar? > > I don’t think many of these changes can be done and still advance it to Internet Standard. If we can’t advance the current document, then the w.g. may want to just do the errata and withdraw the advancement request. Of course, if people want to work on a revision of IPv6 Path MTU Discovery, it would be welcomed, but it won’t be able to advanced to Internet Standard. Given the level of discussion, I would think that the WG should seriously consider a revised version clearing up the full set of issues raised in discussion. Responses in line Best Regards Stewart > > Comments below. > > Thanks, > Bob > > >> On Feb 9, 2017, at 7:19 AM, Stewart Bryant wrote: >> >> Reviewer: Stewart Bryant >> Review result: Almost Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-6man-rfc1981bis-04 >> Reviewer: Stewart Bryant >> Review Date: 9/Feb/2017 >> IETF LC End Date: 1/Mar/2017 >> IESG Telechat date: unknown >> >> Summary: This draft is on the right track but has open issues, >> described in the review. >> >> This review together with the lengthy discussion on the IETF list >> suggest that this draft has a number of issues that need to be >> addressed before publication. >> >> I wonder if we would best serve both our future and our heritage >> if we declared RFC1981 as historic, and either left the idea there, >> or declared it as historic and wrote a new text from a clean start? >> >> > I think this was closed in the email thread. OK > > >> Major issues: >> >> Nits points out a number of faults with the document, but the only >> one of substance is: >> >> The text has a lot of RFC2119 language, but no RFC2119 declaration. >> >> The document could use a thorough RFC2119 scrub > Based on in an earlier another review, our AD suggested an update to Shepard Writeup instead of adding something to the document. It says: > > This document is an update to RFC1981 that was published prior to > RFC2119 being published. Consequently while it does use "should/must" > style language in upper and lower case, the document does not cite the > RFC2119 definitions. Since the changes in this update were very > limited, the w.g. concluded to not change any of this language. This is really an IESG decision. > >> The document lists the three original authors one with an affiliation >> >> change, but no email addresses. Has this been agreed with the >> original >> authors, and have arrangements been put in place for the RFC editor >> to process auth48? > I contacted the original authors and they didn’t express any interest in being involved in this update. They haven’t participated in the IETF for many years. I can contact them during AUTH48, or the AD can override this requirement for this document. So long as you have an arrangement in place that is acceptable to the RFC Editor and IESG. >> It is concerning that the draft does not talk in any detail about >> how modern ECMP works, i.e. using the five tuple, and noting that >> the PMTU may be different depending on the transport layer port >> numbers. >> > I think this is out of scope. So long as PMTU is bound to the five tuple (which I think it is), then the mechanism works, but given the prevalence of ECMP (pretty much every packet going across the core will be sujected to it) I don't think I agree that a discussion is out of scope. > > >> Given that a very large fraction of packets will traverse an MPLS >> network at some point, I am surprised that there is no text talking >> about the importance of providing support for this feature in the >> MPLS domain. RFC3988 talks to this point, but is only experimental. >> > I think this was closed in the email thread. It was ruled out of scope on the basis that tunnel were out of scope, but this tunnel type does need some special consideration, particularly as nearly every packet crossing the Internet goes across this tunnel type a number of times in its passage. For me it is ore a question of providing the best advice to the reader, rather than minimising change. > >> ====== >> >> If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation >> could use the flow id as the local representation of a path. >> Packets >> sent to a particular destination but belonging to different flows >> may >> use different paths, with the choice of path depending on the flow >> id. This approach will result in the use of optimally sized >> packets >> on a per-flow basis, providing finer granularity than PMTU values >> maintained on a per-destination basis. >> >> SB> How widely is flow-id supported in networks? I thought that the >> SB> current position was that it was unreliable as an ECMP indicator >> SB> and thus routers tended to glean information from the packet >> themselves. > I think this was closed in the email thread. > >> ====== >> >> Note: if the original packet contained a Routing header, the >> Routing header should be used to determine the location of the >> destination address within the original packet. If Segments >> Left >> is equal to zero, the destination address is in the Destination >> Address field in the IPv6 header. If Segments Left is greater >> than zero, the destination address is the last address >> (Address[n]) in the Routing header. >> >> SB> So this has the effect that a traffic engineered packet and >> SB> a non-traffic engineered packet will have the lower of the >> SB> two PMTUs. This was all harmless when source routing was a >> curiosity >> SB> as far as mainstream networking was concerned, but may be >> SB> more of a problem as a result of the SPRING work. > I think the onus is on SPRING to make sure it doesn’t break existing mechanisms. .. or really doesn't break them any more than they discussion on this draft suggests that they are already broken. > >> ======= >> >> >> 5.3. Purging stale PMTU information >> >> Internetwork topology is dynamic; routes change over time. While >> the >> local representation of a path may remain constant, the actual >> path(s) in use may change. Thus, PMTU information cached by a >> node >> can become stale. >> >> If the stale PMTU value is too large, this will be discovered >> almost >> immediately once a large enough packet is sent on the path. No >> such >> mechanism exists for realizing that a stale PMTU value is too >> small, >> so an implementation should "age" cached values. When a PMTU >> value >> has not been decreased for a while (on the order of 10 minutes), >> the >> PMTU estimate should be set to the MTU of the first-hop link, and >> the >> packetization layers should be notified of the change. This will >> cause the complete Path MTU Discovery process to take place again. >> >> SB> Should that be an RFC2119 SHOULD? >> SB> The impact of this advice is going to be a disruption to what >> might >> SB> be a critical service every 10 mins. >> SB> Should there be some advice along the lines of noting the >> SB> importance of service delivery as part of deciding whether to >> SB> test for bigger PMTU vs improving efficiency? >> >> ======= >> >> >> Minor issues: >> >> IPv6 defines a standard mechanism for a node to discover the >> PMTU of an arbitrary path. >> >> SB> Do you mean "This document defines ....."? Otherwise this needs >> SB> a reference. > Will fix. > >> ======= >> >> An extension to Path MTU Discovery defined in this document can be >> found in [RFC4821]. It defines a method for Packetization Layer >> Path >> SB> Rather than have the reader figure out what "It" is, perhaps >> SB> s/It/RFC4821/ > The w.g. noodled on this text for a long time. I think the “it” is clear, but will change to RFC4821. > > >> ======= >> >> >> Upon receipt of such a >> message, the source node reduces its assumed PMTU for the path >> based >> on the MTU of the constricting hop as reported in the Packet Too >> Big >> message. >> >> SB> We should perhaps state up front that this procedure >> SB> hunts for the worst case of the ECMP set associated with the >> SB> ingress nodes PMTU classifier. > I think getting into ECMP is out of scope for moving this to IS. Yes, but I don't think you should set elevation to standard above providing the best advice, which is what seems to be proposed here. > > >> ======= >> >> If a node receives a Packet Too Big message reporting a next-hop >> MTU >> that is less than the IPv6 minimum link MTU, it should discard it. >> >> SB> Should that be an RFC2119 SHOULD? > See note above. > >> ======= >> >> 5.2. Storing PMTU information >> >> Ideally, a PMTU value should be associated with a specific path >> traversed by packets exchanged between the source and destination >> nodes. However, in most cases a node will not have enough >> information to completely and accurately identify such a path. >> Rather, a node must associate a PMTU value with some local >> representation of a path. It is left to the implementation to >> select >> the local representation of a path. >> >> SB> Is it worth noting the five tuple since that is how a lot of >> SB> load balancers work? > I think getting into ECMP is out of scope for moving this to IS. > >> ======= >> >> The set of paths in use to a >> particular destination is expected to be small, in many cases >> consisting of a single path. >> >> SB> I am not sure that remains true in modern networks. > Do we have any data on this? I wonder if there will be much difference in the PMTU in this case. In a well managed network the point is probably moot since all paths should have the same PMTU except under error conditions, but the path set can be quite large, and certainly more that a single path. >> ======= >> >> One approach to implementing PMTU aging is to associate a >> timestamp >> field with a PMTU value. This field is initialized to a >> "reserved" >> value, indicating that the PMTU is equal to the MTU of the first >> hop >> link. Whenever the PMTU is decreased in response to a Packet Too >> Big >> message, the timestamp is set to the current time. >> >> Once a minute, a timer-driven procedure runs through all cached >> PMTU >> values, and for each PMTU whose timestamp is not "reserved" and is >> older than the timeout interval: >> >> - The PMTU estimate is set to the MTU of the first hop link. >> >> - The timestamp is set to the "reserved" value. >> >> - Packetization layers using this path are notified of the >> increase. >> >> >> SB> Such detailed implementation advice is uncommon in modern RFCs. It >> has >> SB> the disadvantage of de-facto standardizing something that should >> be left to >> SB> the innovation of the implementer. > Can you point to any harm this has caused? It is very widely implemented. It tends to result in people treating the example complete with any artifacts as normative. Which gives implementors less scope for optimisation, and can result in restrictions beyond the true intent of the WG. Now I am not sure if there is a problem here, but I think it is bad practise in general. > >> ======= >> >> 5.4. TCP layer actions >> >> SB> TCP implementations have moved on a lot since this section was >> SB> written. Is this still current best practise? >> >> ======= >> >> 5.5. Issues for other transport protocols >> >> Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed >> to >> repacketize when doing a retransmission. >> >> SB> How much TP4 is there going over IPv6? Doesn't this example >> SB> show the IETF as not being in the modern age? > > I have no information one way or another. I have heard there is some TP4 on airplanes, may they will move it to IPv6 :-) It really depends on whether the goal is to elevate what was originally written or to provide best current advice. > >> ======= >> >> Nits/editorial comments: >> >> upper layer a protocol layer immediately above IPv6. >> Examples are transport protocols such as TCP >> and >> UDP, control protocols such as ICMP, routing >> protocols such as OSPF, and internet or lower- >> layer protocols being "tunneled" over (i.e., >> encapsulated in) IPv6 such as IPX, AppleTalk, >> or >> IPv6 itself. >> >> SB> Everything in the list above is in the well known list, except >> SB> IPX, so technically it needs expansion. However it might be nice >> SB> to use some modern example in common use. > I will add a reference to IPX. The best reference I have found to IPX is: > > Novell, Inc., "Advanced NetWare V2.1 Internetwork Packet Exchange > Protocol (IPX) with Asynchronous Event Scheduler (AES)", October > 1986. > > Please suggest something better. I stand by my original view that we should use modern examples and leave it to the IESG to decide which path they prefer. > > >> ======= >> >> link a communication facility or medium over which >> nodes can communicate at the link layer, i.e., >> the layer immediately below IPv6. Examples >> are >> Ethernets (simple or bridged); PPP links; >> X.25, >> Frame Relay, or ATM networks; and internet (or >> higher) layer "tunnels", such as tunnels over >> IPv4 or IPv6 itself. >> >> SB> Technically X.25 needs a reference, since it is not "well known” > Will add a reference, if you think it is necessary. > >> ======= >> >> path the set of links traversed by a packet between >> a >> source node and a destination node. >> >> SB> Is it a set of links, or a set of links and nodes? > I think the current text is OK. > >> ======== >> >> the value of MMS_S, the "maximum send transport-message size". >> SB> The modern convention is full-name(abbreviation) > I don’t follow this. A really minor point. A RFC usually expresses this as the maximum send transport-message size (MMS_S), but that is a house style thing. > >> ======== >> >> The Sun Network File System (NFS) uses a Remote Procedure Call >> (RPC) >> protocol [RPC] that, when used over UDP, in many cases will >> generate >> payloads that must be fragmented even for the first-hop link. >> This >> might improve performance in certain cases, but it is known to >> cause >> reliability and performance problems, especially when the client >> and >> server are separated by routers. >> >> SB> Perhaps this should point to RFC7530 (the current NFS Spec), >> assuming >> SB> the behaviour description is still correct. > Will do. > >> ========= >> >> The former can be accomplished by associating a flag with the >> path; >> when a packet is sent on a path with this flag set, the IP layer >> does >> not send packets larger than the IPv6 minimum link MTU. >> >> SB> We do not normally give this level of implementation advice > I think it varies a lot. OK > >> ======================== >> >> >> > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --------------D16124D1E89C620CFECE780A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



    On 17/03/2017 21:56, Bob Hinden wrote:
    Hi Stewart,

Thanks for the detailed review.  I am responding after reading the email thread that resulted, some issues were closed.

Several of the reviews have suggested significant changes to this document.  The working group was trying to make a few changes to bring it into alignment with some changes to rfc2460bis (based on updating documents).  It was not attempting a major rewrite when advancing it to Internet Standard.  The alternative that the working group discussed was to file errata on RFC1981 and leave it to a future document update.

    That might be the way to go.

    At the end of the day it is an IESG decision, but I was somewhat disquieted by the number of issues and
    comments raised across the set of reviewers.

    When we elevate a document to standard we are saying that it represents a fully baked idea that has no
    significant defects. The question given the level of comments is does this meet that bar?

    
I don’t think many of these changes can be done and still advance it to Internet Standard. If we can’t advance the current document, then the w.g. may want to just do the errata and withdraw the advancement request.  Of course, if people want to work on a revision of IPv6 Path MTU Discovery, it would be welcomed, but it won’t be able to advanced to Internet Standard.
    Given the level of discussion, I would think that the WG should seriously consider a revised version clearing
    up the full set of issues raised in discussion.

    Responses in line

    Best Regards

    Stewart

    
Comments below.

Thanks,
Bob



    On Feb 9, 2017, at 7:19 AM, Stewart Bryant <stewart@g3ysx.org.uk> wrote:

Reviewer: Stewart Bryant
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6man-rfc1981bis-04
Reviewer: Stewart Bryant
Review Date: 9/Feb/2017
IETF LC End Date: 1/Mar/2017
IESG Telechat date: unknown

Summary: This draft is on the right track but has open issues,
described in the review.

This review together with the lengthy discussion on the IETF list
suggest that this draft has a number of issues that need to be
addressed  before publication.

I wonder if we would best serve both our future and our heritage
if we declared RFC1981 as historic, and either left the idea there,
or declared it as historic and wrote a new text from a clean start?



    I think this was closed in the email thread.
    OK
    


    Major issues:

Nits points out a number of faults with the document, but the only
one of substance is:

The text has a lot of RFC2119 language, but no RFC2119 declaration.

The document could use a thorough RFC2119 scrub

    Based on in an earlier another review, our AD suggested an update to Shepard Writeup instead of adding something to the document.  It says:

   This document is an update to RFC1981 that was published prior to
   RFC2119 being published.  Consequently while it does use "should/must"
   style language in upper and lower case, the document does not cite the
   RFC2119 definitions.  Since the changes in this update were very
   limited, the w.g. concluded to not change any of this language.
    This is really an IESG decision. 

    

    The document lists the three original authors one with an affiliation

change, but no email addresses. Has this been agreed with the
original
authors, and have arrangements been put in place for the RFC editor
to process auth48?

    I contacted the original authors and they didn’t express any interest in being involved in this update.  They haven’t participated in the IETF for many years.  I can contact them during AUTH48, or the AD can override this requirement for this document.

    So long as you have an arrangement in place that is acceptable to the RFC Editor and IESG.

    
      
    
        
    It is concerning that the draft does not talk in any detail about
how modern ECMP works, i.e. using the five tuple, and noting that
the PMTU may be different depending on the transport layer port
numbers.


    
      
    
      
    I think this is out of scope.
    
    
    
    
    
    So long as PMTU is bound to the five tuple (which I think it is),
    then the mechanism works, but given the
    
    prevalence of ECMP (pretty much every packet going across the core
    will be sujected to it) I don't think
    
    I agree that a discussion is out of scope. 
    
    
    
    
    
      
    


    
      
    
        
    Given that a very large fraction of packets will traverse an MPLS
network at some point, I am surprised that there is no text talking
about the importance of providing support for this feature in the
MPLS domain. RFC3988 talks to this point, but is only experimental.


    
      
    
      
    I think this was closed in the email thread.
    
    
    
    
    
    It was ruled out of scope on the basis that tunnel were out of
    scope, but this tunnel type does need
    
    some special consideration, particularly as nearly every packet
    crossing the Internet goes across
    
    this tunnel type a number of times in its passage.
    
    
    
    For me it is ore a question of providing the best advice to the
      reader, rather than minimising change.
    
      
    
        
    
    
      
    

    
      
    
        
    ======

  If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
  could use the flow id as the local representation of a path.
Packets
  sent to a particular destination but belonging to different flows
may
  use different paths, with the choice of path depending on the flow
  id.  This approach will result in the use of optimally sized
packets
  on a per-flow basis, providing finer granularity than PMTU values
  maintained on a per-destination basis.

SB> How widely is flow-id supported in networks? I thought that the
SB> current position was that it was unreliable as an ECMP indicator
SB> and thus routers tended to glean information from the packet
themselves.

    
      
    
      
    I think this was closed in the email thread.


    
      
    
        
    ======

     Note: if the original packet contained a Routing header, the
     Routing header should be used to determine the location of the
     destination address within the original packet.  If Segments
Left
     is equal to zero, the destination address is in the Destination
     Address field in the IPv6 header.  If Segments Left is greater
     than zero, the destination address is the last address
     (Address[n]) in the Routing header.

SB> So this has the effect that a traffic engineered packet and
SB> a non-traffic engineered packet will have the lower of the
SB> two PMTUs. This was all harmless when source routing was a
curiosity
SB> as far as mainstream networking was concerned, but may be
SB> more of a problem as a result of the SPRING work.

    
      
    
      
    I think the onus is on SPRING to make sure it doesn’t break existing mechanisms.
    
    
    
    
    
    .. or really doesn't break them any more than they discussion on
    this draft suggests that they are
    
    already broken.
    
    
    
    
    
      
    

    
      
    
        
    =======


5.3.  Purging stale PMTU information

  Internetwork topology is dynamic; routes change over time.  While
the
  local representation of a path may remain constant, the actual
  path(s) in use may change.  Thus, PMTU information cached by a
node
  can become stale.

  If the stale PMTU value is too large, this will be discovered
almost
  immediately once a large enough packet is sent on the path.  No
such
  mechanism exists for realizing that a stale PMTU value is too
small,
  so an implementation should "age" cached values.  When a PMTU
value
  has not been decreased for a while (on the order of 10 minutes),
the
  PMTU estimate should be set to the MTU of the first-hop link, and
the
  packetization layers should be notified of the change.  This will
  cause the complete Path MTU Discovery process to take place again.

SB> Should that be an RFC2119 SHOULD?
SB> The impact of this advice is going to be a disruption to what
might
SB> be a critical service every 10 mins.
SB> Should there be some advice along the lines of noting the
SB> importance of service delivery as part of deciding whether to
SB> test for bigger PMTU vs improving efficiency?

=======


Minor issues:

  IPv6 defines a standard mechanism for a node to discover the
  PMTU of an arbitrary path.

SB> Do you mean "This document defines ....."? Otherwise this needs
SB> a reference.

    
      
    
      
    Will fix.


    
      
    
        
    =======

  An extension to Path MTU Discovery defined in this document can be
  found in [RFC4821].  It defines a method for Packetization Layer
Path
SB> Rather than have the reader figure out what "It" is, perhaps
SB> s/It/RFC4821/

    
      
    
      
    The w.g. noodled on this text for a long time.  I think the “it” is clear, but will change to RFC4821.



    
      
    
        
    =======


  Upon receipt of such a
  message, the source node reduces its assumed PMTU for the path
based
  on the MTU of the constricting hop as reported in the Packet Too
Big
  message.

SB> We should perhaps state up front that this procedure
SB> hunts for the worst case of the ECMP set associated with the
SB> ingress nodes PMTU classifier.

    
      
    
      
    I think getting into ECMP is out of scope for moving this to IS.
    
    
    
    
    
    Yes, but I don't think you should set elevation to standard above
    providing the best advice, which
    
    is what seems to be proposed here.
    
    
    
    
    
      
    


    
      
    
        
    =======

  If a node receives a Packet Too Big message reporting a next-hop
MTU
  that is less than the IPv6 minimum link MTU, it should discard it.

SB> Should that be an RFC2119 SHOULD?

    
      
    
      
    See note above.


    
      
    
        
    =======

5.2.  Storing PMTU information

  Ideally, a PMTU value should be associated with a specific path
  traversed by packets exchanged between the source and destination
  nodes.  However, in most cases a node will not have enough
  information to completely and accurately identify such a path.
  Rather, a node must associate a PMTU value with some local
  representation of a path.  It is left to the implementation to
select
  the local representation of a path.

SB> Is it worth noting the five tuple since that is how a lot of
SB> load balancers work?

    
      
    
      
    I think getting into ECMP is out of scope for moving this to IS.


    
      
    
        
    =======

  The set of paths in use to a
  particular destination is expected to be small, in many cases
  consisting of a single path.

SB> I am not sure that remains true in modern networks.

    
      
    
      
    Do we have any data on this?  I wonder if there will be much difference in the PMTU in this case.

    
    
    
    In a well managed network the point is probably moot since all paths
    should have the same PMTU except
    
    under error conditions, but the path set can be quite large, and
    certainly more that a single path.
    
    
    
    
    
      
    
      
    
        
    =======

  One approach to implementing PMTU aging is to associate a
timestamp
  field with a PMTU value.  This field is initialized to a
"reserved"
  value, indicating that the PMTU is equal to the MTU of the first
hop
  link.  Whenever the PMTU is decreased in response to a Packet Too
Big
  message, the timestamp is set to the current time.

  Once a minute, a timer-driven procedure runs through all cached
PMTU
  values, and for each PMTU whose timestamp is not "reserved" and is
  older than the timeout interval:

  -  The PMTU estimate is set to the MTU of the first hop link.

  -  The timestamp is set to the "reserved" value.

  -  Packetization layers using this path are notified of the
increase.


SB> Such detailed implementation advice is uncommon in modern RFCs. It
has
SB> the disadvantage of de-facto standardizing something that should
be left to
SB> the innovation of the implementer.

    
      
    
      
    Can you point to any harm this has caused?  It is very widely implemented.
    
    
    
    
    
    It tends to result in people treating the example complete with any
    artifacts as normative. Which gives
    
    implementors less scope for optimisation, and can result in
    restrictions beyond the true intent of the 
    
    WG.
    
    
    
    Now I am not sure if there is a problem here, but I think it is bad
    practise in general.
    
    
    
    
    
      
    

    
      
    
        
    =======

5.4.  TCP layer actions

SB> TCP implementations have moved on a lot since this section was
SB> written. Is this still current best practise?

=======

5.5.  Issues for other transport protocols

  Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed
to
  repacketize when doing a retransmission.

SB> How much TP4 is there going over IPv6? Doesn't this example
SB> show the IETF as not being in the modern age?

    
      
    
      
    
I have no information one way or another.  I have heard there is some TP4 on airplanes, may they will move it to IPv6 :-)
    
    
    
    It really depends on whether the goal is to elevate what was
    originally written or to provide best current
    
    advice.
    
    
    
    
    
      
    

    
      
    
        
    =======

Nits/editorial comments:

  upper layer         a protocol layer immediately above IPv6.
                      Examples are transport protocols such as TCP
and
                      UDP, control protocols such as ICMP, routing
                      protocols such as OSPF, and internet or lower-
                      layer protocols being "tunneled" over (i.e.,
                      encapsulated in) IPv6 such as IPX, AppleTalk,
or
                      IPv6 itself.

SB> Everything in the list above is in the well known list, except
SB> IPX, so technically it needs expansion. However it might be nice
SB> to use some modern example in common use.

    
      
    
      
    I will add a reference to IPX.  The best reference I have found to IPX is:

       Novell, Inc., "Advanced NetWare V2.1 Internetwork Packet Exchange
       Protocol (IPX) with Asynchronous Event Scheduler (AES)", October
       1986.

Please suggest something better.
    
    
    
    
    
    I stand by my original view that we should use modern examples and
    leave it to the IESG to
    
    decide which path they prefer.
    
    
    
    
    
      
    


    
      
    
        
    =======

  link                a communication facility or medium over which
                      nodes can communicate at the link layer, i.e.,
                      the layer immediately below IPv6.  Examples
are
                      Ethernets (simple or bridged); PPP links;
X.25,
                      Frame Relay, or ATM networks; and internet (or
                      higher) layer "tunnels", such as tunnels over
                      IPv4 or IPv6 itself.

SB> Technically X.25 needs a reference, since it is not "well known”

    
      
    
      
    Will add a reference, if you think it is necessary.


    
      
    
        
    =======

  path                the set of links traversed by a packet between
a
                      source node and a destination node.

SB> Is it a set of links, or a set of links and nodes?

    
      
    
      
    I think the current text is OK.


    
      
    
        
    ========

   the value of MMS_S, the "maximum send transport-message size".
SB> The modern convention is full-name(abbreviation)

    
      
    
      
    I don’t follow this.
    
    
    
    
    
    A really minor point. A RFC usually expresses this as 
    
    
       the maximum send transport-message size (MMS_S), but that is a house style thing.
    
    
    
    
    
    
    
    
    
    
    
      
    

    
      
    
        
    ========

  The Sun Network File System (NFS) uses a Remote Procedure Call
(RPC)
  protocol [RPC] that, when used over UDP, in many cases will
generate
  payloads that must be fragmented even for the first-hop link.
This
  might improve performance in certain cases, but it is known to
cause
  reliability and performance problems, especially when the client
and
  server are separated by routers.

SB> Perhaps this should point to RFC7530 (the current NFS Spec),
assuming
SB> the behaviour description is still correct.

    
      
    
      
    Will do.


    
      
    
        
    =========

  The former can be accomplished by associating a flag with the
path;
  when a packet is sent on a path with this flag set, the IP layer
does
  not send packets larger than the IPv6 minimum link MTU.

SB> We do not normally give this level of implementation advice

    
      
    
      
    I think it varies a lot.
    
    
    
    OK
    
    
    
    
    
      
    

    
      
    
        
    ========================




    
      
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

    
    
    
    
    
  


--------------D16124D1E89C620CFECE780A--


From nobody Mon Mar 20 15:44:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E693712940D for ; Mon, 20 Mar 2017 15:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 y2UWn8DsxcBQ for ; Mon, 20 Mar 2017 15:44:54 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CDD129406 for ; Mon, 20 Mar 2017 15:44:54 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id l7so38888876ioe.3 for ; Mon, 20 Mar 2017 15:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/pm6dBhh2yCUEQpn7iHuKJ8jECli6PI1CN96SJgS6jQ=; b=M3P8dSsNsjNdTIoPgg5lEcGN/8ejRK9/Q/NgN0Ck0+D//3KObuQUEryf4wWLkzr0F/ 5Sil1PSuSqjFrokIinWIYgKJKUWah5xYzUopw3UaDdlasO6K3cpEfeokGmP0FU2P149t XPyq8/ovVipWW0ZCJ1s8sNyipL4nmFa2FlDAmuO7F/bfGHE77cT4hkIY7pqIR8a73zXB bjNPd0pqSthtdCl5YoSDxw3SbQPw+yXM3sjUOHaZRmEFF6vohoi1e3rwQ1M8ptXZb06E JCYy/tjonFJ43suW7NjSy9o6n6GPsM/J5YozWOtb4Lvy4I4r1WBHoq+/P6Iml0Ugxn5a +49w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=/pm6dBhh2yCUEQpn7iHuKJ8jECli6PI1CN96SJgS6jQ=; b=uB8t/CD8nYRIsaGNagpbn4OjkJIAnASQquY4O7dF2UPrHQ8NWPhDWBYmQ0yFKr8HQv XYrzUMjKdOAGFG1CqUqimHQE7RN8UfnO5fhM6Z2qASM92eqtPVO/eDkSIlX4iVSPNhH1 l0opJY2ztyB55Nx1HqVGFgFaEVa15Jjd+7wBaR7Nar9WWG2K74VwSnUj9LQHXurt/C4I v3dMPHLg0OniepkJN/ITWp7rnNbB7kDSMTvD+dtApqB5Oiyxijuq0Q2t+X1zqAzDp2d5 5aCnbnyBL3DrDrvVvmuBQgjDZRSGIMQ0Dqs5HQdSlkYpiB02WSs4krcoEbyGCZ0rheHf uIfA==
X-Gm-Message-State: AFeK/H3TPqiG2pNF9Ulol6O/HlqsMRYp9HmLYGZ/pMkhnCtYvgltzi0aE2sbDVCrUmWipg==
X-Received: by 10.107.153.9 with SMTP id b9mr28837053ioe.200.1490049893535; Mon, 20 Mar 2017 15:44:53 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id b88sm5858800itd.21.2017.03.20.15.44.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 15:44:53 -0700 (PDT)
Subject: Re: Failure of AH
To: Michael Richardson , Christian Huitema 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk>    <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com>   <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <32305.1489937663@obiwan.sandelman.ca> <0e628656-f8b2-effb-9f93-2efe6b0ee4c5@gmail.com> <11502.1489948766@obiwan.sandelman.ca> <735862da-0e36-b36d-5f0f-0c25245c0f2a@huitema.net> <18061.1490019476@obiwan.sandelman.ca>
Cc: 6man WG 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Tue, 21 Mar 2017 11:44:55 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <18061.1490019476@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Mar 2017 22:44:56 -0000

On 21/03/2017 03:17, Michael Richardson wrote:
...
> So I'm just not worried about breaking AH.

That's well understood for today's AH. What bothers me is that
if we allowed en-route changes to headers now, without thinking this
aspect through, we might make any future AH-like authentication
mechanism impossible too. So at a minimum, we'd have to be sure
that inserted, modifiable and deletable headers are marked in some
way that will allow them to be excluded from authentication. That
was thought about years ago for IPv6 options, but not for extension
headers.

    Brian


From nobody Tue Mar 21 07:57:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584241299D3 for ; Tue, 21 Mar 2017 07:57:17 -0700 (PDT)
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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6HJXH7o8effK for ; Tue, 21 Mar 2017 07:57:16 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D961299BB for ; Tue, 21 Mar 2017 07:57:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6D70220183 for ; Tue, 21 Mar 2017 11:20:40 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 44AFE636BB for ; Tue, 21 Mar 2017 10:57:13 -0400 (EDT)
From: Michael Richardson 
To: 6man WG 
Subject: Re: Failure of AH
In-Reply-To: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk>    <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com>   <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com> <32305.1489937663@obiwan.sandelman.ca> <0e628656-f8b2-effb-9f93-2efe6b0ee4c5@gmail.com> <11502.1489948766@obiwan.sandelman.ca> <735862da-0e36-b36d-5f0f-0c25245c0f2a@huitema.net> <18061.1490019476@obiwan.sandelman.ca> 
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Mar 2017 14:57:17 -0000

--=-=-=
Content-Type: text/plain


Brian E Carpenter  wrote:
    > On 21/03/2017 03:17, Michael Richardson wrote: ...
    >> So I'm just not worried about breaking AH.

    > That's well understood for today's AH. What bothers me is that if we
    > allowed en-route changes to headers now, without thinking this aspect
    > through, we might make any future AH-like authentication mechanism
    > impossible too. So at a minimum, we'd have to be sure that inserted,
    > modifiable and deletable headers are marked in some way that will allow
    > them to be excluded from authentication. That was thought about years
    > ago for IPv6 options, but not for extension headers.

a) AH was invented in the early 1990s, and was a response to the realization
   that we might not get a cryptographic system out of the US that included
   encryption.

b) it has never been useful for authenticating IPv6 headers.  The one time
   that we got close was SEND, and we specified the "unknown SPI" behaviour
   wrong so we couldn't do SEND as AH+ICMP unless we had a flag day.

c) I would claim that the headers that would most benefit from being
   authenticated would ones inserted mid-path :-)
   That argues actually for IPIP encapsulation of those headers so that
   the trust anchor is the IPv6 src address. (but, AH SPI# are allocated by
   destinations, not senders, so AH is also wrong for that)

   But, we have inadequately documented IPIP header decapsulation by end
   hosts, explaining that they should ignore AH (or AHng) headers that they
   do not understand.

d) does 7045 even give us enough power to create AHng?  I didn't read it
   that way.

I'm just not convinced that "breaks IPsec" is a valid concern.
(And I weep saying this)


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljRP0gACgkQgItw+93Q
3WV9+wgAjrvDn3kchecWiKJSMhnPeqBppbZ8CwLfCrRvLylsFJA2YJBBjqcugdPQ
GKVrjBAqVs1+q/OVuKTf27ZQER+wMSsCAiIA/+Yjq1o4LByN8uQyO0b792PLqozN
ETkQSG78K/hNOzzy4I9rfOpdbpmIuLZa5KWeXF6rXzaqDVvB6tukA5ZlLzOWY7ml
XiHtqfNDV3EGOj6+NVXgix8iqkySbuvwJf66lScRlUT4XSnAiFXbLAA+BPQgCzKl
nFMW3Hw8b/az0nNnPIkAQV8BPYHHiOxSHu60+NtZ42r/Kz4jIcz1VcWNdRBM/cyq
lMLbykQX+0YbWeW9sSInWNYT6a4a3A==
=h5O6
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Mar 21 14:16:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6430212951E for ; Tue, 21 Mar 2017 14:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IO6NOJX4rTOK for ; Tue, 21 Mar 2017 14:16:25 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F7E129B60 for ; Tue, 21 Mar 2017 14:16:24 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id w124so15686988itb.1 for ; Tue, 21 Mar 2017 14:16:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=72MVFhIFQaQc3jtgFmHOnT+DU+zOrzFVHF/3k2bpXWk=; b=NqL2Q0k4Mc/P2TDalYofw6lipXcC/SBiMOVHCQpU6/ynoyGhVjYo6/hNa7R4PrDusr 5h5w7Shvcoi3d/9XEjVZqFsv4tQVEGdD/3rJD74D513Pb1WghYEeAC6mXE0qlBaZP981 Ur9G1/n4hPqLuo6axLvPvn58V2A1AJhl25KozK/qmKPsAL1PKl8xeVoVSbKQFZySUQJp eA0AUE85LYe7pjM999MjcbMJ5/NSQ22xyvKTfIhk43RqaJFUvYsd/z6C1nl9WekZR5Mn fhiPXNQ6+mk8K+NNukzmZ61SJiyv+bY5YY02aufJucJaqnVXCtIjykA6LbpyTQgepExj u1uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=72MVFhIFQaQc3jtgFmHOnT+DU+zOrzFVHF/3k2bpXWk=; b=euSZUdzp/lZmgvA3yEqWy6+4edHuv+rO0RYNNJYkz1LzhANV+eqJP11T9EGamiu2Sn 60Snd1ymc0kmH/HVa3jBir3FR29lukzW+NWVtnzAFUJ3+sUJY3iGZPChFZLgfmH//ulA Txa/bn2pVUY0pdKinyAWD+Fpi8FCa1eEPisbPf3xQ2L6TqLc+YXBiID23C+4GCuY5PoE 5H7QQKWtkPlwLC+75T+G0keXm6Dy7YevTHRCNYkRLwNWg5dj5eRY1U47oq7IPkfhSuYa Qpgqa+nil3GxOXx6d4MBjoQzC41uelAZDThXH7UkrJfZC2Xfn52rNXUHUa+/ISY0QzMO uBuA==
X-Gm-Message-State: AFeK/H3WI/0wkFGRkOz6vm1csz6wFQMv2WPcyAw1Hex2T7TbXvfqKqKI3kXvTXfLSZWAdQ==
X-Received: by 10.36.108.5 with SMTP id w5mr4572087itb.116.1490130984200; Tue, 21 Mar 2017 14:16:24 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id b88sm7333243itd.21.2017.03.21.14.16.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 14:16:23 -0700 (PDT)
Subject: Re: Fwd: New Version Notification for draft-clw-rfc6434-bis-01.txt
To: Timothy Winters , 6man WG 
References: <148943650492.20338.10199609342471625076.idtracker@ietfa.amsl.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Wed, 22 Mar 2017 10:16:27 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Mar 2017 21:16:27 -0000

Hi,

Thanks, this is going in the right direction.

I'd like to suggest adding https://tools.ietf.org/html/rfc8028
which has impact on both router and host implementations.

Regards
   Brian

On 14/03/2017 09:33, Timothy Winters wrote:
> Hi 6MAN,
> 
> There is a new version of IPv6 Node Requirements available.  This version
> includes RFC updates, removal of out of date RFCs, and requested changes
> from last time.
> 
> There are still several areas where there needs to be more discussion which
> we plan on having in Chicago, but feel free to send comments.
> 
> ~Tim
> ---------- Forwarded message ----------
> From: 
> Date: Mon, Mar 13, 2017 at 4:21 PM
> Subject: New Version Notification for draft-clw-rfc6434-bis-01.txt
> To: Tim Chown , Timothy Winters ,
> John Loughney 
> 
> 
> 
> A new version of I-D, draft-clw-rfc6434-bis-01.txt
> has been successfully submitted by Tim Winters and posted to the
> IETF repository.
> 
> Name:           draft-clw-rfc6434-bis
> Revision:       01
> Title:          IPv6 Node Requirements
> Document date:  2017-03-13
> Group:          Individual Submission
> Pages:          34
> URL:            https://www.ietf.org/internet-drafts/draft-clw-rfc6434-bis-0
> 1.txt
> Status:         https://datatracker.ietf.org/doc/draft-clw-rfc6434-bis/
> Htmlized:       https://tools.ietf.org/html/draft-clw-rfc6434-bis-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-clw-rfc6434-bis-01
> 
> Abstract:
>    This document defines requirements for IPv6 nodes.  It is expected
>    that IPv6 will be deployed in a wide range of devices and situations.
>    Specifying the requirements for IPv6 nodes allows IPv6 to function
>    well and interoperate in a large number of situations and
>    deployments.
> 
>    This document obsoletes RFC 6434, and in turn RFC 4294.
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Tue Mar 21 14:22:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C757412951D for ; Tue, 21 Mar 2017 14:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7B-oQSbwdqms for ; Tue, 21 Mar 2017 14:22:30 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E4B127342 for ; Tue, 21 Mar 2017 14:22:29 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id f84so56171529ioj.0 for ; Tue, 21 Mar 2017 14:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=0QRiR2lSRe+cyWBl/OES8WfZbG66dvBAZAQKF95nT0E=; b=YlQ7VJXsgA+G9zZ5/iTZaW09aNQs4TkxmMjJsiXTLoi01vXUUdahu8c6ihOgFJkYhK G6B7DgHnalNpVv0ZxFLel+9/lFvmBloVbLCZtL+d1Zsr/54fFiawU3OgPxpFavRPAsd0 ylz5RGr3PsQ02J43sBT3menoLlYj7UOYUc07ff/aaQitUmJ75d6V7q8CaFP3cdRIyAZl coN6YUncjToC5Et9zVBP9Z0DEbi6cvkdkiZpy1+7aA1v2fRWWRaKXKagNW5bwoYUb1v9 UUbCuXMq4ZgTIWIGptgdapd08GWKlDJSmrCQwThl3Xzy+XFIek53qvgI/ySsMJUwIUJ+ xZ6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=0QRiR2lSRe+cyWBl/OES8WfZbG66dvBAZAQKF95nT0E=; b=ZP9jrqIrdqRUndlmNTKJVjDSMcryr2Sj/Kucy/xhRaXtLSx6+1jKZiiddHdCfHNG0X XAO+OntOSay3l3924YMFtnTccafnMc+GYPDsdKZPvOlbPsT4sNL7DLkSQH0htFrXsqTU Ed+2pj3AW++UBS1A66Pj6pPX6bshKDXhBtID5UaP2qBtQJWh+c8Qbx2MAhUKDHubxhz1 seIce0rVaozK3lIWThY7pACeaNZmPVDTHvjdhL2H7qhO3ytgNl6nXy9/yc8jJRjqXE6R pC4tD9yricL9nIUuw6yhRpk/6zHNJ0Qh85Cu/Mvt+y6ykCwxROxRpU79s8Jf81RD9mdM KWZA==
X-Gm-Message-State: AFeK/H2UhzcXd7Y1bqouikY/DJd1CDwrOhVBzqkcVo72gZ+3q9abTcZwWkKNcJMCJ0Sg3Q==
X-Received: by 10.107.156.200 with SMTP id f191mr27347768ioe.9.1490131349019;  Tue, 21 Mar 2017 14:22:29 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id z204sm10674149iod.3.2017.03.21.14.22.27 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 14:22:28 -0700 (PDT)
Subject: Re: I-D Action: draft-jinmei-6man-prefix-clarify-00.txt
To: 6man 
References: <148943819693.20381.7869390660906713129@ietfa.amsl.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Wed, 22 Mar 2017 10:22:32 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <148943819693.20381.7869390660906713129@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Mar 2017 21:22:32 -0000

Hi,

I like this draft.

I suggest mentioning https://tools.ietf.org/html/rfc8028 which
describes a valid use of PIO with both L and A flags set to zero.
This underlines the point that they are logically independent of each
other.

Regards
   Brian


From nobody Wed Mar 22 10:50:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4E21294DA for ; Wed, 22 Mar 2017 10:50:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.402
X-Spam-Level: 
X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6T8K8xwpX_qZ for ; Wed, 22 Mar 2017 10:50:16 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFEC1296DE for ; Wed, 22 Mar 2017 10:50:14 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id v127so162542669qkb.2 for ; Wed, 22 Mar 2017 10:50:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WHWBIcuiOJQUNYrqxzvMurBcLsUpSJwqbXQtjQZGprQ=; b=MJYT/BRHqxmRkKLOPvTdzsmXkDGKOJW1k+j9S5XKf5+v4bwy8poFS6bvH2LE5l+NKZ E2Q2r8ezyzNKV2tVDJsXKFDhO/pOCu8L2lreuDFr1l8cJHngKY9lKz2nbndjau9Cl+Sf aa/6NgA7XbSdaJuZRPj7GWQLE71m0qo15t25gD82y1n3DB6FPW+HsJKPkSUB4ULTpdNU nJz8moD1ImF4Es3pCiVmE8VVfuOe15FhPWtfJ/+0JcDrugxvZYGtYCIdqPHbRbpgdsIQ M7BhKGVy2nDhf7jTEBC7XbGk9YE/ZI7h1JcyRqCUQytT7mHRY3UBVu7IbJkzeVqnlsv1 CmHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WHWBIcuiOJQUNYrqxzvMurBcLsUpSJwqbXQtjQZGprQ=; b=tNpHZBC72wpDyPy8N/ccfcCSC9K0ofG52AXkjYA4IYkD6Mp6YF8DvXqLn0TiehLXjs z58THaUdmEL35WvEyLsJH7prgBqBEhGBG4Q9sAANjDXE/IjB+gM8NGShu6m/BGPYgehO Bk+yGl2EixI77yVJzu7D1jlIz0j6fUqscLtw/Yz/H79FCfHNjJgoW5+RF1wrd38i5TlQ TSsmiYSYurphxFzBtdJcoKdWoQgrHlkWzQOa6+WsuuRV0l/5aHD83uHebtvHeEPIJ7pi 4xAV0vSh3d0NRB1tLJHQ2g0Vu3ix/mQIsJFaH68az3/zN+BVA1+B4kV0z5c/pSgs9E/F 53AQ==
X-Gm-Message-State: AFeK/H3XU6JYYdleDzZLnQrHOjltdxn+hGTlGldMUAGbN965RsmQWBHMj1NCJYJpbAwS/Zke2iDSBrji/BwjNA==
X-Received: by 10.55.112.66 with SMTP id l63mr36998622qkc.149.1490205013145; Wed, 22 Mar 2017 10:50:13 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Wed, 22 Mar 2017 10:50:12 -0700 (PDT)
In-Reply-To: 
References: <148943819693.20381.7869390660906713129@ietfa.amsl.com> 
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Wed, 22 Mar 2017 10:50:12 -0700
X-Google-Sender-Auth: vA-YRBBZxB_iVKToa7-F3ERE4UQ
Message-ID: 
Subject: Re: I-D Action: draft-jinmei-6man-prefix-clarify-00.txt
To: Brian E Carpenter 
Cc: 6man 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Mar 2017 17:50:18 -0000

At Wed, 22 Mar 2017 10:22:32 +1300,
Brian E Carpenter  wrote:

> I like this draft.
>
> I suggest mentioning https://tools.ietf.org/html/rfc8028 which
> describes a valid use of PIO with both L and A flags set to zero.
> This underlines the point that they are logically independent of each
> other.

Thanks for the feedback.  I'd note a prefix in PIA with both L and A
cleared is technically not in the scope of the draft (it's neither an
"on-link" nor "SLAAC subnet" prefix), but I see its relevance in terms
of how PIOs should be validated.  Right now I don't have a strong need
for revising the draft, but in case I update it I've added a note
about it to the local source of the document.

--
JINMEI, Tatuya


From nobody Thu Mar 23 10:20:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC18312995F for ; Thu, 23 Mar 2017 10:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zV-j8lPC7MZM for ; Thu, 23 Mar 2017 10:20:18 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A8B129970 for ; Thu, 23 Mar 2017 10:20:18 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id p22so46453689qka.3 for ; Thu, 23 Mar 2017 10:20:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=H/L/+xJNj18ShnK7w8u+JvFDXNFthH/lubS/5tJ3z0Y=; b=F7CXUxEC2Prbnz9A+RoSQ5dMAe9duCAZNIZ24zr+P6ruDtA0cIgray+NHUM8RkOscU Bef4b8EdhA5vLeN/DnELfYhx+I/MM6mhJvHqLf4DU4f93vAET6QBy8wKoikSrgb2RpOT itbd4GLpS9E4dGnHkGtHIHAL9o9oz2g87LLUCmnak+6NUqoQxpOuZ2DX9ozCjOZTzJzO clznYm+in44LDqxo3vk5xsbD9Xn1HPa8A3QVu21jSeMotCOn1n8sqSq6oUcjzftp9Ph8 yKhnGfh6QYjmuZ4RlbQrgAYUA3SuMAeRNITHCWRi5PECBNXnL22f5U2Wl2rWtR6eMPHt 5XRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=H/L/+xJNj18ShnK7w8u+JvFDXNFthH/lubS/5tJ3z0Y=; b=smoeKqtNrtS31+kNzgsmL9sjaVCE32ltVz2lkMidVOxaiaWJnqe+eJetSWweZT/21+ RLlBFpTFBPvu26xHBzWO9AoS5nvda+B3IFTQX6+BnO+TcjYCfia8AGkfVs6szdGcDMbY GXx5agGZsn1NR51jaDFaCMcb8ST+80GUBVLJ06MWg05woOJV4qtBKvcMOS8Q+60Ey99B MJhFB4B29Ts3mGuHOyG5fTHunBHnbEHoUUemyPna+fhl3vkYrPc15pTKlgnSDjEzdnKa gLgDhH0MfWxKGCTVF6xDK7Y9dkR55B88aDCksm8vE7mPt3eQ0k216ZsC01v8OPRSbZDX tcig==
X-Gm-Message-State: AFeK/H1dOa8zjU9eSmlB2lHlv0+PaIL+5Ja6i0L/KMUTphbA+vvpii3YYIKhTI8R4g0doBy6oMZN7ztrFioYNg==
X-Received: by 10.55.60.137 with SMTP id j131mr3009663qka.19.1490289617157; Thu, 23 Mar 2017 10:20:17 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Thu, 23 Mar 2017 10:20:16 -0700 (PDT)
In-Reply-To: <589AE235.6080808@inria.fr>
References: <589AE235.6080808@inria.fr>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Thu, 23 Mar 2017 10:20:16 -0700
X-Google-Sender-Auth: 1lsABSu54axv0Lf9onXjsJaRp4s
Message-ID: 
Subject: Re: Feedback on the use of Hop-by-Hop options extension header (draft-francois-dots-ipv6-signal-option-01)
To: =?UTF-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= 
Cc: IPv6 List 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Mar 2017 17:20:21 -0000

On Wed, Feb 8, 2017 at 1:17 AM, J=C3=A9r=C3=B4me Fran=C3=A7ois  wrote

> We are working on a DOTS draft about using the Hop-by-Hop option header
> to encapsulated DDoS signaling  within network to enabel a kind of
> epidemic propagation
> (https://tools.ietf.org/html/draft-francois-dots-ipv6-signal-option-01)
[...]
> We have also followed the mailing list discussion about header insertion,
> which obviously concerns our approach since we are extracting and inserti=
ng
> some info in headers on the paths. Even if this is is limited to specific
> routers in a single domain, we understand that it can create problems and
> should maybe use packet encapsulation.

I've just (quickly) read the 01 version.  Regarding the header
insertion, I think the conclusion has now been made in the context of
rfc2460bis, but that aside, it was not really clear to me from the
draft text that it intends to allow an intermediate node (=3D DOTS
opportunistic-capable router?) to insert a new Hop-by-hop option.  If
you're going to avoid insertion as a result of the decision on
rfc2460bis, that will be moot anyway.  But if you plan to keep it
(possibly as post-rfc2460bis fodder), I think the draft text should be
much clearer on the intent.

Some other comments:

- I suspect this use of Hop-by-hop options header could be considered
  a layer violation; my general understanding is that HbH options are
  intended to be used at around layer 3, but the proposed use seems to
  belong to a much higher layer.  I'm not a layer-boundary-police
  officer, so I personally wouldn't be opposed to the idea just
  because of that, but I can easily imagine some of those officers
  will complain about it.

- (a minor point) in section 1.2 the draft states:

   an application layer (DNS) attack [rootops-ddos]. Each one of the 13
   root server letters (A--M) was hit by attacks peaking at 5 million
   queries per second.

  This could be misleading.  Root DNS servers are highly distributed
  using anycast today, and there are actual several hundreds server
  instances.  And in that sense "each one of the 13 letters" is
  ambiguous: whether it's each *one set of servers* of each of the 13
  letters, or it's each instance of hundreds of actual servers.
  Actually the referenced document ([rootops-ddos]) is also ambiguous,
  so it's not really a fault of this draft, but it's still better to
  be clarified or to find another clearer example.

- Section 5:

   [...] At DOTS capable
   nodes (client, gateway and server), it requires a service interface
   used by upper-layer protocols and application programs to ask the IP
   layer to insert and listen to the Hop-by-Hop header option in IPv6
   packets with the content and strategies described in Section 3. A
   DOTS client invokes the service interface to insert the option, A
   DOTS gateway invokes the service interface for listening and
   inserting the option, and finally a DOTS server only invokes the
   service interface to listen to the DOTS signalling option.

  At least for the actual source and destination nodes of the packets,
  I believe the advanced socket API (RFC3542) could be used for this
  purpose (unfortunately, though, it's not as widely implemented as
  the basic API).  You may want to refer to RFC3542 here.

--
JINMEI, Tatuya


From pim@hosted.ipng.nl  Fri Mar 24 06:02:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643A212441E for ; Fri, 24 Mar 2017 06:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hosted.ipng.nl header.b=gJXCFJ+C; dkim=pass (1024-bit key) header.d=ipng.nl header.b=l/9VmklX
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 euHmGCz7oG2B for ; Fri, 24 Mar 2017 06:02:28 -0700 (PDT)
Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C634712967E for ; Fri, 24 Mar 2017 06:02:28 -0700 (PDT)
Received: by mail-ot0-x22b.google.com with SMTP id a12so1150612ota.0 for ; Fri, 24 Mar 2017 06:02:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hosted.ipng.nl; s=google; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=VU4U/Km7CU1sL9sZjIIhv0pL/SacAuR74leSEHvKmkI=; b=gJXCFJ+C7tgnMnEauKaF7yaBdN7iMWoJkQuTgmM1q7Tcg9NvoqiC0OZwM0c1jucoNw +5mzNrXMTJGb+rJm/DvWPsvLsR5CzB0xo7ktfcbRUuOPOCOGBA4lLGHYDbYY24GjzIPX j6XNTh8BHdZvB/3gQxCb5rzLjxKmTITSct9A4=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipng.nl; s=google; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=VU4U/Km7CU1sL9sZjIIhv0pL/SacAuR74leSEHvKmkI=; b=l/9VmklXovWtxSB0MZ03LG/tVUnHOo3mSCuIb7818LEC4fys0lxN/847y58GdboaqP 6YpOeWGNoP6wwa+H/NUjTUEfR7NlPbqjpnR7fTetzwe6qRuG8FIxULPuwoLMfp3kCfXB L1/MjHUomatCIjeEWIjIXDnGcpSm8Z3PSnauk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-transfer-encoding; bh=VU4U/Km7CU1sL9sZjIIhv0pL/SacAuR74leSEHvKmkI=; b=qib1IsKU4RxEmdV2BzrTcEFNMTQNWXv4sWnUg7otH1wbsjgkdc1VxmdVOcy/AOWP9E buxz4hbfDcTWEDqHRdQNOVKtZZa0PPaB5Gq/rekl1yng7AVcE1iR5CVigqBeIXKu845y XBBBsKhKnFgjPWZIfTyrdX9yegsIjutRggrWr/0Xkcy8MvgaRFlOfV1ntMe7Eu8G7Vx/ Uq3JUxGcPMFOGGJv9AEMTACQs8w+/TTlSDh2sMRUPMXI5knmEJkKEb6aXBliCv+ScYUF YcGry4NRKh7LCtO0LkunlIPsn31SdklerEI0qmujO0D8AD7vOn25RY9wVfaz5iWQMUmr SNIw==
X-Gm-Message-State: AFeK/H2HEVPJRkepKG/ZpDAP93kRVdL/2cw/0o1bhCEmZE6EMUKOu2lBxXsnN/VdcDDKeIBJB/9roLj2FwCdUg==
X-Received: by 10.157.2.38 with SMTP id 35mr4978661otb.118.1490360547926; Fri, 24 Mar 2017 06:02:27 -0700 (PDT)
MIME-Version: 1.0
Sender: pim@hosted.ipng.nl
Received: by 10.202.105.209 with HTTP; Fri, 24 Mar 2017 06:02:27 -0700 (PDT)
From: Pim van Pelt 
Date: Fri, 24 Mar 2017 14:02:27 +0100
X-Google-Sender-Auth: xlUzGwtSwh-uEb3bIFZFMIWXYS4
Message-ID: 
Subject: IETF: SixXS is shutting down
To: ipv6@ietf.org, SixXS Staff 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-Mailman-Approved-At: Fri, 24 Mar 2017 06:08:47 -0700
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 13:04:13 -0000

Colleagues,

In 1999, Jeroen and I started SixXS, a project which aimed to provide
IPv6 connectivity to users who wanted to learn about the network
protocol and gain experience operating IPv6 networks. Our vision was
to facilitate migration to IPv6 in content and access providers.

We were able to provide IPv6 to 50=E2=80=99000+ individual users and compan=
ies
in 140+ countries, using servers hosted at 40+ Internet providers in
30+ countries. We are incredibly proud of what we=E2=80=99ve accomplished
together, and how many people have gotten to know all about IPv6 due
to our combined efforts.

We have completed a retrospective and rationale document, which
details our experience developing and operating the SixXS tunnelbroker
over the last 18 years. We have worked through our plans with the many
dedicated ISPs that have been involved:

https://www.sixxs.net/sunset/

We have reached out to users recently, giving them 6 weeks to make
alternative plans. We have chosen a somewhat symbolic date of
2017-06-06 to turn down the SixXS service. Our website will remain as
a tombstone.

Please feel free to pass this along to any group or list you feel
would benefit from it, and reach out to  or to myself
directly  if you have thoughts you=E2=80=99d like to share
between now and then.

--=20
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/


From nobody Fri Mar 24 07:05:37 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DFB1293F9 for ; Fri, 24 Mar 2017 07:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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_zbbP2PHsJH for ; Fri, 24 Mar 2017 07:05:34 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38135127201 for ; Fri, 24 Mar 2017 07:05:34 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2OE5Wg4017615 for ; Fri, 24 Mar 2017 15:05:32 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 44DDF20705D for ; Fri, 24 Mar 2017 15:05: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 3AF3E206F76 for ; Fri, 24 Mar 2017 15:05:32 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2OE5V0e028233 for ; Fri, 24 Mar 2017 15:05:32 +0100
Subject: Re: IETF: SixXS is shutting down
To: ipv6@ietf.org
References: 
From: Alexandre Petrescu 
Message-ID: <8350d58a-00b1-3561-c842-422703a22be7@gmail.com>
Date: Fri, 24 Mar 2017 15:05:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 14:05:36 -0000

Le 24/03/2017 à 14:02, Pim van Pelt a écrit :
> Colleagues,
>
> In 1999, Jeroen and I started SixXS, a project which aimed to
> provide IPv6 connectivity to users who wanted to learn about the
> network protocol and gain experience operating IPv6 networks. Our
> vision was to facilitate migration to IPv6 in content and access
> providers.
>
> We were able to provide IPv6 to 50’000+ individual users and
> companies in 140+ countries, using servers hosted at 40+ Internet
> providers in 30+ countries. We are incredibly proud of what we’ve
> accomplished together, and how many people have gotten to know all
> about IPv6 due to our combined efforts.

Congratulations for past achievements!

> We have completed a retrospective and rationale document, which
> details our experience developing and operating the SixXS
> tunnelbroker

Tunnelbroker ok, but how about ULA generation and registration at sixxs. 
  Is it shut down tombstone too?
https://www.sixxs.net/tools/grh/ula/

And what happens to the registrations?

> over the last 18 years.

Some local calls it "in their youth" :-)

Alex

> We have worked through our plans with the many dedicated ISPs that
> have been involved:
>
> https://www.sixxs.net/sunset/
>
> We have reached out to users recently, giving them 6 weeks to make
> alternative plans. We have chosen a somewhat symbolic date of
> 2017-06-06 to turn down the SixXS service. Our website will remain
> as a tombstone.

>
> Please feel free to pass this along to any group or list you feel
> would benefit from it, and reach out to  or to
> myself directly  if you have thoughts you’d like to
> share between now and then.
>


From nobody Fri Mar 24 07:14:25 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0B91296F5 for ; Fri, 24 Mar 2017 07:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hosted.ipng.nl header.b=Z6D5GlX6; dkim=pass (1024-bit key) header.d=ipng.nl header.b=VgksrmhZ
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 6He0DWBDvjHe for ; Fri, 24 Mar 2017 07:14:21 -0700 (PDT)
Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6217128C82 for ; Fri, 24 Mar 2017 07:14:21 -0700 (PDT)
Received: by mail-ot0-x22c.google.com with SMTP id a5so2465762oth.1 for ; Fri, 24 Mar 2017 07:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hosted.ipng.nl; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qAfCAelihHecwJSFsW/wBUNY8FeNnb+gBAUOddIth0o=; b=Z6D5GlX6vPydyHBirMn5f1YcUGt16+ALu47beu+4zfK7EI0Oqx5Eg42HjtVxRpEAlW qfs0uTC0EcHsy+/JSL11V4CKwkZEbiGeoJDtVhS4G/8WgFkdin37taFv/hskClAsv7W3 B3yvmgE0K/f65tM763N4EdZljiX4l4EJGgF9k=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipng.nl; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qAfCAelihHecwJSFsW/wBUNY8FeNnb+gBAUOddIth0o=; b=VgksrmhZCJIR8lwx8KgRls2B2Z77HT4yYDUmK+IY8S79PamSLNEfo5L6ZC4xniKUoY JEbjRbiUJzBrAYisN5HV6iN3YAFVThsjQGbelxpPUo9avSsok8Wo/UYLQ2BKSAddlnRj tB8W2PjCEKh9yWwMx2T4Bfra30oWkmQtxLQ38=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qAfCAelihHecwJSFsW/wBUNY8FeNnb+gBAUOddIth0o=; b=Fe8HijMUUduwV0bupLVZ3JJMGDO2PrBrGZBGaiWjL4RuBOMSNMXeUFFgdbfownGNlA NL2FNN82/4bIoQg5ssth/BwCKjzD7mXch92VQPuT8QkgFIivTtKJQ8QQHdf96SNGv15I gu+eBzPAVCRIUfsaH1Q/00ORbdGthELoAzb06gyaBluyTdJS/suyA+peIdyLUzfLih5w dY9/OG29XT0nLba+3g5HcfHkGYb20rAD7FIkybv6H3f8UIqpXhk2Y2B01Gb9UMe+DPrS kLVEPOoh3BmnVVbF6naBQlM9Jo+5cyjjBzw/kWOA5pE+Y+H62zvIHYguCPblD+lBYSBD ikEw==
X-Gm-Message-State: AFeK/H38/XDIHb/7QLscruU1EbFJy0EMDj9vKbdgQ6VbxG7jfWduOkNODEOkgCN1JM9EnRHvQ2ruUY1wF6IPgA==
X-Received: by 10.157.2.38 with SMTP id 35mr5181213otb.118.1490364861115; Fri, 24 Mar 2017 07:14:21 -0700 (PDT)
MIME-Version: 1.0
Sender: pim@hosted.ipng.nl
Received: by 10.202.105.209 with HTTP; Fri, 24 Mar 2017 07:14:20 -0700 (PDT)
In-Reply-To: <8350d58a-00b1-3561-c842-422703a22be7@gmail.com>
References:  <8350d58a-00b1-3561-c842-422703a22be7@gmail.com>
From: Pim van Pelt 
Date: Fri, 24 Mar 2017 15:14:20 +0100
X-Google-Sender-Auth: yd4RpOo7yEFpn6njXqar9DaZe8w
Message-ID: 
Subject: Re: IETF: SixXS is shutting down
To: Alexandre Petrescu 
Cc: ipv6@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 14:14:24 -0000

Hoi Alex,

On Fri, Mar 24, 2017 at 3:05 PM, Alexandre Petrescu
 wrote:
> Congratulations for past achievements!
Thank you.

> Tunnelbroker ok, but how about ULA generation and registration at sixxs.  Is
> it shut down tombstone too?
> https://www.sixxs.net/tools/grh/ula/
TL/DR: Plan of record is that it will cease to exist.

This registry was for educational purposes, and has no official
status. Importantly, as ULA is random per definition, the chance of
collisions is extremely low. It is fairly straight forward to get a
prefix from one of the RIRs. While that does cost some money, it is an
activity that is not the main charter of SixXS and will be expected to
continue with the RIRs.

> And what happens to the registrations?
Can't quite parse the question - so let me offer three answers (maybe
the answer you're looking for is among them):
Firstly, registrations (new users) has been closed since Q4'15, so we
haven't accepted new registrations since that time.
Secondly, in the lifetime of the project, we have taken privacy and
individually identifiable information very seriously, and to our
knowledge have never suffered an information breach or leek. After
decommissioning the services we run, we will destroy all PII data,
keeping only traffic statistics at the PoP level, and general
statistics of our usage, like the graphs seen in the posted sunset
rationale document.
Finally, the allocations we've received from LIRs (total used space is
about one /33 of assigned and active space, and upwards of a /30 of
allocated space), will be returned to the LIRs and all database
objects deleted.

Happy to discuss this or other things further as we near the lights-out date.

groet,
Pim



-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/


From nobody Fri Mar 24 08:24:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340A5129484 for ; Fri, 24 Mar 2017 08:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 Bn3e6qHnXKTG for ; Fri, 24 Mar 2017 08:24:17 -0700 (PDT)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959461293E0 for ; Fri, 24 Mar 2017 08:24:17 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id D9DCB836 for ; Fri, 24 Mar 2017 15:24:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5HyEzmBQi3U for ; Fri, 24 Mar 2017 10:24:16 -0500 (CDT)
Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 9A3457CD for ; Fri, 24 Mar 2017 10:24:16 -0500 (CDT)
Received: by mail-vk0-f71.google.com with SMTP id b202so5775012vka.7 for ; Fri, 24 Mar 2017 08:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=JO4EK7+yHin/+Iuz4yB5dkoyyDTSZxWz1Tsk71GoNEA=; b=mzUGItkjnidZCla2ihLpeQbTACjt0fQPc8YyHhB4ojTCrqHHkFKq2EjSiOwGLvAml5 e9dcMI4R9oAie92gGtCk91ONy3lRhWWYoSEhvPo2X6WRVgHCA4yZ52bjdZxjaOJ5AHLh 8Jb5nJUoTNIYU2HloqPULJ78+37blu4VsDiNbARKTIbP1RiLd8CmV77IJKGmlPRotcDO cv6l+8Kk8+pvG69FKNqPjRIoJeI9T/p7gV6bTN8jg9bM9Q5wkR6CTV+M6kBgGXzlZ0GE IoHSu4kpvZGhsAxZ6mr5AItADXE4uYbPIiZRmUpzdcQ5GeCoqYY8bOBO2RTRPJsH4EAD MFpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=JO4EK7+yHin/+Iuz4yB5dkoyyDTSZxWz1Tsk71GoNEA=; b=nDbXPn/mhlUhro6S0olZ61f6+AoyYmCSAXM6dPG0gDwtjxC7Z9C/VcLTFNePK6V0wh oW0Kw3etSpzTLw+HbExdeQ1cy0NKyrO7HH4AkaMUpYxXpffUmj5lJFlK4IojoN/KeycP p8Oy61D1EkYTe+jCkvgevFC26fnPGt/zCmDlFh2WH7UjRwFD+JT0pAQvdUi1j8v+kh5n gwA3JE4z4SYLaD+klC3mjTk8w2AcTgmQWO/tTJvd4adkhvmb61HhX/W1bNjtcz5ruVMz aSGKBP25T6gqKVQoNRH4I4U3oZAaC17IFR/B1nXpk54bsTmoK1xbQeUHnCdmX1AYlc8B Qchw==
X-Gm-Message-State: AFeK/H3cbHKlqbfCczN5YIEwR6seZ/oWSAYwvQF0KX3VJCuKRQ5qqKKClTEMEvon5yEbj8tsmzL1i9WB7Pi4VRVDw1vbfr09FxYqsv5BYEtVGQalOuWH8Uxjpk7atdSho/SJGTqcRKpikh1XzZo=
X-Received: by 10.176.3.107 with SMTP id 98mr3641825uat.163.1490369055835; Fri, 24 Mar 2017 08:24:15 -0700 (PDT)
X-Received: by 10.176.3.107 with SMTP id 98mr3641813uat.163.1490369055559; Fri, 24 Mar 2017 08:24:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.138.136 with HTTP; Fri, 24 Mar 2017 08:24:14 -0700 (PDT)
From: David Farmer 
Date: Fri, 24 Mar 2017 10:24:14 -0500
Message-ID: 
Subject: ULA Registration (Was: Re: IETF: SixXS is shutting down)
To: Pim van Pelt 
Cc: Alexandre Petrescu , 6man WG 
Content-Type: multipart/alternative; boundary=001a113ee5022425dc054b7b96dd
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 15:24:20 -0000

--001a113ee5022425dc054b7b96dd
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 24, 2017 at 9:14 AM, Pim van Pelt  wrote:

> Hoi Alex,
>
> On Fri, Mar 24, 2017 at 3:05 PM, Alexandre Petrescu
>  wrote:
> > Congratulations for past achievements!
> Thank you.
>
> > Tunnelbroker ok, but how about ULA generation and registration at
> sixxs.  Is
> > it shut down tombstone too?
> > https://www.sixxs.net/tools/grh/ula/
> TL/DR: Plan of record is that it will cease to exist.
>
> This registry was for educational purposes, and has no official
> status. Importantly, as ULA is random per definition, the chance of
> collisions is extremely low. It is fairly straight forward to get a
> prefix from one of the RIRs. While that does cost some money, it is an
> activity that is not the main charter of SixXS and will be expected to
> continue with the RIRs.
>

There are other purposes for registration than just uniqueness, with ULA
such as identification of leaked traffic for instance, but more generally
registration facilitates many forms of operational coordination.  We have
the RIRs use registries because we want more than just a guarantee of
uniqueness, we also want to facilitate operational coordination on many
fronts.

Further, ULA prefixes provide something that RIR allocated GUA prefixes
don't, that is a presumption that they are not routed(or reachable) between
administrative domains.  While they can be routed between administrative
domains, this is really only suppose to happen with one-on-one
coordination. Were as RIR allocated GUA prefixes are presumed to be routed
between all administrative domains.  Their is no guarantee they are
actually routed between any two administrative domains, but it is presumed
to be the case.  And, ULA is presumed to be the exact opposite that.

While ULAs are presumed to not be routed between administrative domains,
that doesn't mean they are not use cases where registration can provide
advantages, especially when ULAs are used for enterprise use cases.  There
are probably much less advantages of ULA registration when all you are
looking for is a semi-stable prefix that isn't dependent on a service
provider, like in typical residential use case, but these are not the only
use cases for ULA.

> And what happens to the registrations?
> Can't quite parse the question - so let me offer three answers (maybe
> the answer you're looking for is among them):
>

I think he means the ULA registrations.  As I mention above, there are
other advantages to registration than just uniqueness.

>From this discussion on another list, here is the count of ULA
registrations in the SixXS database.
+------+-------+
| Year | Count |
+------+-------+
| 2007 |    63 |
| 2008 |   140 |
| 2009 |   321 |
| 2010 |   611 |
| 2011 |   835 |
| 2012 |   742 |
| 2013 |   724 |
| 2014 |  1096 |
| 2015 |  1303 |
| 2016 |   640 |
| 2017 |   143 |
+------+-------+

That is 6618 ULA block that were registered, that seems like that's more
than just a fad. Does this make a case for resurrecting the discussions of
ULA-C? I think it does.  But, what do others think?

Thanks.

Happy to discuss this or other things further as we near the lights-out
> date.
>
> groet,
> Pim
>
> --
> Pim van Pelt 
> PBVP1-RIPE - http://www.ipng.nl/
>

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

--001a113ee5022425dc054b7b96dd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



    =
On Fri, Mar 24, 2017 at 9:14 AM, Pim van Pelt <pim@ipng.nl> wrote:=

    Hoi Alex,
    

    
On Fri, Mar 24, 2017 at 3:05 PM, Alexandre Petrescu
    
<alexa=
ndre.petrescu@gmail.com> wrote:
    
> Congratulations for past achievements!
    
Thank you.
    

    
> Tunnelbroker ok, but how about ULA generation and registration at sixx=
s.=C2=A0 Is
    
> it shut down tombstone too?
    
> https://www.sixxs.net/tools/grh/ula/
    
TL/DR: Plan of record is that it will cease to exist.
    

    
This registry was for educational purposes, and has no official
    
status. Importantly, as ULA is random per definition, the chance of
    
collisions is extremely low. It is fairly straight forward to get a
    
prefix from one of the RIRs. While that does cost some money, it is an
    
activity that is not the main charter of SixXS and will be expected to
    
continue with the RIRs.

    There are other=
 purposes for registration than just uniqueness, with ULA such as identific=
ation of leaked traffic for instance, but more generally registration facil=
itates many forms of operational coordination.=C2=A0 We have the RIRs use r=
egistries because we want more than just a guarantee of uniqueness, we also=
 want to facilitate operational coordination on many fronts. =C2=A0

    Further, ULA prefixes provide something that RIR allocate=
d GUA prefixes don't, that is a presumption that they are not routed(or=
 reachable) between administrative domains.=C2=A0 While they can be routed =
between administrative domains, this is really only suppose to happen with =
one-on-one coordination. Were as RIR allocated GUA prefixes are presumed to=
 be routed between all administrative domains.=C2=A0 Their is no guarantee =
they are actually routed between any two administrative domains, but it is =
presumed to be the case.=C2=A0 And, ULA is presumed to be the exact opposit=
e that.

    While ULAs are presumed to not be routed b=
etween administrative domains, that doesn't mean they are not use cases=
 where registration can provide advantages, especially when ULAs are used f=
or enterprise use cases.=C2=A0 There are probably much less advantages of U=
LA registration when all you are looking for is a semi-stable prefix that i=
sn't dependent on a service provider, like in typical residential use c=
ase, but these are not the only use cases for ULA.=C2=A0

    
> And what happens to the registrations?
    
Can't quite parse the question - so let me offer three answers (maybe
the answer you're looking for is among them):

    =

    I think he means the ULA registrations.=C2=A0 As I mention above=
, there are other advantages to registration than just uniqueness. =C2=A0

    From this discussion on another list, here is the c=
ount of ULA registrations in the SixXS database. =C2=A0
    +------+-------+
    | Year | Count |
    +------+-------+
    | 2007 |=C2=A0 =
=C2=A0 63 |
    | 2008 |=C2=A0 =C2=A0140 |
    | 2009 |=C2=A0 =C2=A0321 |
    | 2010 |=C2=A0 =C2=A0611=
 |
    | =
2011 |=C2=A0 =C2=A0835 |
    | 2012 |=C2=A0 =C2=A0742 |
    | 2013 |=C2=A0 =C2=A0724 |
    | 2014 |=
=C2=A0 1096 |
    | 2015 |=C2=A0 1303 |
    | 2016 |=C2=A0 =C2=A0640 |
    | 2017 |=C2=A0 =C2=A0143 |<=
/span>
    +----=
--+-------+

    Th=
at is 6618 ULA block that were registered, that seems like that's more =
than just a fad. Does this make a case for resurrecting=C2=A0the discussion=
s of ULA-C? I think it does.=C2=A0 But, what do others=C2=A0think?
    =C2=A0
    Thanks.

    
Happy to discuss this or other things further as we near the lights-out dat=
e.
    

    
groet,
    
Pim

    
--
    
Pim van Pelt <pim@ipng.=
nl>
    
PBVP1-RIPE - http://www.ipng.nl/
    -- 
    =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Dav=
id Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.eduNetworking & Telecommunication Services
    Office of Information Tech=
nology
    University of Minnesota=C2=A0=C2=A0 
    2218 University Ave SE=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Minneapolis, MN 55414-30=
29=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
    

    

--001a113ee5022425dc054b7b96dd--


From nobody Fri Mar 24 08:51:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B7F126CE8 for ; Fri, 24 Mar 2017 08:51:26 -0700 (PDT)
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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 zugGA3-LLU0E for ; Fri, 24 Mar 2017 08:51:23 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53070126DC2 for ; Fri, 24 Mar 2017 08:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1490370681; x=1490975481; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=wahkET7kz153mBL5nsnpYv6RK 5+RfXrI7PwEP98Jots=; b=Ub+D3UUKTGi6DTfqJwiSrO5amN+2ns2D24zXFf2vq ASCvA/fpXgPSGgb297UV6MM01x9XcMs2jTOM0ii4SxlO57/aDVp3xJAC13hOABIv SqtN9eAnTa5rYei8J5a10vv7Vma3ez7q+jPkafMe998P5OTazwlmebwItE/Fp1a2 BA=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=QCBbCYFpDCU6NzzHpm3dkwCdLxJEAo1PYdL5dFZGjEX1JtegEojk4K2gWsrI kUVMI/xXXAldpXufFRvyhJt5KFoho+Evr6BuBiNKBYvxRjFcBAErBgpxP Ot2BZBcjMrUfdgsdVoysiiEsaxh7O4xwEKkp+FLjcMpGccc5ojk94E=;
X-MDAV-Processed: mail.consulintel.es, Fri, 24 Mar 2017 16:51:21 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 24 Mar 2017 16:51:20 +0100
Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005395236.msg for ; Fri, 24 Mar 2017 16:51:19 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170324:md50005395236::jc6K8D2+VDgHkK91:00001gkY
X-Return-Path: prvs=12569b9016=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Fri, 24 Mar 2017 16:51:18 +0100
Subject: Re: ULA Registration (Was: Re: IETF: SixXS is shutting down)
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: <15DA964E-B8E4-421E-9BD0-A30B1404F9AB@consulintel.es>
Thread-Topic: ULA Registration (Was: Re: IETF: SixXS is shutting down)
References: 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 15:51:27 -0000

I was trying for some time to make it happen via a global policy, which nee=
ds to be approved in all the RIRs, but didn=E2=80=99t succeeded. May be was=
 too early:

I=E2=80=99m happy to try to run this again if we believe there is some bene=
fit out of it.

https://www.ripe.net/participate/policies/proposals/2007-05

https://www.afrinic.net/library/corporate-documents/264-proposal-for-ipv6-u=
la-central-afpub-2007-v6-003

https://www.apnic.net/wp-content/uploads/prop-048/assets/prop-048-v001.txt

http://www2.lacnic.net/documentos/politicas/LAC-2007-06-en.pdf

Regards,
Jordi
=20

-----Mensaje original-----
De: ipv6  en nombre de David Farmer 
Responder a: 
Fecha: viernes, 24 de marzo de 2017, 16:24
Para: Pim van Pelt 
CC: Alexandre Petrescu , 6man WG 
Asunto: ULA Registration (Was: Re: IETF: SixXS is shutting down)

   =20
    On Fri, Mar 24, 2017 at 9:14 AM, Pim van Pelt  wrote:
   =20
    Hoi Alex,
   =20
    On Fri, Mar 24, 2017 at 3:05 PM, Alexandre Petrescu
     wrote:
    > Congratulations for past achievements!
    Thank you.
   =20
    > Tunnelbroker ok, but how about ULA generation and registration at six=
xs.  Is
    > it shut down tombstone too?
    > https://www.sixxs.net/tools/grh/ula/
    TL/DR: Plan of record is that it will cease to exist.
   =20
    This registry was for educational purposes, and has no official
    status. Importantly, as ULA is random per definition, the chance of
    collisions is extremely low. It is fairly straight forward to get a
    prefix from one of the RIRs. While that does cost some money, it is an
    activity that is not the main charter of SixXS and will be expected to
    continue with the RIRs.
   =20
   =20
   =20
    There are other purposes for registration than just uniqueness, with UL=
A such as identification of leaked traffic for instance, but more generally=
 registration facilitates many forms of operational coordination.  We have =
the RIRs use registries because we want more than just a guarantee of uniqu=
eness, we also want to facilitate operational coordination on many fronts. =
=20
   =20
    Further, ULA prefixes provide something that RIR allocated GUA prefixes=
 don't, that is a presumption that they are not routed(or reachable) betwee=
n administrative domains.  While they can be routed between administrative =
domains, this is really only suppose to happen with one-on-one coordination=
. Were as RIR allocated GUA prefixes are presumed to be routed between all =
administrative domains.  Their is no guarantee they are actually routed bet=
ween any two administrative domains, but it is presumed to be the case.  An=
d, ULA is presumed to be the exact opposite that.
   =20
    While ULAs are presumed to not be routed between administrative domains=
, that doesn't mean they are not use cases where registration can provide a=
dvantages, especially when ULAs are used for enterprise use cases.  There a=
re probably much less advantages of ULA registration when all you are looki=
ng for is a semi-stable prefix that isn't dependent on a service provider, =
like in typical residential use case, but these are not the only use cases =
for ULA.=20
   =20
   =20
    > And what happens to the registrations?
    Can't quite parse the question - so let me offer three answers (maybe
    the answer you're looking for is among them):
   =20
   =20
   =20
    I think he means the ULA registrations.  As I mention above, there are =
other advantages to registration than just uniqueness. =20
   =20
    From this discussion on another list, here is the count of ULA registra=
tions in the SixXS database. =20
    +------+-------+
    | Year | Count |
    +------+-------+
    | 2007 |    63 |
    | 2008 |   140 |
    | 2009 |   321 |
    | 2010 |   611 |
    | 2011 |   835 |
    | 2012 |   742 |
    | 2013 |   724 |
    | 2014 |  1096 |
    | 2015 |  1303 |
    | 2016 |   640 |
    | 2017 |   143 |
    +------+-------+
   =20
   =20
    That is 6618 ULA block that were registered, that seems like that's mor=
e than just a fad. Does this make a case for resurrecting the discussions o=
f ULA-C? I think it does.  But, what do others think?
    =20
    Thanks.
   =20
   =20
    Happy to discuss this or other things further as we near the lights-out=
 date.
   =20
    groet,
    Pim
   =20
    --
    Pim van Pelt 
    PBVP1-RIPE - http://www.ipng.nl/
   =20
   =20
   =20
   =20
    --=20
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer               Email:farmer@umn.edu 
    Networking & Telecommunication Services
    Office of Information Technology
    University of Minnesota  =20
    2218 University Ave SE        Phone: 612-626-0815 
    Minneapolis, MN 55414-3029   Cell: 612-812-9952 
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
   =20
   =20
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
   =20



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the use of the individual(=
s) named above. If you are not the intended recipient be aware that any dis=
closure, copying, distribution or use of the contents of this information, =
including attached files, is prohibited.




From nobody Fri Mar 24 09:09:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262AB1296F2 for ; Fri, 24 Mar 2017 09:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hosted.ipng.nl header.b=QwVzOcHr; dkim=pass (1024-bit key) header.d=ipng.nl header.b=qPppaLsc
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 1KdjQ6TnpQOg for ; Fri, 24 Mar 2017 09:09:02 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A4412426E for ; Fri, 24 Mar 2017 09:09:01 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id f193so3632057oib.2 for ; Fri, 24 Mar 2017 09:09:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hosted.ipng.nl; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=g+SDlwHz+rIWK7QSkFFwtA8cFG/bVbE0UFLxzPFAJhA=; b=QwVzOcHrE+mMb5oHA5fNVrGxK5WK8tirXXSICSr9rA1iJdxiN2LpW8eX71AO6o7i7l PuqkJoS16FGAjzORkH4aOP5+3M0U2cjMjv8mQ/KK5qO29RlBumxeW6IlNGVitXZBoijM L17w1BTjVgK9DYLfvBCgxEAGIVQhtagH0UFGM=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipng.nl; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=g+SDlwHz+rIWK7QSkFFwtA8cFG/bVbE0UFLxzPFAJhA=; b=qPppaLscqu7sNws4+TwfVSi/vtsSMKWiK1gij8smqpL/W6b98x83TS9DvbpE2Fm5vH cy3CZR9PVufz1x2aHckXUAbTTILXkZg6HlNdivoopS12hOYbxwF4A8IJ+MEdvhMgHbVE LFKL5vrcWvG/befPetj+2Lr5ail6PJYe/6VZU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=g+SDlwHz+rIWK7QSkFFwtA8cFG/bVbE0UFLxzPFAJhA=; b=GzIqCBUyll0THSOzk21FfZCf+ePdbdQYzJJfWniIKwOr2hrTq3YxAOLqE+SdZf1xCp btYZR8MVhlaAVoHAiuOAYDWmCTdbOhH4KbSN09duWMAdUU2+gVheHxXDCf8Akj8ayOeG L1iWCg7zcHNqvHP1WVIJMYLlad78cDqhva2bEUoH/wcjPwxKj3rTZywVCX3k0kIxX3H4 JZuFb5vdXet2u7tb/yGvjiBN8eB4/w7+CLw2hxSmUriK/jE/UEpZlXt21TPceMGykIf4 Uc/tRhO6TcSR+vONUQ7I93EROiXfydhjd1JnZbffe4NaRDywI+xKcikMyB0CoIVzhVZq +juw==
X-Gm-Message-State: AFeK/H0teWFdn9gBOORFTdA/nXXxQntHKYDXJrM4HEylfgn6rXILSKWnqlJEODVcxhYzE5xoC/W0bZoPd4ZD9g==
X-Received: by 10.202.62.4 with SMTP id l4mr4402109oia.75.1490371739156; Fri, 24 Mar 2017 09:08:59 -0700 (PDT)
MIME-Version: 1.0
Sender: pim@hosted.ipng.nl
Received: by 10.202.105.209 with HTTP; Fri, 24 Mar 2017 09:08:58 -0700 (PDT)
In-Reply-To: 
References: 
From: Pim van Pelt 
Date: Fri, 24 Mar 2017 17:08:58 +0100
X-Google-Sender-Auth: M_bbLoy7iwtwXI4_F4-lwT4Wzkg
Message-ID: 
Subject: Re: ULA Registration (Was: Re: IETF: SixXS is shutting down)
To: David Farmer 
Cc: Alexandre Petrescu , 6man WG 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 16:09:04 -0000

Hi David,

On Fri, Mar 24, 2017 at 4:24 PM, David Farmer  wrote:
> There are other purposes for registration than just uniqueness, ...
I see your point and I agree with the operational benefits of registering.
Scanning back on the archives on ULA-C discussions, there seem to be
two camps, the pragmatic folk who would like to use a registry to
debug operational issues, and the fundamental camp who do not believe
ULA prefixes should be visible, should not be resolvable globally, and
so on. Personally, I'm in the former camp, believing the visibility is
a benefit at times, while the cost of registering is not large.

>> > And what happens to the registrations?
> That is 6618 ULA block that were registered, that seems like that's more
> than just a fad. Does this make a case for resurrecting the discussions of
> ULA-C? I think it does.  But, what do others think?
My question is not should you register the prefixes or not. My questions are:
- what is the status of SixXS as an authority?
- why do the RIRs not assume responsibility?

My first question is somewhat facetious, as the answer is clearly "it
has no authority". The answer to my second question is not captured in
Jordi's reply (thanks for the context, though!) but I'm keenly
interested in it. It seems that if the RIRs did not approve in 2007,
other than closing that gap, why should I do it? I'll wait for others
to reply to David's request for comments but if we are to re-raise the
ULA-C proposal, I'm happy to be involved (surely by transferring our
existing data, but in any other way we believe makes sense).

groet,
Pim

-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/


From nobody Fri Mar 24 09:18:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193031270FC for ; Fri, 24 Mar 2017 09:18:04 -0700 (PDT)
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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 hN2Nq_l7vJYO for ; Fri, 24 Mar 2017 09:18:02 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7601297AB for ; Fri, 24 Mar 2017 09:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1490372280; x=1490977080; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=KQHnQ6S+j24tlj0+ylvjayhib KJfaj+2F3mvyKNXRjI=; b=NIOGB2l5zaeiiUtXhZxPEQktey627+deZCWlLAAFb KwgcAlaFuQWTrVmUyQs1wLVaqetul9mvdg+K/hiivwM6fLEayyxoju4Bj6ObuSe3 axrIJlCx04UsPUfW/lZA0EfKZzmMEy7N11+UFlQhvo5nu01ezIumOnze49JMduxs hY=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=g4FD4WB8ky7YfCeyrf8q2s6CnCY6GoYC6rtcEpc+gbDp4HEVuS++hxPhpoCk H+Va/dtArQlLA0WNmdNoetchOL9I4VTaWagpXpHkW5UDeJy3rDZ6BGw0a TOh6Nz2hxBE4S6sPBVMD7ZXyIlj6Mm2lopoegCF/N82WLta7gAy+Ec=;
X-MDAV-Processed: mail.consulintel.es, Fri, 24 Mar 2017 17:18:00 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 24 Mar 2017 17:17:59 +0100
Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005395256.msg for ; Fri, 24 Mar 2017 17:17:59 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170324:md50005395256::GpQDc7J6V9Bk3RBD:00000aJN
X-Return-Path: prvs=12569b9016=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Fri, 24 Mar 2017 17:17:54 +0100
Subject: Re: ULA Registration (Was: Re: IETF: SixXS is shutting down)
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: 
Thread-Topic: ULA Registration (Was: Re: IETF: SixXS is shutting down)
References:  
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 16:18:04 -0000

Trying to answer your 2nd question =E2=80=A6 I think the RIR communities (n=
ot the RIRs itself) didn=E2=80=99t got to understand if ULA-C was actually =
needed or not.

This is at the end, the only reason why policy proposals get approved. The =
communities understanding the need/problem and agreeing in the proposed sol=
ution.

I also tried to see if instead of having the NRO running the ULA-C registry=
, or one of them on behalf of all, or a =E2=80=9Cunique=E2=80=9D central re=
gistry managed by all, may be the way is to ask IANA to run the service wit=
h a low fee, just to cover the cost.

As said, if we have a valid reason now, maybe even the same reasons we had =
before, but now are better understood, I=E2=80=99m happy to revive all the =
process in all the RIRs, work in an update of the ula-central with original=
 authors or whatever is needed.

Regards,
Jordi
=20

-----Mensaje original-----
De: ipv6  en nombre de Pim van Pelt 
Responder a: 
Fecha: viernes, 24 de marzo de 2017, 17:08
Para: David Farmer 
CC: Alexandre Petrescu , 6man WG 
Asunto: Re: ULA Registration (Was: Re: IETF: SixXS is shutting down)

    Hi David,
   =20
    On Fri, Mar 24, 2017 at 4:24 PM, David Farmer  wrote:
    > There are other purposes for registration than just uniqueness, ...
    I see your point and I agree with the operational benefits of registeri=
ng.
    Scanning back on the archives on ULA-C discussions, there seem to be
    two camps, the pragmatic folk who would like to use a registry to
    debug operational issues, and the fundamental camp who do not believe
    ULA prefixes should be visible, should not be resolvable globally, and
    so on. Personally, I'm in the former camp, believing the visibility is
    a benefit at times, while the cost of registering is not large.
   =20
    >> > And what happens to the registrations?
    > That is 6618 ULA block that were registered, that seems like that's m=
ore
    > than just a fad. Does this make a case for resurrecting the discussio=
ns of
    > ULA-C? I think it does.  But, what do others think?
    My question is not should you register the prefixes or not. My question=
s are:
    - what is the status of SixXS as an authority?
    - why do the RIRs not assume responsibility?
   =20
    My first question is somewhat facetious, as the answer is clearly "it
    has no authority". The answer to my second question is not captured in
    Jordi's reply (thanks for the context, though!) but I'm keenly
    interested in it. It seems that if the RIRs did not approve in 2007,
    other than closing that gap, why should I do it? I'll wait for others
    to reply to David's request for comments but if we are to re-raise the
    ULA-C proposal, I'm happy to be involved (surely by transferring our
    existing data, but in any other way we believe makes sense).
   =20
    groet,
    Pim
   =20
    --=20
    Pim van Pelt 
    PBVP1-RIPE - http://www.ipng.nl/
   =20
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
   =20
   =20



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the use of the individual(=
s) named above. If you are not the intended recipient be aware that any dis=
closure, copying, distribution or use of the contents of this information, =
including attached files, is prohibited.




From nobody Fri Mar 24 09:25:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4131120727 for ; Fri, 24 Mar 2017 09:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 mbIG51GQ8wAT for ; Fri, 24 Mar 2017 09:25:45 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193AC1201F2 for ; Fri, 24 Mar 2017 09:25:44 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2OGPhx9014553; Fri, 24 Mar 2017 17:25:43 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A4C120ADD8; Fri, 24 Mar 2017 17:25:43 +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 22F5A20AD4A; Fri, 24 Mar 2017 17:25:43 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2OGPgJ3012927; Fri, 24 Mar 2017 17:25:43 +0100
Subject: Re: IETF: SixXS is shutting down - privacy
To: Pim van Pelt 
References:  <8350d58a-00b1-3561-c842-422703a22be7@gmail.com> 
Cc: ipv6@ietf.org
From: Alexandre Petrescu 
Message-ID: 
Date: Fri, 24 Mar 2017 17:25:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 16:25:47 -0000

Le 24/03/2017 à 15:14, Pim van Pelt a écrit :
[...]
> Secondly, in the lifetime of the project, we have taken privacy and
> individually identifiable information very seriously,

Yes.

Now one could use random.org to generate an ULA prefix, instead of the 
sixxs generator.

(provided one trusts random.org, and hoping random.org is reachable on 
IPv6, of course)

Alex


From nobody Fri Mar 24 09:36:00 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5B120727 for ; Fri, 24 Mar 2017 09:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 P5bPkSTpzmt8 for ; Fri, 24 Mar 2017 09:35:57 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB825129858 for ; Fri, 24 Mar 2017 09:35:56 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2OGZtdj023799 for ; Fri, 24 Mar 2017 17:35:55 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3359E20AD4A for ; Fri, 24 Mar 2017 17:35:55 +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 2A7E52067CE for ; Fri, 24 Mar 2017 17:35:55 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2OGZsQS025428 for ; Fri, 24 Mar 2017 17:35:55 +0100
Subject: Re: ULA Registration
To: ipv6@ietf.org
References:   
From: Alexandre Petrescu 
Message-ID: <124a9357-0913-5e12-ce8b-4be0dcb03898@gmail.com>
Date: Fri, 24 Mar 2017 17:35:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 16:35:59 -0000

Le 24/03/2017 à 17:17, JORDI PALET MARTINEZ a écrit :
> Trying to answer your 2nd question … I think the RIR communities (not
> the RIRs itself) didn’t got to understand if ULA-C was actually
> needed or not.
>
> This is at the end, the only reason why policy proposals get
> approved. The communities understanding the need/problem and agreeing
> in the proposed solution.
>
> I also tried to see if instead of having the NRO running the ULA-C
> registry, or one of them on behalf of all, or a “unique†central
> registry managed by all, may be the way is to ask IANA to run the
> service with a low fee, just to cover the cost.

If IANA can take it up, all the better.

> As said, if we have a valid reason now, maybe even the same reasons
> we had before, but now are better understood, I’m happy to revive all
> the process in all the RIRs, work in an update of the ula-central
> with original authors or whatever is needed.

Well I am not sure there is other reasoning now for ULA-Centralized: no 
more and no less reasons than before.  I may be wrong though.

But this event does teach important things.

All ULA-C depends a lot on the viability for a central server, its 
lifetime, its funding perenity.

If there is no server for it, there is no ULA-C.

It's impossible to rewind the effort that was spent in the ULA-C 
discussion...

But does one need to update the RFC4193 "ULA" and tell there is no L==1, 
it's always a 0 (?)

This is a significant event.

Alex

>
> Regards, Jordi
>
>
> -----Mensaje original----- De: ipv6  en nombre
> de Pim van Pelt  Responder a:  Fecha:
> viernes, 24 de marzo de 2017, 17:08 Para: David Farmer
>  CC: Alexandre Petrescu
> , 6man WG  Asunto: Re:
> ULA Registration (Was: Re: IETF: SixXS is shutting down)
>
> Hi David,
>
> On Fri, Mar 24, 2017 at 4:24 PM, David Farmer 
> wrote:
>> There are other purposes for registration than just uniqueness,
>> ...
> I see your point and I agree with the operational benefits of
> registering. Scanning back on the archives on ULA-C discussions,
> there seem to be two camps, the pragmatic folk who would like to use
> a registry to debug operational issues, and the fundamental camp who
> do not believe ULA prefixes should be visible, should not be
> resolvable globally, and so on. Personally, I'm in the former camp,
> believing the visibility is a benefit at times, while the cost of
> registering is not large.
>
>>>> And what happens to the registrations?
>> That is 6618 ULA block that were registered, that seems like that's
>> more than just a fad. Does this make a case for resurrecting the
>> discussions of ULA-C? I think it does.  But, what do others think?
> My question is not should you register the prefixes or not. My
> questions are: - what is the status of SixXS as an authority? - why
> do the RIRs not assume responsibility?
>
> My first question is somewhat facetious, as the answer is clearly
> "it has no authority". The answer to my second question is not
> captured in Jordi's reply (thanks for the context, though!) but I'm
> keenly interested in it. It seems that if the RIRs did not approve in
> 2007, other than closing that gap, why should I do it? I'll wait for
> others to reply to David's request for comments but if we are to
> re-raise the ULA-C proposal, I'm happy to be involved (surely by
> transferring our existing data, but in any other way we believe makes
> sense).
>
> groet, Pim
>
> -- Pim van Pelt  PBVP1-RIPE - http://www.ipng.nl/
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>
>
>
> ********************************************** IPv4 is over Are you
> ready for the new Internet ? http://www.consulintel.es The IPv6
> Company
>
> This electronic message contains information which may be privileged
> or confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be
> aware that any disclosure, copying, distribution or use of the
> contents of this information, including attached files, is
> prohibited.
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


From nobody Fri Mar 24 09:40:23 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62A2126579 for ; Fri, 24 Mar 2017 09:40:21 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 oyrhcDG-jyGB for ; Fri, 24 Mar 2017 09:40:20 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F58120727 for ; Fri, 24 Mar 2017 09:40:19 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id w20so3647619pgc.0 for ; Fri, 24 Mar 2017 09:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1vslNqG7jj3c3zwRsJ/Bp2jYhqNc9A96dEzTy6ji76g=; b=NllzMVYnhKfBduWzGhCXR1CeaPYiM9qv1B341ma6NNs2OBRWB3K+WM5AGuPF/cYWGr iFXuCS3Eym6JBs32zWxbYnbWYKKh3cI6siX2Er0PwLlz9FMqTSMcMRMP3wY/6nflnV76 wfnYRc63AAET/4MLWxMQhV3nAVoL+wqtuPhnh8TK2PFJIFBFmvkHsfbRC/LmMXbvr3Ed 1xr3+UH9Ym1hEWQYlP2UE6JG/+PymSn3i5AT8lqPW53WqeTKxLoURMIBxwImkOylXvYR 6t3m+iC9PAY16ajk3/+Tyymhvs585WW7XyucUv8VixTi6C8NnD3Gwbj8CctFwmIYle7Z QsVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1vslNqG7jj3c3zwRsJ/Bp2jYhqNc9A96dEzTy6ji76g=; b=rmcs+EWYmb2JQz0EXXw8s0xdW28tMZ/GUeICwB7TGLezzeaXwHO6aALtI+6/qWHHnO o3LFNrz77y0Xhw8+HCVu8sdHNVm39VyOiOFT05idFSWzWMav4KNORdqbTnBHGBw4RCVp 1hxgh2Cahy1GC+EfayFTLqR/6nSx90iMgVMLKeJODmxx+J4Jbbuiuvibej+bkhjgu1IL BwRb7t0QVOU+3zEoHlmXMqtQLMRiQVVZ4MnjmhtCaUfLkwTO0Dohl5lwYWiNDLPRNPhz QfmI6n0cJEV0ZsmhYg5Oe4ID6kaR1p8TqBE/BgKstrpRfvkG8Bjq73aQG6fwbeGhG9lz EWzg==
X-Gm-Message-State: AFeK/H0EFtWGAAQdzN/vEplDUQ8xrhZqn2HLBdQE3JKj5V6WA1Pe704QchYd05VuiXD1xA==
X-Received: by 10.84.133.133 with SMTP id f5mr12050277plf.64.1490373619564; Fri, 24 Mar 2017 09:40:19 -0700 (PDT)
Received: from [172.26.35.3] ([104.129.198.114]) by smtp.gmail.com with ESMTPSA id s21sm5692104pgg.65.2017.03.24.09.40.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 09:40:18 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: IETF: SixXS is shutting down - privacy
From: Fred Baker 
In-Reply-To: 
Date: Fri, 24 Mar 2017 09:40:19 -0700
Cc: Pim van Pelt , ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <8350d58a-00b1-3561-c842-422703a22be7@gmail.com>  
To: Alexandre Petrescu 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 16:40:22 -0000

> On Mar 24, 2017, at 9:25 AM, Alexandre Petrescu =
 wrote:
>=20
> Le 24/03/2017 =C3=A0 15:14, Pim van Pelt a =C3=A9crit :
> [...]
>> Secondly, in the lifetime of the project, we have taken privacy and
>> individually identifiable information very seriously,
>=20
> Yes.
>=20
> Now one could use random.org to generate an ULA prefix, instead of the =
sixxs generator.
>=20
> (provided one trusts random.org, and hoping random.org is reachable on =
IPv6, of course)

dhcp-wifi-197:v6ops fred$ dig AAAA random.org +short
2400:cb00:2048:1::6814:2d07
2400:cb00:2048:1::6814:2c07

> Alex
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Fri Mar 24 09:52:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828C5126C25 for ; Fri, 24 Mar 2017 09:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 UDPlGeeCOc7b for ; Fri, 24 Mar 2017 09:52:44 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7331250B8 for ; Fri, 24 Mar 2017 09:52:43 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2OGqgu8038935; Fri, 24 Mar 2017 17:52:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 16E8420AEA6; Fri, 24 Mar 2017 17:52:42 +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 0664320AD66; Fri, 24 Mar 2017 17:52:42 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2OGqfVE001059; Fri, 24 Mar 2017 17:52:41 +0100
Subject: Re: ULA Registration
To: David Farmer , Pim van Pelt 
References: 
Cc: 6man WG 
From: Alexandre Petrescu 
Message-ID: <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com>
Date: Fri, 24 Mar 2017 17:52:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 16:52:45 -0000

Le 24/03/2017 à 16:24, David Farmer a écrit :
>
> On Fri, Mar 24, 2017 at 9:14 AM, Pim van Pelt  > wrote:
>
>     Hoi Alex,
>
>     On Fri, Mar 24, 2017 at 3:05 PM, Alexandre Petrescu
>     >
>     wrote:
>     > Congratulations for past achievements!
>     Thank you.
>
>     > Tunnelbroker ok, but how about ULA generation and registration at
>     sixxs.  Is
>     > it shut down tombstone too?
>     > https://www.sixxs.net/tools/grh/ula/
>     
>     TL/DR: Plan of record is that it will cease to exist.
>
>     This registry was for educational purposes, and has no official
>     status. Importantly, as ULA is random per definition, the chance of
>     collisions is extremely low. It is fairly straight forward to get a
>     prefix from one of the RIRs. While that does cost some money, it is an
>     activity that is not the main charter of SixXS and will be expected to
>     continue with the RIRs.
>
>
> There are other purposes for registration than just uniqueness, with ULA
> such as identification of leaked traffic for instance, but more
> generally registration facilitates many forms of operational
> coordination.  We have the RIRs use registries because we want more than
> just a guarantee of uniqueness, we also want to facilitate operational
> coordination on many fronts.
>
> Further, ULA prefixes provide something that RIR allocated GUA prefixes
> don't, that is a presumption that they are not routed(or reachable)
> between administrative domains.  While they can be routed between
> administrative domains, this is really only suppose to happen with
> one-on-one coordination. Were as RIR allocated GUA prefixes are presumed
> to be routed between all administrative domains.  Their is no guarantee
> they are actually routed between any two administrative domains, but it
> is presumed to be the case.  And, ULA is presumed to be the exact
> opposite that.
>
> While ULAs are presumed to not be routed between administrative domains,
> that doesn't mean they are not use cases where registration can provide
> advantages, especially when ULAs are used for enterprise use cases.
> There are probably much less advantages of ULA registration when all you
> are looking for is a semi-stable prefix that isn't dependent on a
> service provider, like in typical residential use case, but these are
> not the only use cases for ULA.
>
>     > And what happens to the registrations?
>     Can't quite parse the question - so let me offer three answers (maybe
>     the answer you're looking for is among them):
>
>
> I think he means the ULA registrations.  As I mention above, there are
> other advantages to registration than just uniqueness.

Other advantages yes, and inconvenients too, depending on how it's 
implemented.  It should be trustable.

> From this discussion on another list, here is the count of ULA
> registrations in the SixXS database.
> +------+-------+
> | Year | Count |
> +------+-------+
> | 2007 |    63 |
> | 2008 |   140 |
> | 2009 |   321 |
> | 2010 |   611 |
> | 2011 |   835 |
> | 2012 |   742 |
> | 2013 |   724 |
> | 2014 |  1096 |
> | 2015 |  1303 |
> | 2016 |   640 |
> | 2017 |   143 |
> +------+-------+
>
> That is 6618 ULA block that were registered, that seems like that's more
> than just a fad. Does this make a case for resurrecting the discussions
> of ULA-C? I think it does.  But, what do others think?

The numbers look impressive, with a glory period yet now declining. Or
just momentarily declining to only grow bigger in the longer term.

On my side, I hesitated before registering my small ULA prefixes on sixxs.

Now I could still live with randomly-generated ULA prefixes, or
generated from other significant identifiers, controlled by other
authorities relevant in particular use-cases.

But, if in the future very many computers hit this unique-/64 limit,
then ULA-C w/ or w/o NAT66 could become real necessities.

Alex

>
> Thanks.
>
>     Happy to discuss this or other things further as we near the
>     lights-out date.
>
>     groet,
>     Pim
>
>     --
>     Pim van Pelt >
>     PBVP1-RIPE - http://www.ipng.nl/
>
>
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu
> 
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815 
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 
> ===============================================


From nobody Fri Mar 24 11:02:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1CF1294C8 for ; Fri, 24 Mar 2017 11:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 V-wFck9TyhHr for ; Fri, 24 Mar 2017 11:02:00 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB51126D05 for ; Fri, 24 Mar 2017 11:02:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v2OI1xGE059621; Fri, 24 Mar 2017 11:02:00 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v2OI1mDL059483 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 24 Mar 2017 11:01:48 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 24 Mar 2017 11:01:48 -0700
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 24 Mar 2017 11:01:48 -0700
From: "Manfredi, Albert E" 
To: Alexandre Petrescu 
CC: 6man WG 
Subject: RE: ULA Registration
Thread-Topic: ULA Registration
Thread-Index: AQHSpL8Wtghz9V35LkmfhLX/yLgT5qGkQ4yg
Date: Fri, 24 Mar 2017 18:01:48 +0000
Message-ID: <39db830bd4d04faca308c01d0d39b8ae@XCH15-06-11.nw.nos.boeing.com>
References:  <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com>
In-Reply-To: <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 18:02:02 -0000

LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0cmVzY3UNCg0KPiBPbiBteSBz
aWRlLCBJIGhlc2l0YXRlZCBiZWZvcmUgcmVnaXN0ZXJpbmcgbXkgc21hbGwgVUxBIHByZWZpeGVz
DQo+IG9uIHNpeHhzLg0KDQpNZSB0b28uIEkgdGhpbmsgb2YgVUxBIGFzIGZ1bmN0aW9uYWxseSBl
cXVpdmFsZW50IHRvIFJGQyAxOTE4IGFkZHJlc3Nlcy4gQSByZWdpc3RyeSBmb3IgVUxBcywgb3Ig
VUxBLUMsIGlzIG5vdCBhbmQgc2hvdWxkIG5vdCBiZSBtYW5kYXRvcnkuIENvbnNlcXVlbnRseSwg
c3VjaCBhIHJlZ2lzdHJ5IGlzIG9mIGxpbWl0ZWQgZWZmZWN0aXZlbmVzcy4gVUxBcyBhcmUgZWFz
aWx5IGlkZW50aWZpZWQsIHNvIHRoZXkgY2FuIGJlIGJsb2NrZWQgYXQgYm91bmRhcmllcyBiZXR3
ZWVuIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMgKHVubGVzcyB0aGUgYWRtaW5pc3RyYXRpdmUgZG9t
YWlucyBoYXZlIGEgc3BlY2lhbCBhZ3JlZW1lbnQpLCB0byBtaXRpZ2F0ZSB0aGUgcHJvYmxlbSBE
YXZpZCBtZW50aW9uZWQsIG9mIHRyYWNraW5nIGRvd24gVUxBcyB0aGF0IGFwcGVhciBvbiB0aGUg
SW50ZXJuZXQuDQoNCj4gQnV0LCBpZiBpbiB0aGUgZnV0dXJlIHZlcnkgbWFueSBjb21wdXRlcnMg
aGl0IHRoaXMgdW5pcXVlLS82NA0KPiBsaW1pdCwgdGhlbiBVTEEtQyB3LyBvciB3L28gTkFUNjYg
Y291bGQgYmVjb21lIHJlYWwgbmVjZXNzaXRpZXMuDQoNCk5vdCBzdXJlIHRoYXQgYSBVTEEgcmVn
aXN0cnkgaXMgbmVlZGVkIGV2ZW4gaW4gdGhpcyBldmVudHVhbGl0eS4gQW5kIGFueSBkZWNlbnQg
UFJORyBzaG91bGQgYmUgZ29vZCBlbm91Z2ggdG8gZ2VuZXJhdGUgcmFuZG9tIHByZWZpeGVzPw0K
DQpCZXJ0DQoNCg==


From nobody Fri Mar 24 11:37:25 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5921286B1 for ; Fri, 24 Mar 2017 11:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Daf1dTi4rrha for ; Fri, 24 Mar 2017 11:37:22 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9C41279E5 for ; Fri, 24 Mar 2017 11:37:22 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id y18so10091896itc.1 for ; Fri, 24 Mar 2017 11:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XO1zWjkxusI2j11JlQ3HqFNseI3+f61O2X62VhW7vag=; b=pTv6U95iUJwqg9eZAX+BDQP6nf3XQ8uTRi4khHHuue/zaSdyLfgrU+UsnB6nU6+MZl ST+LviswGz0gy/BVhHTQJiYHhr/tXmTFfD6rfMTmXMAcofG9nCdEsEji2Y1ikMRfbynj ENCSNf7NCcly0lNBlIGFE53gsPRjU/ZKOCD4nt73wab8lGDBnq0PmO3IEKK+sZJtblc5 iSqDOTZKOFqg5FU4VbfSoUYpRNNQAnhYlKHJGbdjF89Gl02WYXy7vE0WJWueuA/k5a7t 5VMBIPMtg86ThbdZlcqnAupF8I0+dyj7CAGoP5SA7TqfkDsO1L4MSpyBABUgEU6P8Dix mtEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=XO1zWjkxusI2j11JlQ3HqFNseI3+f61O2X62VhW7vag=; b=VWMUPAFigaiQj/huzyuecSUr/b/w3rP+rvXAi6M+SlqntN27B6Hcwvqo/XUIgikgez wcljPhC4APPhpGVnkP8pDBr8hTLEtu0A/gTGnnDV+o0ZL9yrqSjcnlQLHABXeD7KDBeP ln87lS9aeXxAJA4BQAw8VYdROokLyJ2fVnhvBzIk+lECO2uz1NuH5wbn6uMuHbFp2Bu0 VFvKWwGs+txogf6EB63MBCpPp0IJMBfBgKmwnbg7eDkb0zkwQr7Nx69IKw+033zWmkP1 2TWWDPrGR8cgHg5p+Rj+I2E4AOgFH2m3WC6cLu6RHZcnDwQc+bb7F9KfnhU82IKjWUq5 Dz7g==
X-Gm-Message-State: AFeK/H1SHxVZANKaFjdF4jJDTDMpZsPSu3Zgbiv9g5dqnOCopzoSV89CDrf6qIfXiqXmPA==
X-Received: by 10.36.66.141 with SMTP id i135mr4675828itb.86.1490380641363; Fri, 24 Mar 2017 11:37:21 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 89sm1572652ioj.17.2017.03.24.11.37.20 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 11:37:20 -0700 (PDT)
Subject: ULA clashes don't matter [Re: ULA Registration]
To: ipv6@ietf.org
References:  <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com> <39db830bd4d04faca308c01d0d39b8ae@XCH15-06-11.nw.nos.boeing.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Sat, 25 Mar 2017 07:37:31 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <39db830bd4d04faca308c01d0d39b8ae@XCH15-06-11.nw.nos.boeing.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 18:37:24 -0000

Do I need to justify that? Oh, OK:

1. In the highly unlikely event of two networks merging (i.e. installing
round-the-back private routing between them) and discovering that they
are using the same pseudo-random ULA prefix: yes, they will be put to
a little bother. But this is so unlikely that it really isn't worth any
overhead to avoid it - and it would only be avoidable if at least of the
two networks had bothered to register their prefix.

2. In the rather more likely event of two networks merging and discovering
that they are using the same non-random ULA prefix (fd00::/48 probably),
it's their own silly fault.

3. In the somewhat likely event of a ULA prefix being announced in BGP4,
we will know who's announcing it, so we don't need a registry. And everybody
else will filter it anyway.

Regards
   Brian


From nobody Fri Mar 24 11:45:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A49B120727 for ; Fri, 24 Mar 2017 11:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DX2eM-zyB7TH for ; Fri, 24 Mar 2017 11:45:27 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D923E126C2F for ; Fri, 24 Mar 2017 11:45:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v2OIjQBi043530; Fri, 24 Mar 2017 11:45:26 -0700
Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v2OIjK5h043503 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 24 Mar 2017 11:45:20 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 24 Mar 2017 11:45:19 -0700
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 24 Mar 2017 11:45:19 -0700
From: "Manfredi, Albert E" 
To: Brian E Carpenter , "ipv6@ietf.org" 
Subject: RE: ULA clashes don't matter [Re: ULA Registration]
Thread-Topic: ULA clashes don't matter [Re: ULA Registration]
Thread-Index: AQHSpM3A/iJHQdoIe0W/pkEm96rrv6GkU96g
Date: Fri, 24 Mar 2017 18:45:19 +0000
Message-ID: 
References:  <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com> <39db830bd4d04faca308c01d0d39b8ae@XCH15-06-11.nw.nos.boeing.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 18:45:30 -0000

+1


-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: Friday, March 24, 2017 14:38
To: ipv6@ietf.org
Subject: ULA clashes don't matter [Re: ULA Registration]

Do I need to justify that? Oh, OK:

1. In the highly unlikely event of two networks merging (i.e. installing
round-the-back private routing between them) and discovering that they
are using the same pseudo-random ULA prefix: yes, they will be put to
a little bother. But this is so unlikely that it really isn't worth any
overhead to avoid it - and it would only be avoidable if at least of the
two networks had bothered to register their prefix.

2. In the rather more likely event of two networks merging and discovering
that they are using the same non-random ULA prefix (fd00::/48 probably),
it's their own silly fault.

3. In the somewhat likely event of a ULA prefix being announced in BGP4,
we will know who's announcing it, so we don't need a registry. And everybod=
y
else will filter it anyway.

Regards
   Brian

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



From nobody Fri Mar 24 13:31:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E88B129890 for ; Fri, 24 Mar 2017 13:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 H0hykDtpRNui for ; Fri, 24 Mar 2017 13:31:23 -0700 (PDT)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BD41294B1 for ; Fri, 24 Mar 2017 13:31:23 -0700 (PDT)
Received: by mail-pg0-x232.google.com with SMTP id 21so545496pgg.1 for ; Fri, 24 Mar 2017 13:31:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=s+bR51Vfy2TRYi4yjijMId9QyXSWLW8iAz00RDspyGg=; b=FsAonR1f/ckoQcveaJUBcyC7/dhMQvMPqJbjYKJ59KfW2+k2S/+Mc4jxvDFSZAxdTP q8834MvjJj5/2+/5hNvOKXHwrz3DcJrHEKMj3oNbBEpZEjvG//EzqzUDcvKeN47OXUsf bhY0OfxVK/hANHmXV7dWhPdJO+24FdiRUgTDNdswmbENcYdmQeH48qiAgLq74Q9tdoia lFP+rU3FvXfrQaHUZzYPvCJAW9Ebilgzrf0W2cVVzE/iw80QlRiFgLJ+ekCtC/VKIm/6 ifa1J80ybYVmNux4gi0ahnM45P+uCw1/95F1q2yQ8qZKVy1XUG7L5HjctUFzt8GCQVtW tqoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=s+bR51Vfy2TRYi4yjijMId9QyXSWLW8iAz00RDspyGg=; b=qQheM9NeHFcticiw+5qNTubRgzh4tUaMniqD8UryOyP74vw0yA+GbOeH29IhIMsBsc M5AtgzMLHvSGeosb+if8UdlvyvyDFrC0U24uyvJlb1CD2bLPUM5SefbCMhvspGV/uz5+ Z7R2e4GwxRQ6Lh+o7WiRPGahqMZnh+dpx0c+CT3gCa2AFYw+F/3YMWVACMbfjdQobS+L Ylxo4S2LuL0BXLAxr04qELoIfF/0MihfqkAA0ZcV1fL78nQb0s9RGDadkX4pP0/AMM3O d+HRrN1aHEYM6gZfRpL2+uK66s6bRXWj0Trq0fyGvotIG4xtHfc/irDV6bs1uFtZevMG DQJw==
X-Gm-Message-State: AFeK/H0xa3QWC8wks/bYXoyG9xf8R0/807M4HWGHi7vYLd62B46jRjHkEHP4cllUCNQhZ0D/
X-Received: by 10.84.236.5 with SMTP id q5mr3069650plk.2.1490387483105; Fri, 24 Mar 2017 13:31:23 -0700 (PDT)
Received: from ?IPv6:2001:5a8:4:2290:7dfe:1226:9d62:746a? ([2001:5a8:4:2290:7dfe:1226:9d62:746a]) by smtp.gmail.com with ESMTPSA id s3sm6302259pgn.55.2017.03.24.13.31.22 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 13:31:22 -0700 (PDT)
From: james woodyatt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF945968-0E2D-4582-8A97-E0B69F7995E5"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: ULA clashes don't matter [Re: ULA Registration]
Date: Fri, 24 Mar 2017 13:31:20 -0700
References:  <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com> <39db830bd4d04faca308c01d0d39b8ae@XCH15-06-11.nw.nos.boeing.com> 
To: 6man WG 
In-Reply-To: 
Message-Id: <1E2BE958-3186-4201-92B6-FB7A5EB59D5C@google.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 20:31:25 -0000

--Apple-Mail=_CF945968-0E2D-4582-8A97-E0B69F7995E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Mar 24, 2017, at 11:37, Brian E Carpenter =
 wrote:
>=20
> Do I need to justify that? Oh, OK: [=E2=80=A6]

4. In the event of the simultaneous merge of a sufficient number of =
ULA-numbered networks that the statistical chance of Global ID =
collisions arising would approach a significant level, the entity =
performing that merge can make its own private arrangements to manage =
the numbering requirements for the merge. For one thing, there is no =
apparent and immediate need for a public service to do it, and for =
another, establishing a registry is not obviously the best way to =
construct such a service in the event the need arises for one in the =
unforeseeable future.

--james woodyatt >




--Apple-Mail=_CF945968-0E2D-4582-8A97-E0B69F7995E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Mar 24, 2017, at 11:37, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

    Do I =
need to justify that? Oh, OK: [=E2=80=A6]

    4. In the =
event of the simultaneous merge of a sufficient number of ULA-numbered =
networks that the statistical chance of Global ID collisions arising =
would approach a significant level, the entity performing that merge can =
make its own private arrangements to manage the numbering requirements =
for the merge. For one thing, there is no apparent and immediate need =
for a public service to do it, and for another, establishing a registry =
is not obviously the best way to construct such a service in the event =
the need arises for one in the unforeseeable future.

    

    --james woodyatt <jhw@google.com>


    


    

    =

--Apple-Mail=_CF945968-0E2D-4582-8A97-E0B69F7995E5--


From nobody Fri Mar 24 13:52:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D554F12996E for ; Fri, 24 Mar 2017 13:52:15 -0700 (PDT)
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 autolearn_force=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 IB5QY9PfKFpb for ; Fri, 24 Mar 2017 13:52:14 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18CE129968 for ; Fri, 24 Mar 2017 13:52:13 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.lan (106.250.159.143.dyn.plus.net [143.159.250.106]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id E84471A071 for ; Fri, 24 Mar 2017 20:52:30 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: ULA Registration
From: Simon Hobson 
In-Reply-To: <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com>
Date: Fri, 24 Mar 2017 20:52:09 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com>
To: 6man WG 
X-Mailer: Apple Mail (2.1510)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 20:52:16 -0000

Alexandre Petrescu  wrote:

>> =46rom this discussion on another list, here is the count of ULA
>> registrations in the SixXS database.
>> +------+-------+
>> | Year | Count |
>> +------+-------+
>> | 2007 |    63 |
>> | 2008 |   140 |
>> | 2009 |   321 |
>> | 2010 |   611 |
>> | 2011 |   835 |
>> | 2012 |   742 |
>> | 2013 |   724 |
>> | 2014 |  1096 |
>> | 2015 |  1303 |
>> | 2016 |   640 |
>> | 2017 |   143 |
>> +------+-------+
>>=20
>> That is 6618 ULA block that were registered, that seems like that's =
more
>> than just a fad. Does this make a case for resurrecting the =
discussions
>> of ULA-C? I think it does.  But, what do others think?
>=20
> The numbers look impressive, with a glory period yet now declining. Or
> just momentarily declining to only grow bigger in the longer term.

The fall is consistent with SixXS having stopped taking new =
registrations towards the end of 2015. "business stops selling widgets, =
widget sales fall"


From nobody Fri Mar 24 14:08:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63F212871F for ; Fri, 24 Mar 2017 14:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hosted.ipng.nl header.b=hWFbzg2Q; dkim=pass (1024-bit key) header.d=ipng.nl header.b=Zxb70TuL
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 a8IVumgxZj8e for ; Fri, 24 Mar 2017 14:08:45 -0700 (PDT)
Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F4F128D2E for ; Fri, 24 Mar 2017 14:08:45 -0700 (PDT)
Received: by mail-ot0-x231.google.com with SMTP id y88so1323976ota.2 for ; Fri, 24 Mar 2017 14:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hosted.ipng.nl; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hrUCPeMvZt/qAQC+YNZ+KXTOLRrxKiRl8CbirZhlBc0=; b=hWFbzg2QZgXdZlLTt8B5MUv3fkviC9q4nO7zfnasNxQ9HNRGN44yYDRtsZLMKtlOBG 1KoENAdJRy+wnAzhg+b1hDK81Ifacy94HLRHqbnWoPAVkS9XuxpQqmu6/UTZWfRw+Q9M bNf8uyZKRjq0mnQZoJ5MB8pIEJBBaNhGcnuto=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipng.nl; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hrUCPeMvZt/qAQC+YNZ+KXTOLRrxKiRl8CbirZhlBc0=; b=Zxb70TuLyy8fjNgC/+LrCQtRFtjZf7el5C0yP0kvdG8qSEwop5wSEpsS2oVBk6LJys +R1UgPv566kLbUDNaDkVHm60+nDyyWy3yXC6OImlS3jPjHTy33FTzCRTDHR9YIQVO6z3 JJxrRW0h/g71DZ19RtAtu7LQGZh7sGV9FuIug=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hrUCPeMvZt/qAQC+YNZ+KXTOLRrxKiRl8CbirZhlBc0=; b=QyKV58gcd4B/Q09Tmwxge6cqE0p/3MHyAHmV6aoNxLJLF907855iMbPd3PgkMhFogR w5wocg2RdqzCaza2w7LgxxTKqNxfSC2f+CZ9gHhf9fugsLUoDdzifHSLnYg4HrYNZzEl /UF52m8hMpj4KWpYW57BUJA/kqoX73L5tsGA3GTWTEkFENCeJEE7oI3lT3r/00wpvcxD fUxb1F92tqdUz2CZMbSrKVIJT1HWVo20/KucRyWkR5zerLNBqBPzDVTNiXSVPjl0pPWS y2YxEdqz6bLPpk2DA10sJYsV2UiCRApMl6K7AN/xtPQ0FVCfY06nWZnsF0Deglbgg24Z JFdg==
X-Gm-Message-State: AFeK/H2z7EbT6828fPtC/mhLxcGsMpoQj0ti1C3P/A5/54+GZk+qJ+FKHv4rQMAeDlxaJlbqiyj5AC/dkGEiRw==
X-Received: by 10.157.25.18 with SMTP id j18mr5334675ota.128.1490389724520; Fri, 24 Mar 2017 14:08:44 -0700 (PDT)
MIME-Version: 1.0
Sender: pim@hosted.ipng.nl
Received: by 10.202.105.209 with HTTP; Fri, 24 Mar 2017 14:08:44 -0700 (PDT)
In-Reply-To: 
References:  <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com> 
From: Pim van Pelt 
Date: Fri, 24 Mar 2017 22:08:44 +0100
X-Google-Sender-Auth: L168fVAKHWucyot3vFiqyZ2cUMs
Message-ID: 
Subject: Re: ULA Registration
To: Simon Hobson 
Cc: 6man WG 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 21:08:48 -0000

On Fri, Mar 24, 2017 at 9:52 PM, Simon Hobson  wrote:
>>> That is 6618 ULA block that were registered, that seems like that's more
>>> than just a fad. Does this make a case for resurrecting the discussions
>>> of ULA-C? I think it does.  But, what do others think?
>>
>> The numbers look impressive, with a glory period yet now declining. Or
>> just momentarily declining to only grow bigger in the longer term.
One other thing I'd question is the validity (not the correctness) of
the registrations. Of the 6618 registrations that Jeroen shared
earlier:
- 1066 are invalid, mostly because they are duplicates
- 2473 do not set organisation.
- 3982 do not set website.
- 2249 set neither website nor organisation.

While SixXS does not require website or organisation to be set, I
can't speak to the registrations that don't provide them. I took a
cursory look at the registered e-mail addresses used when registering,
not sure if there's much to learn from it, but JFYI 1127 were
gmail.com, 256 were howfunky.com, 159 were hotmail.com and any other
domain existed less than 100 times. So it does appear to me that the
e-mail addresses used are from a wide variety of users.

> The fall is consistent with SixXS having stopped taking new registrations towards the end of 2015. "business stops selling widgets, widget sales fall"
That's an interesting observation, Simon. It should not in principle
follow the SixXS userbase. If it does, that would imply that SixXS
users "also" registered an ULA while they were at it. I can't find any
data that shows this correlation, so I think it's accidental.

groet,
Pim
-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/


From nobody Fri Mar 24 16:05:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFB912762F; Fri, 24 Mar 2017 16:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.358
X-Spam-Level: 
X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 Gaew8qrTwwoA; Fri, 24 Mar 2017 16:05:27 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 57715120326; Fri, 24 Mar 2017 16:05:27 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (unknown [216.80.70.251]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 214791B017C3; Sat, 25 Mar 2017 01:02:41 +0000 (GMT)
Message-ID: <58D518EA.5000508@erg.abdn.ac.uk>
Date: Fri, 24 Mar 2017 13:02:34 +0000
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Bob Hinden 
CC: "tsv-area@ietf.org" ,  "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF ,  "draft-ietf-6man-rfc1981bis@ietf.org" 
Subject: Re: Last Call:  (Path MTU Discovery for IP version 6) to Internet Standard
References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com>  <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com>  <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu>  <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com>  <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com>  <58A33D08.4090505@erg.abdn.ac.uk> <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com>
In-Reply-To: <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 23:05:31 -0000

On 17/03/2017, 21:56, Bob Hinden wrote:
> Gorry,
>
> Thanks for the detailed review.
>
> Several of the reviews have suggested significant changes to this document.  The working group was trying to make a few changes to bring it into alignment with some changes to rfc2460bis (based on updating documents).  It was not attempting a major rewrite when advancing it to Internet Standard.  The alternative that the working group discussed was to file errata on RFC1981 and leave it to a future document update.
>
> I don’t think many of these changes can be done and still advance it to Internet Standard. If we can’t advance the current document, then the w.g. may want to just do the errata and withdraw the advancement request.  Of course, if people want to work on a revision of IPv6 Path MTU Discovery, it would be welcomed, but it won’t be able to advanced to Internet Standard.
>
> Comments below.
>
> Thanks,
> Bob
Thanks Bob,

I note  the question of status, but in this case, there's a lot happened 
in the Internet since this PS was first published, and much of this was 
in the transport area. Please see replies to comments below. I'm happy 
to discuss or refine text, if this helps.

Gorry
>> On Feb 14, 2017, at 9:23 AM, Gorry Fairhurst  wrote:
>>
>>
>> I have some late transport comments on this ID. The update seems to retain a lot of thinking that is really historical and I'd really encourage people to look again to making the document uptodate.
>>
>> Detailed comments follow.
>>
>> Best wishes,
>>
>> Gorry
>>
>> ----
>> The following text strikes me as a little odd in an update:
>> " Moreover, TCP implementations that follow the "slow-
>>    start" congestion-avoidance algorithm [CONG] typically calculate and
>>    cache several other values derived from the PMTU.  It may be simpler
>>    to receive asynchronous notification when the PMTU changes, so that
>>    these variables may be updated.â€
>> - A modern TCP caches at least some path information in the TCB, why start with this clause at all:
>> "Moreover, TCP implementations that follow the "slow start" congestion-avoidance algorithm [CONG] typically calculate andâ€
>> and simply replace this with something like:
>> "TCP implementations�
>> ——
> To clarify, you are suggesting to replace it with:
>
>     TCP implementations typically cache several other values derived
>     from the PMTU.  It may be simpler to receive asynchronous notification when
>     the PMTU changes, so that these variables may be updated.
> I think that is editorial, and OK to change.  The paragraph will read:
>
>     The TCP layer must track the PMTU for the path(s) in use by a
>     connection; it should not send segments that would result in packets
>     larger than the PMTU.  A simple implementation could ask the IP layer
>     for this value each time it created a new segment, but this could be
>     inefficient.  TCP implementation typically cache several other values
>     derived from the PMTU.  It may be simpler to receive asynchronous
>     notification when the PMTU changes, so that these variables may be
>     updated.
Thanks. Seems better, although I would suggest to revise this in this way:

    A packetization layer layer (e.g., TCP) must track the PMTU
    for the path(s) in use by a
    connection; it should not send segments that would result in packets
    larger than the PMTU, except to probe during PMTU discovery.
    A simple implementation could ask the IP layer
    for this value each time it created a new segment, but this could be
    inefficient.  An implementation typically caches other values
    derived from the PMTU.  It may be simpler to receive asynchronous
    notification when the PMTU changes, so that these variables may be
    also updated.

- This would fix typos, and also make the text relevant to transport protocols,
rather than only TCP. Which is I beleive the correct interpretation.

>> The following text also seems to not reflect a modern TCP stack:
>> " It is sufficient
>>    to treat this as any other dropped segment, and wait until the
>>    retransmission timer expires to cause retransmission of the segment.â€
>> (and following 3 paras).
>> Could this be replaced by text that does not exclude modern retransmission methods:
>> " It is sufficient
>>    to treat this in the same way as any other dropped segment, and
>>    will be recovered by normal retransmission methods.â€
> Yes, resulting in:
>
>     When a Packet Too Big message is received, it implies that a packet
>     was dropped by the node that sent the ICMP message.  It is sufficient
>     to treat this in the same way as any other dropped segment, and will
>     be recovered by normal retransmission methods.  If the Path MTU
>     Discovery process requires several steps to find the PMTU of the full
>     path, this could delay the connection by many round-trip times.
Good. Seems much better.
>
>> —
>> There is a block of text that describes retransmission triggered by ICMPv6.
>> Has this code been implemented in modern releases of TCP?:
>> "   Alternatively, the retransmission could be done in immediate response
>>    to a notification that the Path MTU has changed, but only for the
>>    specific connection specified by the Packet Too Big message.â€
>> - It seems to expose a number of attack vectors that really should not be exposed!!
> Are you suggesting remove this text?  Following this text, there are two notes.
>
I'd personally remove this and the notes (you decide) - more because it 
says think that it opens a can of worms about transport details that are 
largely beyond the scope of the document (such as whether to trust 
ICMPv6 as indications of actual loss, and how this interacts with 
re-packaging to a different segment size, congetsuon control, etc).

If the WG thinks retaining some text is good, I'd say (as a cautious 
transport person) that we should call out a warning to people doing 
transmissions...

OLD:
      If the new estimated PMTU is
       still wrong, the process repeats, and there is an exponential
       growth in the number of superfluous segments sent.
NEW:
      If the new estimated PMTU is
       still wrong, the process repeats, and there is an exponential
       growth in the number of superfluous segments sent.
       Retransmissions can increase network load in
       response to congestion, worsening that congestion.  Any
       packetization layer that uses retransmission is responsible for
      congestion control of its retransmissions.

If you wish, cite RFC8085 and RFC4821 to let people figure this out? 
(these 2 sentences come directly from RFC8085).
>> ---
>> The discussion of NFS may still be a reasonable historic example, but to be current it should really refer also to NFSv4/TCP as utlising the MTU discovery provided by TCP, since UDP-based NFS is no longer a key application.
>> —
> I was planning to update the reference to NFS to RFC7530.   I could add text that says something like:
The protocol changed though - so it's not just a replacement reference.

I think text should note that RFC7530 says NFS must be able to run over 
a congestion-controlled transport, such as TCP.
>     It is recommended that NFS running over TCP utilize the MTU discovery
>     provided by TCP.
>
> Other suggestions?
Maybe, you could say something like:
"RFC191 used NFS as an example of a UDP-based application that benefits 
from PMTU discovery. Since then RFC7530, states the supported transport 
layer between NFS
and IP must be an IETF standardized transport protocol that is specified 
to avoid
network congestion; such transports include TCP and the Stream Control 
Transmission Protocol (SCTP). In this case, the transport is itself 
responsible for determining and using an effective Path MTU, including 
implementing PMTU discovery when this is needed."

RFC8085 may well be a good place to point to say what is 
needed/desirable for PMTU for UDP applications, if you wish to say 
something about UDP.
>> There is no mention that paths including tunnels can eat ICMPv6 PTB messages on the tunnel segment, blackholing them, which prevents reaching the destination.
> As noted above, I think adding discussion about tunnels is out of scope of this effort.
I agree that new mechanisms are out of scope, I was hoping that a simple 
note on tunnels would be in the security considerations.

RFC8085 or draft-ietf-intarea-tunnels could be pointed to describe the 
implications of tunnels.
>> ---
>> I think the security consideration is naive!
> Suggestions?
"   In the first attack, the false message indicates a PMTU much smaller
    than reality.  This should not entirely stop data flow, since the
    victim node should never set its PMTU estimate below the IPv6 minimum
    link MTU.  It will, however, result in suboptimal performance."

So... In the case of the first attack, I still question whether this 
choice of words misrepresents the attack.
What if, the false message advertises ~1280 bytes, and the path uses a 
tunnel encapsulation transporting IPv6, then the PTB message can be 
basis for a straight DoS attack that does stop data flow?

I would recommend revising the security considerations (at least to 
something like):
"  In the first attack, the false message indicates a PMTU much smaller
    than reality.  In response, the
    victim node should never set its PMTU estimate below the IPv6 minimum
    link MTU. A sender that falsely reduces to this MTU would observe 
suboptimal performance."

- Although this skirts the problem.
>> This statement in particular seems to open DOS vulnerability:
>> "
>>   When a node receives a Packet Too Big message, it MUST reduce its
>>    estimate of the PMTU for the relevant path, based on the value of the
>>    MTU field in the message."
>> - Introdueces a significant vulnerability.  A rogue PTB message that reduces the PMTU to a minimum, can result in a path too small to carry an encapsulated packet. (Recently noted by Fernando Gont).
> Suggestions?
See below - and above.
>> Moreover, other layers view ICMP messages with suspicion and have long noted the need to check ICMP payload and match only packets that relate to actual 5-tuples in use (effectively reducing vulnerability to off-path attacks). For example, the Guidelines for UDP, rfc5405bis, state:
>>
>> " Applications SHOULD appropriately validate the payload of ICMP
>>    messages to ensure these are received in response to transmitted
>>    traffic (i.e., a reported error condition that corresponds to a UDP
>>    datagram actually sent by the application). …“
>> - clearly handling this in IP-layer tunnels can be troublesome, but that's a problem that should be described, not obscured.
> I could add something like the following as a new second paragraph in Section 4 Protocol Requirements:
>
>    Protocols SHOULD appropriately validate the payload of ICMPv6 PTB
>    messages to ensure these are received in response to transmitted
>    traffic (i.e., a reported error condition that corresponds to a UDP
>    datagram actually sent by the application).
>
> or similar.

That certainly is a nod in what I think is really the correct direction.
Probably /UDP/ should be /IPv6 packet/ given the context of this ID.
>
>> ——
>>
>> I’d finally  like to add my concerns about the understatement of the value of PLPMTUD, which seems to not reflect the recommendations to use this method:
>> “  It defines a method for Packetization Layer Path
>>    MTU Discovery (PLPMTUD) designed for use over paths where delivery of
>>    ICMP messages to a host is not assured.â€
>> This  seems under-stating the value and recommendations to deploy PLMTUD, compared with current transport-area recommendations, for instance, the UDP Guidelines provide much more on this important design consideration:
>
> The w.g. spent a lot of time on this paragraph.  The intent was to point to it, but not into detail of how it worked, nor make it a new requirement.  There was some discussion that adding more detail about the relationship between PTMUD and PLPMTUD in the ongoing update to IPv6 Node Requirements would be helpful.

I appreciate people have spent time trying to get the IPv6 
specifications progressed to standards status. This is a good effort, 
but I think just adding a nod in the introduction is rather feeble for 
soemthing now recommended. I think at least the security considerations 
should motivate the benefits of this approach (see next).
>> "   Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not
>>    rely upon network support for ICMP messages and is therefore
>>    considered more robust than standard PMTUD.  It is not susceptible to
>>    "black holing" of ICMP message.  To operate, PLPMTUD requires changes
>>    to the way the transport is used, both to transmit probe packets, and
>>    to account for the loss or success of these probes.  This updates not
>>    only the PMTU algorithm, it also impacts loss recovery, congestion
>>    control, etc.  These updated mechanisms can be implemented within a
>>    connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not a
>>    part of UDP, but this type of feedback is not typically present for
>>    unidirectional applications."
>>
>> ----
>>
>> The examples used in the definition of  "upper layer" and "link" also makes this document appear as historic, rather than a new RFC!
> As noted above, I think there would be support for a rewrite if some folks wanted to take that on.
Could the WG consider to also add the first two sentences to the 
security considerations?

Gorry

P.S. A few more out-dated statements abiut TCP, based on the way 
specific stacks work when the original was written:

- The phrase below needs to be removed also, since not all TCP stacks 
behave in this way anymore:
", which is always a multiple of the segment size"

- There was very specific detailis relating to 4.2BSD TCP 
implementations, which would have been better not being here.



From nobody Sun Mar 26 07:37:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51EE12940C for ; Sun, 26 Mar 2017 07:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dd_8KRPf7kIA for ; Sun, 26 Mar 2017 07:37:03 -0700 (PDT)
Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7201129451 for ; Sun, 26 Mar 2017 07:36:58 -0700 (PDT)
Received: by mail-it0-x242.google.com with SMTP id 76so6674573itj.0 for ; Sun, 26 Mar 2017 07:36:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XZQIVDdpvPDARiobMkQWJXUl0aIqsrm3orjoTepzztU=; b=guqdItUiW/alt2dX03uWx+qBYv1aOFjb4BUhXp6tupuRl0syV4FB6joL4Opa9gDQyT N5CT2ipzE3yXKNShR6ktLQvT+uVVXxx0BDVcSVKw2iv+G4uh3GaRlZwMR45BLwjPbIPa zNH+oZU6cNaNlL6t6/EsE9LCVc//dW1X8zQgcEk2uOjwDFaH8BuS2CRX3xM0mcEJ0cpK N4vMsemRpAYXK1dSYyh1n6oAA2ychcWsAwO3uuHjPi5zjyejLp4UOKxiie6ve9/ty1LK 8Be7KcvClQmafEapUJJsFmieHUwecA73h/a4jB64HGDR4BOvQyDkBgm/tTqLNo1Qt4Mj xg6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XZQIVDdpvPDARiobMkQWJXUl0aIqsrm3orjoTepzztU=; b=ldYdDdZSwZkyGcnhPv5Q/6VKIJh4sE+X9zXdlmNFh1yQ9/PxTqVohKfWOf9C0O4ExB Yw+CXK8o3uNPJ+GKZxhpFxEx+K4227qlxkU404q6ixKtDzX6EB0DFP11P3bJRR0kdS/m xRM4U/MCNmdrEtqG3bIb+BelwHx4eSw42AWMYdGvAf6aUti/0kEXQ7QgPTtGY1pHzY3T H6coxVZfvDwylsMzASgORlBHK4jZB7Br5+OmuKJSjpTIKYrMOQmk1xWXbvY5cYGFFOal R+P5BwtDqsPPJtTWaYElyKr6926a4s5UgJMDcvfMPbRAlaOv9KAq1TtqRBA1TUJZHpcy 5xPg==
X-Gm-Message-State: AFeK/H2kl20UPI5MKtxecyi2rnlGU1JyJmhMAIb/QUNhTKKG9yvnSrquuOqMMjrwPQFFjg==
X-Received: by 10.107.190.2 with SMTP id o2mr17055408iof.95.1490539017997; Sun, 26 Mar 2017 07:36:57 -0700 (PDT)
Received: from [172.20.4.255] (swissotel07.s.subnet.rcn.com. [216.80.61.6]) by smtp.gmail.com with ESMTPSA id m71sm3966518itg.14.2017.03.26.07.36.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 07:36:57 -0700 (PDT)
From: "Song Linjian (Davey)" 
Message-Id: <70EDF6B4-CCFB-45BE-A377-8EBD1C899231@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DB7C4736-70CB-4376-829D-18BEA4AB42AE"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: IETF: SixXS is shutting down
Date: Sun, 26 Mar 2017 09:36:56 -0500
In-Reply-To: 
Cc: ipv6@ietf.org, SixXS Staff 
To: Pim van Pelt 
References: 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Mar 2017 14:37:07 -0000

--Apple-Mail=_DB7C4736-70CB-4376-829D-18BEA4AB42AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=gb2312

Sigh! When people think IPv6 tunnel become a hinder of IPv6 deployment,  =
people in China still in the struggle of chicken and egg problem.=20

-Davey

> =D4=DA 2017=C4=EA3=D4=C224=C8=D5=A3=AC08:02=A3=ACPim van Pelt =
 =D0=B4=B5=C0=A3=BA
>=20
> Colleagues,
>=20
> In 1999, Jeroen and I started SixXS, a project which aimed to provide
> IPv6 connectivity to users who wanted to learn about the network
> protocol and gain experience operating IPv6 networks. Our vision was
> to facilitate migration to IPv6 in content and access providers.
>=20
> We were able to provide IPv6 to 50=A1=AF000+ individual users and =
companies
> in 140+ countries, using servers hosted at 40+ Internet providers in
> 30+ countries. We are incredibly proud of what we=A1=AFve accomplished
> together, and how many people have gotten to know all about IPv6 due
> to our combined efforts.
>=20
> We have completed a retrospective and rationale document, which
> details our experience developing and operating the SixXS tunnelbroker
> over the last 18 years. We have worked through our plans with the many
> dedicated ISPs that have been involved:
>=20
> https://www.sixxs.net/sunset/
>=20
> We have reached out to users recently, giving them 6 weeks to make
> alternative plans. We have chosen a somewhat symbolic date of
> 2017-06-06 to turn down the SixXS service. Our website will remain as
> a tombstone.
>=20
> Please feel free to pass this along to any group or list you feel
> would benefit from it, and reach out to  or to myself
> directly  if you have thoughts you=A1=AFd like to share
> between now and then.
>=20
> --=20
> Pim van Pelt 
> PBVP1-RIPE - http://www.ipng.nl/
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

------------------------------
Davey Song(=CB=CE=C1=D6=BD=A1)
BII Lab
songlinjian@gmail.com



--Apple-Mail=_DB7C4736-70CB-4376-829D-18BEA4AB42AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=gb2312

Sigh! When people think IPv6 tunnel become a hinder of IPv6 =
deployment,  people in China still in the struggle of chicken and =
egg problem. 

    -Davey

    =D4=DA=
 2017=C4=EA3=D4=C224=C8=D5=A3=AC08:02=A3=ACPim van Pelt <pim@ipng.nl> =
=D0=B4=B5=C0=A3=BA

    Colleagues,

    In =
1999, Jeroen and I started SixXS, a project which aimed to provide
    IPv6 connectivity to users who wanted to learn about the =
network
    protocol and gain experience operating IPv6 =
networks. Our vision was
    to facilitate migration to IPv6 =
in content and access providers.

    We were =
able to provide IPv6 to 50=A1=AF000+ individual users and companies
    in 140+ countries, using servers hosted at 40+ Internet =
providers in
    30+ countries. We are incredibly proud of =
what we=A1=AFve accomplished
    together, and how many people =
have gotten to know all about IPv6 due
    to our combined =
efforts.

    We have completed a retrospective =
and rationale document, which
    details our experience =
developing and operating the SixXS tunnelbroker
    over the =
last 18 years. We have worked through our plans with the many
    dedicated ISPs that have been involved:

    https://www.sixxs.net/sunset/

    We have reached out to users recently, giving them 6 weeks to =
make
    alternative plans. We have chosen a somewhat symbolic =
date of
    2017-06-06 to turn down the SixXS service. Our =
website will remain as
    a tombstone.

    Please feel free to pass this along to any group or list you =
feel
    would benefit from it, and reach out to =
<info@sixxs.net> or to myself
    directly =
<pim@ipng.nl> if you have thoughts you=A1=AFd like to share
    between now and then.

    -- 
    Pim van Pelt <pim@ipng.nl>
    PBVP1-RIPE - =
http://www.ipng.nl/

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

    

    ------------------------------
    Davey Song(=CB=CE=C1=D6=BD=A1)
    BII Lab
    songlinjian@gmail.com

    

    

    =

--Apple-Mail=_DB7C4736-70CB-4376-829D-18BEA4AB42AE--


From nobody Sun Mar 26 07:55:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93392129453 for ; Sun, 26 Mar 2017 07:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=massar.ch
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 pnCLxJrOYjq3 for ; Sun, 26 Mar 2017 07:55:19 -0700 (PDT)
Received: from bastion.ch.unfix.org (citadel.ch.unfix.org [IPv6:2001:1620:20b0::50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E121129447 for ; Sun, 26 Mar 2017 07:55:18 -0700 (PDT)
Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id EE4BB1004C426; Sun, 26 Mar 2017 14:55:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1490540117; bh=f1k9MfvCx8U4lo7O1SUIrXl8U3ApvuFo+IL8AN369oY=; h=Subject:References:To:Cc:From:Date:In-Reply-To; b=QakcJf0+y8/E2T+5qVsFITPLLLcKxU0hxILk4Mq8up2fOkCWUI3Etp2X9pbZXAVHC 1y6EzmEZQdYb4O0Fi4hsU93Dgl4sOYnXdJPp+7RhQ9PXBKhKyVHjsnN6A58fMEj5CZ hyjfyKBRmcwU3/mrwVFOl1pXcrgBbqRlHV5EmhM94QeWVd7eFiPngJRyNY/tRMa62L jhX4UGlMpLKmK4OExEbyMjPQlbbSjgMA0Y+YwhckWjybF0woF99QbEGDx240bMqg0X SzZ+k2bJDs2Dseshq3Ql5b3Y7qTBmJJ3omrAYzAywL8ttS636iVZ6nfJ0Z0eRO2hAd 1+B8VaaWX+XhQ==
Subject: Re: IETF: SixXS is shutting down
References:  <70EDF6B4-CCFB-45BE-A377-8EBD1C899231@gmail.com>
To: "Song Linjian (Davey)" , Pim van Pelt 
Cc: ipv6@ietf.org, SixXS Staff 
From: Jeroen Massar 
Organization: Massar Networking
Message-ID: <635f4330-eae5-ad47-f4d5-da1402393993@massar.ch>
Date: Sun, 26 Mar 2017 16:55:13 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <70EDF6B4-CCFB-45BE-A377-8EBD1C899231@gmail.com>
Content-Type: text/plain; charset=gbk
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Mar 2017 14:55:22 -0000

On 2017-03-26 16:36, Song Linjian (Davey) wrote:
> Sigh! When people think IPv6 tunnel become a hinder of IPv6 deployment,
>  people in China still in the struggle of chicken and egg problem. 

Please explain more about your "chicken and egg problem" and how the
last 20 years of IPv6 deployment have not addressed those problems.

Greets,
 Jeroen



From nobody Sun Mar 26 12:52:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13B61296A3 for ; Sun, 26 Mar 2017 12:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 bavp3nUvjN8v for ; Sun, 26 Mar 2017 12:52:38 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E25912969B for <6man@ietf.org>; Sun, 26 Mar 2017 12:52:38 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id d188so32220894vka.0 for <6man@ietf.org>; Sun, 26 Mar 2017 12:52:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CqcdR3HUd4Mo/VJ7+J7Gx9SW0dPqzSFP5s+P0Zmvk7M=; b=PtNHA3Z/3mDkyXGiU94aqZRaUt1aKVDOx7PJENoIuqzQfHJp4gZVJCV9k07LZ+kp+g rabUiaBh1nXM4AKLCVff7xVRE1zfr3QAiLpJtLDNpctaum5QM6qpPigoTKlKAFk1BEPj ibTyw0Pc0loal7YzwuUi+mqV9ToGFofmPEIJZ23Ur6+FWdp1o3dkTFLJUZUPF8Lt0rKz QpUtad7RkMcna7YI0wjGx71ShjSC+es37f8lW3V4tDySFv0+eJ3uAfdTraa/HYz0+16D I+J4JIr7QAO1fDLH/gSn+nJ8nqzHfJIwtl6OCdquFPnvqgf6st10nfRJgmzVb+n2k8j1 x0YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CqcdR3HUd4Mo/VJ7+J7Gx9SW0dPqzSFP5s+P0Zmvk7M=; b=LQyKRP0p5IFlh6RrijLvUTAkrVrzSgDF0SyjMCHkiN2F7YL+U5jaG3D3a8V2MApapK UpwmaB+OcWnRCH23Znt0naDfe+eMApV257TDGif8VoUdShYjVbSes3HeVzbAEFq7RC16 gt8zw1oNvdb2Bk+An6zh/Vti57euscv/vk4rEEYyyJ66qgKnykE1s4lVxdHl6X559dZ3 yIHfDTdtXXLyAHse/QLePJ0F5hyAx7pb5OtKjbbJuQRJ9Q+a7vz3MEE2zk0dJ0Opymwp 53Td/Wog0mCB21w4OEmR85oU5hLYc9B8hfHG0r9rMphKrXKPR/E5C2GOky8jugBPtqKl AyEQ==
X-Gm-Message-State: AFeK/H0otrxwv0bfm5EehOtcjuTUBFc2RB5cmFYPZTk38AZk7++L/eF9KJ8liBi/72LjPeHf+Zy56ebR4rCOaQ==
X-Received: by 10.31.15.82 with SMTP id 79mr7929199vkp.156.1490557957630; Sun, 26 Mar 2017 12:52:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.181 with HTTP; Sun, 26 Mar 2017 12:52:07 -0700 (PDT)
In-Reply-To: <4deb5200-0f4f-d3d1-b164-e70fabc77d86@si6networks.com>
References: <148942937853.9227.2944252822855237301.idtracker@ietfa.amsl.com>   <4deb5200-0f4f-d3d1-b164-e70fabc77d86@si6networks.com>
From: Mark Smith 
Date: Mon, 27 Mar 2017 06:52:07 +1100
Message-ID: 
Subject: Re: "Recommendation on Temporary IPv6 Interface Identifiers" (revised I-D) (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-01.txt)
To: Fernando Gont 
Cc: "6man@ietf.org" <6man@ietf.org>, draft-gont-6man-non-stable-iids@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Mar 2017 19:52:41 -0000

Hi Fernando,

Sorry not to get back to you sooner.

Comments below,  bits I can't add to.


On 17 March 2017 at 03:35, Fernando Gont  wrote:
> Hi, Mark,
>
> Thanks so much for your feedback! Please find my comments in-line...
>
>

>
>> "  4.  The resulting interface identifiers MUST NOT embed layer-2
>>        identifiers (e.g.  MAC addresses)."
>>
>> perhaps add,
>>
>> "to prevent correlation between IPv6 IIDs and MAC addresses, when an
>> outside entity has been able to record both."
>
> Yes, there's also the fact that:
>
> 1) We cannot be assured that the randomization of the underlying MAC
> address is good enough
> 2) if the IIDs are 64-bit long, and the mac addresses are 48-bit long,
> you still need to randomize those remaining 16 bits... so there's no
> point in setting pieces of the IID differently
> 3) Another way to think about this is "compartmentalization": if you
> embed an ID from a layer below 8when you don't need to), if you screw up
> with how you generate it, the problem is exacerbated.
> 4) etc.
>
> I'm not sure whether to delve into all these details here, or just
> simply provide references to the reader, as we're currently doing. That
> is, the reuse of identifiers is well-covered in e.g.
> draft-gont-predictable-numeric-ids-00... and if we start to elaborate
> the reasons, the discussion will be incomplete or we will end up
> embedding such I-D into this one...
>
> Thoughts?
>
>

I don't think it is worth dealing with the details here either. Just a
simple "do this because of this broad/fundamental reason" should be
enough.



>
>> "Having a variable maximum lifetime prevents
>>    an observer from synchronizing with the temporary address
>>    regeneration; that is, from being able to expect when address will be
>>    regenerated, and thus infer that one newly observed addresses is the
>>    result of regenerating a previously observed one."
>>
>> This draft seems to be going a bit further in this direction (in a
>> good way) than RFC4941 does (based on my brief reading of "3.5.
>> Regeneration of Randomized Interface Identifiers") RFC4941 seems to
>> have either host or interface universal values
>> (TEMP_PREFERRED_LIFETIME: 1day, TEMP_VALID_LIFETIME:1 week) for the
>> maximum lifetimes of temporary addresses. It looks to be focusing on
>> avoiding synchronised address changes across clients rather than
>> across addresses within a client.
>
> We're certainly going further than RFC4941: that's intentional.

OK. My interpretation was that the only change being made to RFC4941
was to drop the statement or a requirement that temporary addresses
were companions to stable addresses, rather than going further than
that.

> The goal
> of this requirement is to avoid the regeneration of a temporary address
> to become obvious to an observer -- because if it is obvious, there's no
> point in regenerating the temporary addresses.
>
>
>
>> "That is, a host that de-
>>    attaches from a network and subsequently re-attaches to a (possibly
>>    different) network should regenerate all of its temporary addresses."
>>
>> RFC4941 only very briefly deals with this scenario.
>
> IIRC, research had found that RFC4941 implementations were failing in
> this area.
>
>
>> I agree with doing
>> it, however I think there is a risk of a DoS on the link or similar if
>> an interface starts failing, and disconnects/re-connects rapidly. I
>> think there should be some prevention against this e.g., multiple
>> disconnects/connects within 3 seconds indicates the interface is
>> failing and regeneration of temporary addresses should not take place
>> if this occurs.
>
> I agree with you. There should certainly be some sort of limit. The
> specific value (e.g., multiple disconnects in X time) is less
> important... but the document should probably at least mention this and
> suggest some limit here.
>

Yes, I would see that as one of the further updates to RFC4941.




>
>> Regarding using the MAC_Address,
>>
>> "Employing the MAC address in this expression (in replacement of the
>> Net_Iface parameter of the expression in RFC7217) means that the
>> re-generation of a randomized MAC address will result in a different
>> temporary address."
>>
>> it isn't clear to me whether randomised MAC addresses is a requirement
>> or a recommendation when using this algorithm. With it replacing
>> Net_Iface, it seems to be leaning towards a requirement.
>
> Your question/concern is certainly valid.
>
> Rationale: In RFC7217, you want a Net_Iface that is as stable as
> possible (and the MAC address might not be the best choice in such
> case). For temporary addresses, as long as Net_Iface uniquely identifies
> an interface, it's okay. You could certainly use anything (e.g., still
> use the interface name or interface index) for the generation of
> temporary addresses. However, if you use the MAC address, one property
> comes for free: if you happen to implement mac address randomization,
> you can be assured that whenever you regenerate an IPv6 address (after
> the mac address has been regenerated), the ipv6 address is going to change.
>
> FWIW, so far the I-D does not say much regarding whether you should do
> mac address randomization or not...
>

I think for the purposes of the algorithm, it would be good to state
whether randomised MACs are desirable or don't really matter.



Regards,
Mark.


From nobody Sun Mar 26 14:21:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0941296A4 for ; Sun, 26 Mar 2017 14:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 uNKP27Tb-bcw for ; Sun, 26 Mar 2017 14:21:24 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF29126BF0 for ; Sun, 26 Mar 2017 14:21:24 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id v76so20033740ywg.0 for ; Sun, 26 Mar 2017 14:21:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2cCcikgyLuGqSJZgXF5zLi/QJ8Lq9v2KLLnksThu2yI=; b=oi77QRlLOlLHnkHZXvuiIN+WjuKEnp750/mOuhMhDENKtNWk+4AN8tcS6P5ZaCxyD+ 3RkXjadHFp0hTYa+xVeZ3vW4tFTrfSjn+T9ujBpih9GehzvslCAf2VauF94opcrajt5H aXk08UfDgqG7NyKP1j7GT9LmFU0movkMoFkmdzRavzopLOKE3NHuZ2NjylvqkD0Z6foC ii/e8Ff5/cmI4DZyrBYsnODZzLkVQd9BtqDxxVQwrjTbSmf7NC9sfbdSFZrkQ1vcq6Ds +OqYk4tXQDOVOouMXO6cZiUH71Plz4bt3OWAVtTPcEiqwhBcwisIvG0TvLJg40DdTqls FlxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2cCcikgyLuGqSJZgXF5zLi/QJ8Lq9v2KLLnksThu2yI=; b=OcXMip96iFAEq0pIrmMh/1t4pZjIi06aHQb2dj63iLWwtOLQrbu6T1PGoIL/UWugLK S6kB0AZ9mbIRoMp6XDnap3UTtw/Hgil2XB7IEXgE4QA1SYVpSmTvBEzT+mFx+HOUOlE7 SqXZNqXEnASlzc1p+pHoFpojjBtvHHLdb4Q/XDVw+a8hiBBdA7noWds8Y2j0cyXrgbg4 ZE5x1zluZsY0TMkguf9R8VASektz5Ikx6EsxiT5qfCeFOBWED6Xm7yrR68I+PCx1zkzr /CzlTU7ahSKNXcnPNB5ffxqqe0RuohlLJ49wVR/n2K/MLutBICYTKlAaDELSPIVkdrwM VR0g==
X-Gm-Message-State: AFeK/H0whw0lLX6PBNxK2btHZ7a9YCdm2l8mM4vuktBjJ+rGDuihRNgmH1A26cBNszQKJ5pQYc0vlQwyfPBqbnqo
X-Received: by 10.37.88.212 with SMTP id m203mr14673666ybb.27.1490563283002; Sun, 26 Mar 2017 14:21:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.50.7 with HTTP; Sun, 26 Mar 2017 14:21:02 -0700 (PDT)
In-Reply-To: <1E2BE958-3186-4201-92B6-FB7A5EB59D5C@google.com>
References:  <7c4412a4-6494-961d-165b-9c5d267015a7@gmail.com> <39db830bd4d04faca308c01d0d39b8ae@XCH15-06-11.nw.nos.boeing.com>  <1E2BE958-3186-4201-92B6-FB7A5EB59D5C@google.com>
From: Erik Kline 
Date: Sun, 26 Mar 2017 14:21:02 -0700
Message-ID: 
Subject: Re: ULA clashes don't matter [Re: ULA Registration]
To: james woodyatt 
Cc: 6man WG 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113fc6b8083683054ba8cf06"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Mar 2017 21:21:26 -0000

--001a113fc6b8083683054ba8cf06
Content-Type: multipart/alternative; boundary=001a113fc6b8001b1d054ba8cf73

--001a113fc6b8001b1d054ba8cf73
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Agreed.

The doc is clear about what is required in order to minimize the chance of
collision.

In the inevitable event two non-randomly generated fd00:: networks merge,
that's their problem.  If this situation were to be cited as a motivation
for standards action, the correct answer IMHO is "they're doing it wrong;
not the IETF's problem".

On 24 March 2017 at 13:31, james woodyatt  wrote:

> On Mar 24, 2017, at 11:37, Brian E Carpenter 
> wrote:
>
>
> Do I need to justify that? Oh, OK: [=E2=80=A6]
>
>
> 4. In the event of the simultaneous merge of a sufficient number of
> ULA-numbered networks that the statistical chance of Global ID collisions
> arising would approach a significant level, the entity performing that
> merge can make its own private arrangements to manage the numbering
> requirements for the merge. For one thing, there is no apparent and
> immediate need for a public service to do it, and for another, establishi=
ng
> a registry is not obviously the best way to construct such a service in t=
he
> event the need arises for one in the unforeseeable future.
>
> --james woodyatt 
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

--001a113fc6b8001b1d054ba8cf73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Agreed.

    The doc is clear about what is =
required in order to minimize the chance of collision.

    =

    In the inevitable event two non-randomly generated fd00:: networks mer=
ge, that's their problem.=C2=A0 If this situation were to be cited as a=
 motivation for standards action, the correct answer IMHO is "they'=
;re doing it wrong; not the IETF's problem".

    On 24 March 2017 at 13:31, =
james woodyatt <jhw@google.com> wrote:
    On Mar 24, 2017, at 11:37, Br=
ian E Carpenter <brian.e.carpenter@gmail.com> wrote:

    Do I need to justify that? Oh, OK: [=E2=80=A6]

    4. In the event of the simultaneous merge of a su=
fficient number of ULA-numbered networks that the statistical chance of Glo=
bal ID collisions arising would approach a significant level, the entity pe=
rforming that merge can make its own private arrangements to manage the num=
bering requirements for the merge. For one thing, there is no apparent and =
immediate need for a public service to do it, and for another, establishing=
 a registry is not obviously the best way to construct such a service in th=
e event the need arises for one in the unforeseeable future.

    

    --james woodyatt <jhw@google.com>


    


    


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


    

--001a113fc6b8001b1d054ba8cf73--

--001a113fc6b8083683054ba8cf06
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy
MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L
KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N
LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7
oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8
kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm
MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo
dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud
DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg
PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i
YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh
bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX
iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S
toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2
/5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c
UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw
jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgAO8SRZ3lt9bUN6+BVX4fpgtylSu5uUp5
N+LtZ1NeUbowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzI2
MjEyMTIzWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAJ4345Rwtt6n/xXqDd8L6SfQwEZqDE/0/VpM9ma9VBDvdA/pS+jP
hYnA5url4vWlrLcRpn7YOrxUp3RAa1eTquHVaG9Dawys6spN1sghgmsuiy4ke66Z11OXvMgip6b8
yjpdDiEPTREh54sZGG2KzgPHDcPDi24NVmPwavvF6Wr1zs3hTSsCB6Np8d4lvvxumncFg9w5+UJq
t+0t9iDgFNArMhLCSqe52kOcIpAa+zDu7tYQx5TDhHM+JtXrTbHrka1W9NB5ReF4YTMnTtiEcNiB
l3TBVJ4F8cGa/FkQOfYEHPCHoS6FmNF68Fj6V+dApf+nSLVz3jbYQq0SRvC8GFU=
--001a113fc6b8083683054ba8cf06--


From nobody Sun Mar 26 14:23:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18840127871; Sun, 26 Mar 2017 14:23:03 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QJvoAqKwZy7z; Sun, 26 Mar 2017 14:23:00 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D3E126BF0; Sun, 26 Mar 2017 14:23:00 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id u1so30186156wra.2; Sun, 26 Mar 2017 14:23:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NLt274xY80wnDd8Lx3qrFJnF65/i8bPr1S8zWExwSVY=; b=Hp61IQgzzkepINfuBAkrwRlOqXMuwkUXyFVc5juv10ABPtoSL+LFKT8tiVMMAptJBC 8GdoFUJmsPfX0+1k+L72aN2t+YpaUsnLh3dT8YppdwsPrqpLObf5ayj/lAqFeJuPpctc MFAjLSMk3vVgohx84Cw2fcFK0hfRQqGVXjNlvfElEOpoPAKoofCdgaaEjwnuU5E+kGGD CL5eN9xnfSVb/7jZ1nlIDzRlGDumw8yIqGPbtC9lTr5JD4SXN0705p26yV+PhfCR4lts HYRNyws2+/kOIVqjN/7rFzwLlkibkijboGLTsDDLpEOfN34dRxZ1B2tUNb2VrhNVTF8S c+Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NLt274xY80wnDd8Lx3qrFJnF65/i8bPr1S8zWExwSVY=; b=cXLdc4yTtxgl8nfh7CHdpArBZp9FMurLS4ExTQgJKP+tYWlaTMe7BAEnqcGJZnSwJ2 pFQE0tioIDLhEoRQ6NlKvUzRtSTLyHb2kNx8Pj4CUGBW6pYCg4G6umUxweuDYSXR3+se NAOIxtWg01T0D83/Sso7TvZ8fZtFMNM8SasXam7De/vccvYnXqy8I9uri1XotlMMS56y wcJ3LSK5h6D77mmcmBEJ/E19nv/MpBiOBskrBZogxoPvypKqlS793DtxU1s8IQTrGF0X 1o1UUo4k8qIXUWWVC/uf/LowSAxGJK1NBgWGtOpDTpfyv2njAYzFWmEIFTo0StUcjADv MRsQ==
X-Gm-Message-State: AFeK/H01xpv6CYhJeDqVEaba9gh0UiON/hiED9MCpBfPGbmo97hRQI0hJ+cULht650CM9Q==
X-Received: by 10.28.11.130 with SMTP id 124mr6916926wml.3.1490563378478; Sun, 26 Mar 2017 14:22:58 -0700 (PDT)
Received: from dhcp-9201.meeting.ietf.org (dhcp-9201.meeting.ietf.org. [31.133.146.1]) by smtp.gmail.com with ESMTPSA id l21sm12180619wrl.59.2017.03.26.14.22.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 14:22:56 -0700 (PDT)
From: Bob Hinden 
Message-Id: <4BC1763E-9D76-4EAA-B0B4-35620421736B@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_BA125144-D743-4BD9-923D-DD79D54571BC"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call:  (Path MTU Discovery for IP version 6) to Internet Standard
Date: Sun, 26 Mar 2017 16:22:51 -0500
In-Reply-To: <58D518EA.5000508@erg.abdn.ac.uk>
Cc: Bob Hinden , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF , "draft-ietf-6man-rfc1981bis@ietf.org" 
To: gorry@erg.abdn.ac.uk
References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com>  <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com>  <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu>  <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com>  <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com>  <58A33D08.4090505@erg.abdn.ac.uk> <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> <58D518EA.5000508@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Mar 2017 21:23:03 -0000

--Apple-Mail=_BA125144-D743-4BD9-923D-DD79D54571BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Gorry,

> On Mar 24, 2017, at 8:02 AM, Gorry Fairhurst  =
wrote:
>=20
> On 17/03/2017, 21:56, Bob Hinden wrote:
>> Gorry,
>>=20
>> Thanks for the detailed review.
>>=20
>> Several of the reviews have suggested significant changes to this =
document.  The working group was trying to make a few changes to bring =
it into alignment with some changes to rfc2460bis (based on updating =
documents).  It was not attempting a major rewrite when advancing it to =
Internet Standard.  The alternative that the working group discussed was =
to file errata on RFC1981 and leave it to a future document update.
>>=20
>> I don=E2=80=99t think many of these changes can be done and still =
advance it to Internet Standard. If we can=E2=80=99t advance the current =
document, then the w.g. may want to just do the errata and withdraw the =
advancement request.  Of course, if people want to work on a revision of =
IPv6 Path MTU Discovery, it would be welcomed, but it won=E2=80=99t be =
able to advanced to Internet Standard.
>>=20
>> Comments below.
>>=20
>> Thanks,
>> Bob
> Thanks Bob,
>=20
> I note  the question of status, but in this case, there's a lot =
happened in the Internet since this PS was first published, and much of =
this was in the transport area. Please see replies to comments below. =
I'm happy to discuss or refine text, if this helps.

Comments below.  Let=E2=80=99s get together and go over the document =
while we are in Chicago.  I want to make sure the changes are made =
correctly and in context.

Thanks,
Bob

>=20
> Gorry
>>> On Feb 14, 2017, at 9:23 AM, Gorry Fairhurst  =
wrote:
>>>=20
>>>=20
>>> I have some late transport comments on this ID. The update seems to =
retain a lot of thinking that is really historical and I'd really =
encourage people to look again to making the document uptodate.
>>>=20
>>> Detailed comments follow.
>>>=20
>>> Best wishes,
>>>=20
>>> Gorry
>>>=20
>>> ----
>>> The following text strikes me as a little odd in an update:
>>> " Moreover, TCP implementations that follow the "slow-
>>>   start" congestion-avoidance algorithm [CONG] typically calculate =
and
>>>   cache several other values derived from the PMTU.  It may be =
simpler
>>>   to receive asynchronous notification when the PMTU changes, so =
that
>>>   these variables may be updated.=E2=80=9D
>>> - A modern TCP caches at least some path information in the TCB, why =
start with this clause at all:
>>> "Moreover, TCP implementations that follow the "slow start" =
congestion-avoidance algorithm [CONG] typically calculate and=E2=80=9D
>>> and simply replace this with something like:
>>> "TCP implementations=E2=80=9D?
>>> =E2=80=94=E2=80=94
>> To clarify, you are suggesting to replace it with:
>>=20
>>    TCP implementations typically cache several other values derived
>>    from the PMTU.  It may be simpler to receive asynchronous =
notification when
>>    the PMTU changes, so that these variables may be updated.
>> I think that is editorial, and OK to change.  The paragraph will =
read:
>>=20
>>    The TCP layer must track the PMTU for the path(s) in use by a
>>    connection; it should not send segments that would result in =
packets
>>    larger than the PMTU.  A simple implementation could ask the IP =
layer
>>    for this value each time it created a new segment, but this could =
be
>>    inefficient.  TCP implementation typically cache several other =
values
>>    derived from the PMTU.  It may be simpler to receive asynchronous
>>    notification when the PMTU changes, so that these variables may be
>>    updated.
> Thanks. Seems better, although I would suggest to revise this in this =
way:
>=20
>   A packetization layer layer (e.g., TCP) must track the PMTU
>   for the path(s) in use by a
>   connection; it should not send segments that would result in packets
>   larger than the PMTU, except to probe during PMTU discovery.
>   A simple implementation could ask the IP layer
>   for this value each time it created a new segment, but this could be
>   inefficient.  An implementation typically caches other values
>   derived from the PMTU.  It may be simpler to receive asynchronous
>   notification when the PMTU changes, so that these variables may be
>   also updated.
>=20
> - This would fix typos, and also make the text relevant to transport =
protocols,
> rather than only TCP. Which is I beleive the correct interpretation.

I think that=E2=80=99s good.  I will require some other changes to the =
Section that is titled "TCP layer action=E2=80=9D, let=E2=80=99s discuss =
this later.

>=20
>>> The following text also seems to not reflect a modern TCP stack:
>>> " It is sufficient
>>>   to treat this as any other dropped segment, and wait until the
>>>   retransmission timer expires to cause retransmission of the =
segment.=E2=80=9D
>>> (and following 3 paras).
>>> Could this be replaced by text that does not exclude modern =
retransmission methods:
>>> " It is sufficient
>>>   to treat this in the same way as any other dropped segment, and
>>>   will be recovered by normal retransmission methods.=E2=80=9D
>> Yes, resulting in:
>>=20
>>    When a Packet Too Big message is received, it implies that a =
packet
>>    was dropped by the node that sent the ICMP message.  It is =
sufficient
>>    to treat this in the same way as any other dropped segment, and =
will
>>    be recovered by normal retransmission methods.  If the Path MTU
>>    Discovery process requires several steps to find the PMTU of the =
full
>>    path, this could delay the connection by many round-trip times.
> Good. Seems much better.

Good.

>>=20
>>> =E2=80=94
>>> There is a block of text that describes retransmission triggered by =
ICMPv6.
>>> Has this code been implemented in modern releases of TCP?:
>>> "   Alternatively, the retransmission could be done in immediate =
response
>>>   to a notification that the Path MTU has changed, but only for the
>>>   specific connection specified by the Packet Too Big message.=E2=80=9D=

>>> - It seems to expose a number of attack vectors that really should =
not be exposed!!
>> Are you suggesting remove this text?  Following this text, there are =
two notes.
>>=20
> I'd personally remove this and the notes (you decide) - more because =
it says think that it opens a can of worms about transport details that =
are largely beyond the scope of the document (such as whether to trust =
ICMPv6 as indications of actual loss, and how this interacts with =
re-packaging to a different segment size, congetsuon control, etc).
>=20
> If the WG thinks retaining some text is good, I'd say (as a cautious =
transport person) that we should call out a warning to people doing =
transmissions...
>=20
> OLD:
>     If the new estimated PMTU is
>      still wrong, the process repeats, and there is an exponential
>      growth in the number of superfluous segments sent.
> NEW:
>     If the new estimated PMTU is
>      still wrong, the process repeats, and there is an exponential
>      growth in the number of superfluous segments sent.
>      Retransmissions can increase network load in
>      response to congestion, worsening that congestion.  Any
>      packetization layer that uses retransmission is responsible for
>     congestion control of its retransmissions.
>=20
> If you wish, cite RFC8085 and RFC4821 to let people figure this out? =
(these 2 sentences come directly from RFC8085).

Ok, I think that works.

>>> ---
>>> The discussion of NFS may still be a reasonable historic example, =
but to be current it should really refer also to NFSv4/TCP as utlising =
the MTU discovery provided by TCP, since UDP-based NFS is no longer a =
key application.
>>> =E2=80=94
>> I was planning to update the reference to NFS to RFC7530.   I could =
add text that says something like:
> The protocol changed though - so it's not just a replacement =
reference.
>=20
> I think text should note that RFC7530 says NFS must be able to run =
over a congestion-controlled transport, such as TCP.
>>    It is recommended that NFS running over TCP utilize the MTU =
discovery
>>    provided by TCP.
>>=20
>> Other suggestions?
> Maybe, you could say something like:
> "RFC191 used NFS as an example of a UDP-based application that =
benefits from PMTU discovery. Since then RFC7530, states the supported =
transport layer between NFS
> and IP must be an IETF standardized transport protocol that is =
specified to avoid
> network congestion; such transports include TCP and the Stream Control =
Transmission Protocol (SCTP). In this case, the transport is itself =
responsible for determining and using an effective Path MTU, including =
implementing PMTU discovery when this is needed.=E2=80=9D


>=20
> RFC8085 may well be a good place to point to say what is =
needed/desirable for PMTU for UDP applications, if you wish to say =
something about UDP.

Thanks, I think that works.  Not sure if the other paragraphs on NFS =
should remain.


>>> There is no mention that paths including tunnels can eat ICMPv6 PTB =
messages on the tunnel segment, blackholing them, which prevents =
reaching the destination.
>> As noted above, I think adding discussion about tunnels is out of =
scope of this effort.
> I agree that new mechanisms are out of scope, I was hoping that a =
simple note on tunnels would be in the security considerations.
>=20
> RFC8085 or draft-ietf-intarea-tunnels could be pointed to describe the =
implications of tunnels.
>>> ---
>>> I think the security consideration is naive!
>> Suggestions?
> "   In the first attack, the false message indicates a PMTU much =
smaller
>   than reality.  This should not entirely stop data flow, since the
>   victim node should never set its PMTU estimate below the IPv6 =
minimum
>   link MTU.  It will, however, result in suboptimal performance."
>=20
> So... In the case of the first attack, I still question whether this =
choice of words misrepresents the attack.
> What if, the false message advertises ~1280 bytes, and the path uses a =
tunnel encapsulation transporting IPv6, then the PTB message can be =
basis for a straight DoS attack that does stop data flow?
>=20
> I would recommend revising the security considerations (at least to =
something like):
> "  In the first attack, the false message indicates a PMTU much =
smaller
>   than reality.  In response, the
>   victim node should never set its PMTU estimate below the IPv6 =
minimum
>   link MTU. A sender that falsely reduces to this MTU would observe =
suboptimal performance."
>=20
> - Although this skirts the problem.

OK, I agree this is better.

>>> This statement in particular seems to open DOS vulnerability:
>>> "
>>>  When a node receives a Packet Too Big message, it MUST reduce its
>>>   estimate of the PMTU for the relevant path, based on the value of =
the
>>>   MTU field in the message."
>>> - Introdueces a significant vulnerability.  A rogue PTB message that =
reduces the PMTU to a minimum, can result in a path too small to carry =
an encapsulated packet. (Recently noted by Fernando Gont).
>> Suggestions?
> See below - and above.
>>> Moreover, other layers view ICMP messages with suspicion and have =
long noted the need to check ICMP payload and match only packets that =
relate to actual 5-tuples in use (effectively reducing vulnerability to =
off-path attacks). For example, the Guidelines for UDP, rfc5405bis, =
state:
>>>=20
>>> " Applications SHOULD appropriately validate the payload of ICMP
>>>   messages to ensure these are received in response to transmitted
>>>   traffic (i.e., a reported error condition that corresponds to a =
UDP
>>>   datagram actually sent by the application). =E2=80=A6=E2=80=9C
>>> - clearly handling this in IP-layer tunnels can be troublesome, but =
that's a problem that should be described, not obscured.
>> I could add something like the following as a new second paragraph in =
Section 4 Protocol Requirements:
>>=20
>>   Protocols SHOULD appropriately validate the payload of ICMPv6 PTB
>>   messages to ensure these are received in response to transmitted
>>   traffic (i.e., a reported error condition that corresponds to a UDP
>>   datagram actually sent by the application).
>>=20
>> or similar.
>=20
> That certainly is a nod in what I think is really the correct =
direction.
> Probably /UDP/ should be /IPv6 packet/ given the context of this ID.

Good, I think that makes sense.

>>=20
>>> =E2=80=94=E2=80=94
>>>=20
>>> I=E2=80=99d finally  like to add my concerns about the =
understatement of the value of PLPMTUD, which seems to not reflect the =
recommendations to use this method:
>>> =E2=80=9C  It defines a method for Packetization Layer Path
>>>   MTU Discovery (PLPMTUD) designed for use over paths where delivery =
of
>>>   ICMP messages to a host is not assured.=E2=80=9D
>>> This  seems under-stating the value and recommendations to deploy =
PLMTUD, compared with current transport-area recommendations, for =
instance, the UDP Guidelines provide much more on this important design =
consideration:
>>=20
>> The w.g. spent a lot of time on this paragraph.  The intent was to =
point to it, but not into detail of how it worked, nor make it a new =
requirement.  There was some discussion that adding more detail about =
the relationship between PTMUD and PLPMTUD in the ongoing update to IPv6 =
Node Requirements would be helpful.
>=20
> I appreciate people have spent time trying to get the IPv6 =
specifications progressed to standards status. This is a good effort, =
but I think just adding a nod in the introduction is rather feeble for =
soemthing now recommended. I think at least the security considerations =
should motivate the benefits of this approach (see next).
>>> "   Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does =
not
>>>   rely upon network support for ICMP messages and is therefore
>>>   considered more robust than standard PMTUD.  It is not susceptible =
to
>>>   "black holing" of ICMP message.  To operate, PLPMTUD requires =
changes
>>>   to the way the transport is used, both to transmit probe packets, =
and
>>>   to account for the loss or success of these probes.  This updates =
not
>>>   only the PMTU algorithm, it also impacts loss recovery, congestion
>>>   control, etc.  These updated mechanisms can be implemented within =
a
>>>   connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not =
a
>>>   part of UDP, but this type of feedback is not typically present =
for
>>>   unidirectional applications."
>>>=20
>>> ----
>>>=20
>>> The examples used in the definition of  "upper layer" and "link" =
also makes this document appear as historic, rather than a new RFC!
>> As noted above, I think there would be support for a rewrite if some =
folks wanted to take that on.
> Could the WG consider to also add the first two sentences to the =
security considerations?

Sorry, which two sentences?

>=20
> Gorry
>=20
> P.S. A few more out-dated statements abiut TCP, based on the way =
specific stacks work when the original was written:
>=20
> - The phrase below needs to be removed also, since not all TCP stacks =
behave in this way anymore:
> ", which is always a multiple of the segment size"
>=20
> - There was very specific detailis relating to 4.2BSD TCP =
implementations, which would have been better not being here.
>=20
>=20

OK, I can remove both.





--Apple-Mail=_BA125144-D743-4BD9-923D-DD79D54571BC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJY2DEsAAoJEK7rdBF357uokT0H/2VCVMjQgoGMDl42peaiitp6
ZcL7MwA59BVUaHTv/fwR7FdHgSKZ5JwyQI/j2/fbriJSwxjb+FnPQO8194kkSSd4
mnrIpQnTxHfOczDRTwVuT1YLD5hNWj4R3sm8Ot+6qr7qm05DjjY4D32sj5LOq0eo
QRfwAW1N6kZZEEwCrDtQe4fClj5V7287V7o6GnMvSKLM6XoKS6l+BRwxUmX7v6fk
VFKpC7bqt1n4deud+dJKBuwP5lCBK3Ymij+tgn0NUh7kHD7c0uMBLsTngW9QsaFQ
uLshSCMuj5jkS8ebdbJxtj5+xqEXQ/1wNwkjGrJPIr0/cYCEOJj+ioXXbucgkqU=
=/Knx
-----END PGP SIGNATURE-----

--Apple-Mail=_BA125144-D743-4BD9-923D-DD79D54571BC--


From nobody Sun Mar 26 14:40:09 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0011296A4 for ; Sun, 26 Mar 2017 14:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WgJOSJKh4KGQ for ; Sun, 26 Mar 2017 14:40:06 -0700 (PDT)
Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3971D1286B1 for ; Sun, 26 Mar 2017 14:40:06 -0700 (PDT)
Received: by mail-pg0-x241.google.com with SMTP id 81so7420218pgh.3 for ; Sun, 26 Mar 2017 14:40:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bM7ZqaGzPIKJlSd5TZHHdSAJ40tRotG2Si2WuTCWGKA=; b=R/xynchJSgh8VZmNBzAGW1H0PKpU4xdlD5emYk4tYwz+oJ4fd+33OOksGyiysrLIXW yLQbpGIjTxFkIeXaR/PjEJl0zbA5JabtyoIralvnMW0yDV+ARh24ItzoNAxxlg7OIcBo ahShIi/c2O7rtjD7mvn/3G6cCyp2H6PSlqoyj9J9ToMHWMdLGaX2LBXy7rlahWXyD+Dp 4XisAJ42jd92zLU2+hY9m/wRtACY2sR1CDeBaKJvyecQizwTMFsftkKsR8ysuY/FmLJa /pyYl+C//N3/N5VfMTIeNhGr+oN1nD9xBaMsEHQMhe9zAD6UnBDBwnlBzq+4ajU4EtOH hOEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bM7ZqaGzPIKJlSd5TZHHdSAJ40tRotG2Si2WuTCWGKA=; b=G2uJaBLmrD+Dc0ht23NIL1TwCtySNy+3uP4ikF9xnkRx7F1+FfSQCTIpyKv+smMgcW HNQl6Zf5iGEBais5m2bwoDO5F1OKsc9N3tCc/o7Yxes08nsYqH4ce7alNo7yswdOZr68 hDm+TWGTv9c8bRkhAwqfvsWYl6JJ7cBu+PG+jPOMy/6m/R2KUzc0LUlhVYOtMD06fWy5 fu/oCzrNBIkL33AJC07NITOdok4mApgXYF6OuNXa1Sgo5o8ri7pTyHJThTarXPSw7mL/ 9d/0qIlXKnAPCORiXXMtbOrzFPd2uqOQVdBvWfNHhodHP2T9CH1aJnCXCgptowlJeNu/ zNkA==
X-Gm-Message-State: AFeK/H2N0ZUkz6W+IL9TQfNS5wh5+GNcuDYce/xIzzB0HJFCG9pyvecpbX9rbK2DlnJwcg==
X-Received: by 10.98.93.150 with SMTP id n22mr21932498pfj.103.1490564405778; Sun, 26 Mar 2017 14:40:05 -0700 (PDT)
Received: from t2001067c03700128cc479f04955eec1c.v6.meeting.ietf.org (t2001067c03700128cc479f04955eec1c.v6.meeting.ietf.org. [2001:67c:370:128:cc47:9f04:955e:ec1c]) by smtp.gmail.com with ESMTPSA id e16sm16560809pfb.102.2017.03.26.14.39.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 14:40:05 -0700 (PDT)
From: Song Linjian (Davey) 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_B401A76E-8875-4A71-89F2-D875CFE6A00C"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: IETF: SixXS is shutting down
Date: Sun, 26 Mar 2017 15:23:58 -0500
In-Reply-To: <635f4330-eae5-ad47-f4d5-da1402393993@massar.ch>
Cc: Pim van Pelt , ipv6@ietf.org, SixXS Staff 
To: Jeroen Massar 
References:  <70EDF6B4-CCFB-45BE-A377-8EBD1C899231@gmail.com> <635f4330-eae5-ad47-f4d5-da1402393993@massar.ch>
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Mar 2017 21:40:08 -0000

--Apple-Mail=_B401A76E-8875-4A71-89F2-D875CFE6A00C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=gb2312

Chicken and egg problem is the same :=20

ISP complains there is no content in IPv6, no requirement from user for =
IPv6 connection. ICP complains there is no IPv6 network and IPv6 user=20

China is different from India because it can not leap by taking the =
advantage of IPv6 development of big global ICPs, like Google , =
Facebook, and Youtube. Besides, most netizens in China do not consume =
much content in English. Most of people can live well without =
connections outside. So the only hope is on the local ICP like Baidu , =
Tencent and Alibaba. But the local ICP and ISP are in the early stage of =
Chicken and egg problem.

Most IPv6 stories from China are from research and academic network , =
and some pilots from Telcos supported by national IPv6 developing =
fundings. But They are for the purpose of research and demonstration of =
innovation ,not for commercial and productional purpose.

That=A1=AFs what I am sighing for.

Davey

> =D4=DA 2017=C4=EA3=D4=C226=C8=D5=A3=AC09:55=A3=ACJeroen Massar =
> =D0=B4=B5=C0=A3=BA
>=20
> On 2017-03-26 16:36, Song Linjian (Davey) wrote:
>> Sigh! When people think IPv6 tunnel become a hinder of IPv6 =
deployment,
>> people in China still in the struggle of chicken and egg problem.=20
>=20
> Please explain more about your "chicken and egg problem" and how the
> last 20 years of IPv6 deployment have not addressed those problems.
>=20
> Greets,
> Jeroen
>=20
>=20

------------------------------
Davey Song(=CB=CE=C1=D6=BD=A1)
BII Lab
songlinjian@gmail.com 



--Apple-Mail=_B401A76E-8875-4A71-89F2-D875CFE6A00C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=gb2312


    Chicken and egg problem is the same =
: 

    ISP =
complains there is no content in IPv6, no requirement from user for IPv6 =
connection. ICP complains there is no IPv6 network and IPv6 =
user 

    China is different =
from India because it can not leap by taking the advantage of IPv6 =
development of big global ICPs, like Google , Facebook, and Youtube. =
Besides, most netizens in China do not consume much content in English. =
Most of people can live well without connections outside. So the only =
hope is on the local ICP like Baidu , Tencent and Alibaba. But the local =
ICP and ISP are in the early stage of Chicken and egg problem.

    Most IPv6 stories from =
China are from research and academic network , and some pilots from =
Telcos supported by national IPv6 developing fundings. But They are for =
the purpose of research and demonstration of innovation ,not for =
commercial and productional purpose.

    That=A1=AFs what I am sighing =
for.

    Davey

    =D4=DA =
2017=C4=EA3=D4=C226=C8=D5=A3=AC09:55=A3=ACJeroen Massar <jeroen@massar.ch> =
=D0=B4=B5=C0=A3=BA

    On 2017-03-26 16:36, Song Linjian (Davey) =
wrote:
    Sigh! When =
people think IPv6 tunnel become a hinder of IPv6 deployment,
     people in China still in the struggle of chicken and egg =
problem. 

    Please explain more =
about your "chicken and egg problem" and how the
    last 20 =
years of IPv6 deployment have not addressed those problems.

    Greets,
     Jeroen



    

    ------------------------------
    Davey Song(=CB=CE=C1=D6=BD=A1)
    BII Lab
    songlinjian@gmail.com

    

    

    =

--Apple-Mail=_B401A76E-8875-4A71-89F2-D875CFE6A00C--


From nobody Sun Mar 26 15:06:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64E51296ED for ; Sun, 26 Mar 2017 15:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 VOAtR2tY_X0c for ; Sun, 26 Mar 2017 15:06:48 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD5F1296E5 for ; Sun, 26 Mar 2017 15:06:48 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id p22so25235460qka.3 for ; Sun, 26 Mar 2017 15:06:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S6aYagEJaUvcXkgCrcM7pcy/wOEd4jNj2+BWVSyVmOQ=; b=Tn/lB3nUF1doUqH0IFhPJuyXePEXwOD7wAhQbdwLViTKT9uvWApbvp8Thv3VGYaqXk xqQzl4cn61mqRZJuRuJEtCoD/lP6wUmeF7vEkZb9enU73XA3sMIBIcLsn0g8eWdXz7ec e+5U8gxZTzt7b1nyIyUUwZDcKWWpJEqKKO3mZrgTh+F+3nYun8SpRkQQ9MRkdgY24Jwi ynUTOfFuKzMJNNLTXjIA3L8cPxwFThXKPcqmCOMg+TIsI8II0LQisVb7ozUjwHy+Ywoj GedU8/gFCf+GUO3BAdbVCfZrFHeVa+W5EymqjE4lB42tXTqMwRTcKXA7W4N12LDn3iY6 B6ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S6aYagEJaUvcXkgCrcM7pcy/wOEd4jNj2+BWVSyVmOQ=; b=hoiup8XJNSTa7UBUksRKVuSOThkx5Br19vuxFhAMXVyQS5pWWPbtaLgAOZ9CnnYQe9 Vd92ny7T4sSHX8NSaa3t2vwM3Wl3PpD6G1FD7gJV81J1aSlHKkm/W4+ehOdz/sjRQfwT Vmpurn6bdbH5fiBNJ3wG644gg0iesHiOis8vjTfUkcIWegO+8xeT6lnMUHSecGh1XIex gFoxG/+fY/SYVYw1M6Cab7SYVD9Hd7Pz1v55zWmxG+Rj/Sp6WbUvI5O+fInDxtvynyBd FgAmsY9WfBMUnJgGI9/cd8L/AebFUeu7+EqxBc5Ua4Xru+QGdtuywnbKTlEn2Bok4gQc Uheg==
X-Gm-Message-State: AFeK/H269wck/yTL0acLs6RHkgvvrqXV26P9xaQewgaK8i60rSW8hhj/SyNfdu2WCVpkL0bwP/wXbxTv6R03jg==
X-Received: by 10.55.4.146 with SMTP id 140mr18563634qke.23.1490566007323; Sun, 26 Mar 2017 15:06:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.17.75 with HTTP; Sun, 26 Mar 2017 15:06:46 -0700 (PDT)
In-Reply-To: 
References:  <70EDF6B4-CCFB-45BE-A377-8EBD1C899231@gmail.com> <635f4330-eae5-ad47-f4d5-da1402393993@massar.ch> 
From: Christopher Morrow 
Date: Sun, 26 Mar 2017 18:06:46 -0400
Message-ID: 
Subject: Re: IETF: SixXS is shutting down
To: Song Linjian 
Cc: Jeroen Massar , SixXS Staff ,  IETF IPv6 Mailing List , Pim van Pelt 
Content-Type: multipart/alternative; boundary=001a114c9c7a618591054ba971ee
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Mar 2017 22:06:49 -0000

--001a114c9c7a618591054ba971ee
Content-Type: text/plain; charset=UTF-8

On Sun, Mar 26, 2017 at 4:23 PM, Song Linjian  wrote:

> Chicken and egg problem is the same :
>
> ISP complains there is no content in IPv6, no requirement from user for
> IPv6 connection. ICP complains there is no IPv6 network and IPv6 user
>
> China is different from India because it can not leap by taking the
> advantage of IPv6 development of big global ICPs, like Google , Facebook,
> and Youtube. Besides, most netizens in China do not consume much content in
> English. Most
>

some of those ICP are blocked... of course.
Some of them actually do offer local ipv6 versions of their content...
Some of them actually do offer local-language support over the ipv6 even.

Some of the tunnel users in question are probably trying to aboice the
blocks mentioned, right?
ISPs probably can't really enable bypassing filtering, not without
hand-slaps from the larger gov't anyway.


> of people can live well without connections outside. So the only hope is
> on the local ICP like Baidu , Tencent and Alibaba. But the local ICP and
> ISP are in the early stage of Chicken and egg problem.
>
>
what's strange is the story ~10yrs back (more actually) that 'all isps in
china are ipv6 enabled' isn't really true, I guess?
sad :(

--001a114c9c7a618591054ba971ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




    On Sun, Mar 26, 2017 at 4:23 PM, Song Linjian <songlinjian@gmail.c=
om> wrote:
    Chic=
ken and egg problem is the same :=C2=A0

    ISP compla=
ins there is no content in IPv6, no requirement from user for IPv6 connecti=
on. ICP complains there is no IPv6 network and IPv6 user=C2=A0
    China is different from India because it can not leap by taking the=
 advantage of IPv6 development of big global ICPs, like Google , Facebook, =
and Youtube. Besides, most netizens in China do not consume much content in=
 English. Most 

    som=
e of those ICP are blocked... of course.
    Some of them actually do=
 offer local ipv6 versions of their content...
    Some of them actua=
lly do offer local-language support over the ipv6 even.

    Some of the tunnel users in question are probably trying to aboice th=
e blocks mentioned, right?
    ISPs probably can't really enable bypassi=
ng filtering, not without hand-slaps from the larger gov't anyway.
    =C2=A0
    of people can live =
well without connections outside. So the only hope is on the local ICP like=
 Baidu , Tencent and Alibaba. But the local ICP and ISP are in the early st=
age of Chicken and egg problem.


    what's strange is the story ~10yrs back (mo=
re actually) that 'all isps in china are ipv6 enabled' isn't re=
ally true, I guess?
    sad :(
    =C2=A0
    

--001a114c9c7a618591054ba971ee--


From nobody Sun Mar 26 17:54:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8C129441; Sun, 26 Mar 2017 17:54:38 -0700 (PDT)
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, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 cZNXDcE2cMEL; Sun, 26 Mar 2017 17:54:35 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBF3128E19; Sun, 26 Mar 2017 17:54:35 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (unknown [216.80.70.251]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 980F01B0173B; Mon, 27 Mar 2017 03:51:48 +0100 (BST)
Message-ID: <58D862B2.5050607@erg.abdn.ac.uk>
Date: Sun, 26 Mar 2017 19:54:10 -0500
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Bob Hinden 
CC: "tsv-area@ietf.org" ,  "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF ,  "draft-ietf-6man-rfc1981bis@ietf.org" 
Subject: Re: Last Call:  (Path MTU Discovery for IP version 6) to Internet Standard
References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com>  <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com>  <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu>  <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com>  <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com>  <58A33D08.4090505@erg.abdn.ac.uk> <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> <58D518EA.5000508@erg.abdn.ac.uk> <4BC1763E-9D76-4EAA-B0B4-35620421736B@gmail.com>
In-Reply-To: <4BC1763E-9D76-4EAA-B0B4-35620421736B@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Mar 2017 00:54:38 -0000

Thanks for those coments, which I cut, because I think they can now be turned to text. You asked a question about one comment, see below:

GF:
Could the WG consider to also add the first two sentences to the security considerations?
Bob:
Sorry, which two sentences?

These were the two sentences, the rest of the para explained what PMTUD was, and probably could be left to the reader:

   "Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not
   rely upon network support for ICMP messages and is therefore
   considered more robust than standard PMTUD.  It is not susceptible to
   "black holing" of ICMP message."

Gorry


From nobody Sun Mar 26 19:35:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4450E127735; Sun, 26 Mar 2017 19:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 iOTXrPFYo7U3; Sun, 26 Mar 2017 19:35:15 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA331200A0; Sun, 26 Mar 2017 19:35:15 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id w11so23492324wrc.3; Sun, 26 Mar 2017 19:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Y14bXAoeZfUpvBy1Oe5b9AIwA4Yncv4zGU5sf9A9PfE=; b=XP4L7+9sC7lFhY/HDpg9PaPp1ujQMlt9veSfSxjzTMAeKc/OeIFtQkuj9laEAGers6 27rbwe+qpLtr4/5F0EMwPpmEAiuBUnPnwNjgjvrM5T+Sit46l/iAOuhmGS2Vz2uUFnTE gNEONUEyYzbbY7Ln+C1QskB9eQ3BGDpLSsnIzPJ+idFRBx3U9sECY4fprGsD9JTisTJk pyZGPRqP05pF8r4iOyKAONdcDbMQ1R3hAmYyIByT0vb5JHjmkenEXEnp6IRee5QmT9np Ll2CXzRKqvKRlkm+OVAx7W9lx2LCyz82OKEhGAl/uYWtUHo3WiBxn8JfaIscf+pVXKeK ltVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Y14bXAoeZfUpvBy1Oe5b9AIwA4Yncv4zGU5sf9A9PfE=; b=A9BoI5lD+uHVyq3D0+5427zGd3gpIl4zSHGvcCrSxy36xPDYXPKoNhdb6SGHEAW+df ELZ9ZfhLOa3FApxQMDi/RLnWBJeuCMfOv8KwnWyuDIgRO9TcU12QV02JoHDKos5tR8CX wIjUFrMWZbv7fNtuumc3GO4ReDJiixk+rdYdel6LDLuRONKCNwhuUsYTZQQRrBokHNBM no3NFe2KvtPWjsVb3+jSTWQURv4YVooOk0SBixG9YlZdYCcVUC0LovYfamKD3DEQfoqT 61SN3HEoblu+kl/gwOZTAGrhB0HNnej5YEJ6hSgRU0MngLeFk9Vb/UiI1IfSSRTDHZOY t/hg==
X-Gm-Message-State: AFeK/H1FaWewkcSpWla76f8/6+oGyuoeQm2xSxpxPgGqF8NMmqPQNolcUUcsb6ttj1ytNg==
X-Received: by 10.223.162.130 with SMTP id s2mr19298484wra.149.1490582113932;  Sun, 26 Mar 2017 19:35:13 -0700 (PDT)
Received: from dhcp-9201.meeting.ietf.org (dhcp-9201.meeting.ietf.org. [31.133.146.1]) by smtp.gmail.com with ESMTPSA id u145sm12442868wmu.1.2017.03.26.19.35.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 19:35:12 -0700 (PDT)
From: Bob Hinden 
Message-Id: <18CAF7CE-FDC1-46AD-9857-D4475564F4FA@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_4C8AF37D-719F-4B29-B836-FC94BA0F810E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call:  (Path MTU Discovery for IP version 6) to Internet Standard
Date: Sun, 26 Mar 2017 21:35:08 -0500
In-Reply-To: <58D862B2.5050607@erg.abdn.ac.uk>
Cc: Bob Hinden , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF , "draft-ietf-6man-rfc1981bis@ietf.org" 
To: gorry@erg.abdn.ac.uk
References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com>  <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com>  <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu>  <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com>  <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com>  <58A33D08.4090505@erg.abdn.ac.uk> <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> <58D518EA.5000508@erg.abdn.ac.uk> <4BC1763E-9D76-4EAA-B0B4-35620421736B@gmail.com> <58D862B2.5050607@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Mar 2017 02:35:17 -0000

--Apple-Mail=_4C8AF37D-719F-4B29-B836-FC94BA0F810E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Gorry,

> On Mar 26, 2017, at 7:54 PM, Gorry Fairhurst  =
wrote:
>=20
> Thanks for those coments, which I cut, because I think they can now be =
turned to text. You asked a question about one comment, see below:
>=20
> GF:
> Could the WG consider to also add the first two sentences to the =
security considerations?
> Bob:
> Sorry, which two sentences?
>=20
> These were the two sentences, the rest of the para explained what =
PMTUD was, and probably could be left to the reader:
>=20
>  "Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not
>  rely upon network support for ICMP messages and is therefore
>  considered more robust than standard PMTUD.  It is not susceptible to
>  "black holing" of ICMP message.=E2=80=9D

OK, I can add that.

Thanks,
Bob

>=20
> Gorry
>=20


--Apple-Mail=_4C8AF37D-719F-4B29-B836-FC94BA0F810E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJY2HpcAAoJEK7rdBF357uoSVoH/iVdpGHz8JGR3UhiN/C3zWJK
lulo/fQRKO3ITqwFnXa4zGNQbmkkNoVLaZ2M9nKHkqrpspoWwwMAGPvgTOKZt4sM
1WnUQadwbNW6Kyhr1YzxNXdQ/Ih5ifB81oagqLDNpbMK6mlPMq3GFcfCClr+Jofi
YF4pUhPifVB58EufDHqdKMHtjVSqorAZCl9ePBcFyv4X37eyUrwTylPcH5qmVz3U
aSeA8s96c8RVc6ZmgiyphGpsw3W6X93BIYwASUpH6uvzqk5cHSPIYw/9281KvCA1
3UrsE873C+qFJjmuMsnvl6sSb0DO7B2LNWR44XwtF6eoTf+Ocp8NFgaZ7H7v5D0=
=G4Fz
-----END PGP SIGNATURE-----

--Apple-Mail=_4C8AF37D-719F-4B29-B836-FC94BA0F810E--


From nobody Sun Mar 26 22:32:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6BD1274D0 for ; Sun, 26 Mar 2017 22:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 t62pOi8mg1xY for ; Sun, 26 Mar 2017 22:32:01 -0700 (PDT)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E67B1293F2 for ; Sun, 26 Mar 2017 22:31:59 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id 190so40947131itm.0 for ; Sun, 26 Mar 2017 22:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=v/JFwxYZMAOKN7HQ6EaPDWCTuIt9gTFY8wZS6nbbldA=; b=U1Ed1Lmgi4FSaccj8cfBgSTYxAbhKCQZBpg9KaY/w752sGlCd2pPJPRzxJu1GlJBzk XVZXG3zQHmpLrVMx2MvSalZgfIHLa5fcVU7yNY955lytlp66dx2op7AQCSYvsZdkh1v9 +2jtvqgfQhq3LRvkclur4+A4ZavO9Y647MKzh2sOZfK9Rp0/gYacSsdNEmEr9+HbSNeW L4uyU2kPogzWSLfu63IH97rZqDlEuQHeqrEaegpOFWbU3/Ds2TrxUhKoordIlfMphupV osfG3yy/6abhYwbvqOLQ7MchhM61hJIEvCvDSs9YOdeVjx35CFNUJG0//zllp8op/luG c2dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=v/JFwxYZMAOKN7HQ6EaPDWCTuIt9gTFY8wZS6nbbldA=; b=JJVkSLOl5+jVh+VE7eZZIMbiJMAsI2sDGEXVNU//JQYcidrAmoJCLJWJyhONPqJMEo I2Xf83kv4sOuAuXiqKZHry7gQq0jBmXrC5/LRnkhSwHUWQ/dTwqDS2tp7lVcD3ULRqWz Rs1JUzDL4rDXeyrnHt2UKWsvA4b/QIGhWIleN+AqI41YU4Sor/d6E8UbKJYMNMl9FwTs R7Rc2Rlln1LSOoMBT83rcNlDRbMLmbFpMW99aYh8JcgT6IqnOFfQZGZyrSl0nlQtlJEF tTBJ98jus0+U/3jDh96aVO55s1/h6zDJ/iQ7L/tijxGvmmRc6rWUKN1/TKuzZgZc27CD Zp9w==
X-Gm-Message-State: AFeK/H3sqoi43I83pJQBNf1hMFGzAOgsbhoeaKO9ttGp5ZV1jASoBeKUQGTNEIbIwbTqZg==
X-Received: by 10.107.23.6 with SMTP id 6mr19049766iox.14.1490592718414; Sun, 26 Mar 2017 22:31:58 -0700 (PDT)
Received: from [10.0.8.58] ([66.71.229.5]) by smtp.gmail.com with ESMTPSA id r30sm5161830ioi.56.2017.03.26.22.31.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 22:31:57 -0700 (PDT)
From: "Song Linjian (Davey)" 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_3D53D218-0DFF-44E0-92B3-A71FCE620255"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: IETF: SixXS is shutting down
Date: Mon, 27 Mar 2017 00:31:55 -0500
In-Reply-To: 
Cc: Jeroen Massar , SixXS Staff , IETF IPv6 Mailing List , Pim van Pelt 
To: Christopher Morrow 
References:  <70EDF6B4-CCFB-45BE-A377-8EBD1C899231@gmail.com> <635f4330-eae5-ad47-f4d5-da1402393993@massar.ch>  
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Mar 2017 05:32:03 -0000

--Apple-Mail=_3D53D218-0DFF-44E0-92B3-A71FCE620255
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=gb2312


> what's strange is the story ~10yrs back (more actually) that 'all isps =
in china are ipv6 enabled' isn't really true, I guess?
> sad :(=20


Major ISPs are IPv6 enabled in the aspect of the backbone, not the last =
mile to users. Some of them deployed IPv6 island that is not connected =
to the backbone.=20

There are two cases I experienced last year :=20

1) China mobile is provisioning IPv6 to their users in Beijing over =
VoLTE, so I can receive IPv6 address in my handset. But I can not ping =
out (out of China). =20

2) The ISP in Fujian province, they deployed IPv6 to the local network. =
We once setup IPv6-only DNS servers there but we can not pull the zone =
from the master server in my lab in Beijing.

Now the business of Chinese telcos are impacted by the Internet company, =
so they are not motivated to move forward and increase the investment in =
IPv6. The main force of IPv6 guys I know well are from the research =
department , not from the operational department of these telcos. The =
later has more voice in decision making from my impression.

CERNET2 is good but the example is not copied to other ISPs. IMHO =
academic guys spent too much effort on transition protocols and tools as =
a reward to intellectual challenges. few of them are really deployed in =
scale. Instead, too many IPv6 transition choices make IPv6 adoption =
harder for telcos operational people who think IPv6 is not ready for =
productional network. Even in the research area, there are different =
voice/noise  to hold back the IPv6 development, like SDN, non-ip =
solutions, even IPv9 (the freak!!!).=20

In policy making layer, there exists some fears and exaggerating =
opinions with non-trivial group of advocates who try to convince Gov't =
that IPv6 may introduce new threats and impacts to current =
censorship,like IPsec, even the fact that IPsec traffic is poor.

In general, there are many challenges for IPv6 guys in China as far as I =
can tell. More consensus should be reached in the community to take real =
actions. The good news is that the global IPv6 traffic is reaching 18% =
of total which exerts pressures on both industry and Gov't. In most =
Chinese people=A1=AEs mind, it seems acceptable that China fall little =
behind U.S or EU in many areas, but not India and Vietnam.  More IPv6 =
stories of those countries and regions can really help by hurting the =
proud : )=20

 I=A1=AFm expecting to see changes in the coming years.=20

------------------------------
Davey Song(=CB=CE=C1=D6=BD=A1)
BII Lab
songlinjian@gmail.com



--Apple-Mail=_3D53D218-0DFF-44E0-92B3-A71FCE620255
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=gb2312


    what's strange is the story ~10yrs =
back (more actually) that 'all isps in china are ipv6 enabled' isn't =
really true, I guess?
    sad =
:( 
    


    Major ISPs are IPv6 enabled in the aspect of the backbone, =
not the last mile to users. Some of them deployed IPv6 island that is =
not connected to the backbone. 

    There are two cases I experienced last =
year : 

    1) =
China mobile is provisioning IPv6 to their users in Beijing over VoLTE, =
so I can receive IPv6 address in my handset. But I can not ping out (out =
of China).  

    2) The ISP in Fujian province, they deployed IPv6 to the =
local network. We once setup IPv6-only DNS servers there but we can not =
pull the zone from the master server in my lab in Beijing.

    Now the business of =
Chinese telcos are impacted by the Internet company, so they are not =
motivated to move forward and increase the investment in IPv6. The main =
force of IPv6 guys I know well are from the research department , not =
from the operational department of these telcos. The later has more =
voice in decision making from my impression.

    CERNET2 is good but the example is not =
copied to other ISPs. IMHO academic guys spent too much effort on =
transition protocols and tools as a reward to intellectual challenges. =
few of them are really deployed in scale. Instead, too many IPv6 =
transition choices make IPv6 adoption harder for telcos operational =
people who think IPv6 is not ready for productional network. Even in the =
research area, there are different voice/noise  to hold back the =
IPv6 development, like SDN, non-ip solutions, even IPv9 (the =
freak!!!). 

    In policy making layer, there exists some fears and =
exaggerating opinions with non-trivial group of advocates who try to =
convince Gov't that IPv6 may introduce new threats and impacts to =
current censorship,like IPsec, even the fact that IPsec traffic is =
poor.

    In =
general, there are many challenges for IPv6 guys in China as far as I =
can tell. More consensus should be reached in the community to take =
real actions. The good news is that the global IPv6 traffic is reaching =
18% of total which exerts pressures on both industry and Gov't. In most =
Chinese people=A1=AEs mind, it seems acceptable that China fall little =
behind U.S or EU in many areas, but not India and Vietnam. =
 More IPv6 stories of those countries and regions can really help =
by hurting the proud : ) 

     I=A1=AFm expecting to see changes =
in the coming years. 

    

    ------------------------------
    Davey Song(=CB=CE=C1=D6=BD=A1)
    BII Lab
    songlinjian@gmail.com

    

    

    =

--Apple-Mail=_3D53D218-0DFF-44E0-92B3-A71FCE620255--


From nobody Mon Mar 27 07:17:35 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82B41296A1 for ; Mon, 27 Mar 2017 07:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RjRc4n4sX4KN for ; Mon, 27 Mar 2017 07:17:31 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3AC712956B for ; Mon, 27 Mar 2017 07:17:30 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id n21so38386269qta.1 for ; Mon, 27 Mar 2017 07:17:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fG5bj++dRyL7OAO6XSrW1zS5HBw16xSWVQ9XvDRgbvE=; b=Bs7X701CCnSFaQ6bHL4GWf1eYNj3AEnlTikCwLwffKagE0jEIB7dJ/XBXkGnZ01Cch zs1U5LvCh/xy24ukcfFZ9ybnT42mDAUrYpyo9xkCvE+D1IavA6vrF+5FHtEvRpy7xA1/ 2a2JUQwLY+rWUrfnrAhANWnVYzo4xzTbMBa+puPh9PiZDkFIPvYR87V+CN0s5QLEgetf EPxSaDjlmwY+lAqffcX3rBSN2W0VMSnE/XPF7HVj7C4TAGpkELt3w9EOT46OafoufavZ scjjesd1w1q75o5NCx9MDhi5oWHmswwXdZJn2MhOYWxmzaWfPER9OuK/tho/xrK2iOxe YdvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fG5bj++dRyL7OAO6XSrW1zS5HBw16xSWVQ9XvDRgbvE=; b=CbVZaZnJvMgYIYcSK/N+LX5xvxZpSVPqhcLbl+eaX5IIY5YnXwMSNmYfqu8OaMJCjJ P6R4yblPo45Q4hYUb/QUQ9CfMRImNVHm9UlPLnjsseXMH2m4FtAAZlNb3QQZ4fhlu0K1 XlYGYnYtYMeGH46ptI4Z4OIcCl7CKxX82S7oS/yYONNxXxsWqZVJM4+3Y2HRfYpNhePL OXU31uZ1DuX91oeo6NeBkk/lQxgU0CCnknNFZRNNwPCt+FKRT6oxIKI8euBVkG32CiNx mwOTDCv8e1AmWzD3H276/CymDxVuWBrkE7Y5WYvPsCnPiZU+hwntYVnn4WGHzY7KRIwU ajyw==
X-Gm-Message-State: AFeK/H01PMqPNLdmoMK6ji0Wqec6TbaHgso7ca8D9n3ro10mGWnMt57d+OJivZYYKsVfEAr8XgmwFVIBGeWR4Q==
X-Received: by 10.200.51.117 with SMTP id u50mr22630449qta.133.1490624249944;  Mon, 27 Mar 2017 07:17:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.17.75 with HTTP; Mon, 27 Mar 2017 07:17:29 -0700 (PDT)
In-Reply-To: 
References:  <70EDF6B4-CCFB-45BE-A377-8EBD1C899231@gmail.com> <635f4330-eae5-ad47-f4d5-da1402393993@massar.ch>   
From: Christopher Morrow 
Date: Mon, 27 Mar 2017 08:17:29 -0600
Message-ID: 
Subject: Re: IETF: SixXS is shutting down
To: "Song Linjian (Davey)" 
Cc: Jeroen Massar , SixXS Staff ,  IETF IPv6 Mailing List , Pim van Pelt 
Content-Type: multipart/alternative; boundary=001a113ace70e97b8e054bb7005c
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Mar 2017 14:17:33 -0000

--001a113ace70e97b8e054bb7005c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 26, 2017 at 11:31 PM, Song Linjian (Davey) <
songlinjian@gmail.com> wrote:

>
> what's strange is the story ~10yrs back (more actually) that 'all isps in
> china are ipv6 enabled' isn't really true, I guess?
> sad :(
>
>
> Major ISPs are IPv6 enabled in the aspect of the backbone, not the last
> mile to users. Some of them deployed IPv6 island that is not connected to
> the backbone.
>
>
that doesn't sound like an ipv6 deployment at all. bummer.


> There are two cases I experienced last year :
>
> 1) China mobile is provisioning IPv6 to their users in Beijing over VoLTE=
,
> so I can receive IPv6 address in my handset. But I can not ping out (out =
of
> China).
>
>
I don't think you can provision ipv over 'volte' ... volte is
just: 'send voice over ip to handsets'. The LTE standard does speak
strongly about requiring ipv6 though, so probably any LTE deployment does
have ipv6 as a component.

perhaps you mean that?


> 2) The ISP in Fujian province, they deployed IPv6 to the local network. W=
e
> once setup IPv6-only DNS servers there but we can not pull the zone from
> the master server in my lab in Beijing.
>
> Now the business of Chinese telcos are impacted by the Internet company,
> so they are not motivated to move forward and increase the investment in
> IPv6. The main force of IPv6 guys I know well are from the research
> department , not from the operational department of these telcos. The lat=
er
> has more voice in decision making from my impression.
>

and again:
  1) some of the examples you provided are not reachable in the PRC,
because of some PRC local decisions/actions
  2) all of the examples you cited (facebook, youtube, google, etc) are
ipv6 enabled for the rest of the world.
  3) some of these properties even provide content from inside the prc,
over ipv6

I am betting there are other, larger, problems with ipv6 deployment in the
PRC, related to things like: "Why can I not get to facebook.com?" while in
the PRC.


> CERNET2 is good but the example is not copied to other ISPs. IMHO academi=
c
> guys spent too much effort on transition protocols and tools as a reward =
to
> intellectual challenges. few of them are really deployed in scale. Instea=
d,
> too many IPv6 transition choices make IPv6 adoption harder for telcos
> operational people who think IPv6 is not ready for productional network.
> Even in the research area, there are different voice/noise  to hold back
> the IPv6 development, like SDN, non-ip solutions, even IPv9 (the freak!!!=
).
>
>
the rest of the world basically disagrees though? ipv6 deployment is moving
further and faster every day... except in the PRC, it seems?


> In policy making layer, there exists some fears and exaggerating opinions
> with non-trivial group of advocates who try to convince Gov't that IPv6 m=
ay
> introduce new threats and impacts to current censorship,like IPsec, even
> the fact that IPsec traffic is poor.
>
>
maybe don't do the censorship part then?


> In general, there are many challenges for IPv6 guys in China as far as I
> can tell. More consensus should be reached in the community to take real
> actions. The good news is that the global IPv6 traffic is reaching 18% of
> total which exerts pressures on both industry and Gov't. In most Chinese
> people=E2=80=98s mind, it seems acceptable that China fall little behind =
U.S or EU
> in many areas, but not India and Vietnam.  More IPv6 stories of those
> countries and regions can really help by hurting the proud : )
>
>
ok


>  I=E2=80=99m expecting to see changes in the coming years.
>
>
terrific.


> ------------------------------
> Davey Song(=E5=AE=8B=E6=9E=97=E5=81=A5)
> BII Lab
> songlinjian@gmail.com
>
>
>

--001a113ace70e97b8e054bb7005c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




    On Sun, Mar 26, 2017 at 11:31 PM, Song Linjian (Davey) <songlinjia=
n@gmail.com> wrote:

    what's strange is the story ~10yrs back (more actually) that =
9;all isps in china are ipv6 enabled' isn't really true, I guess?
    sad :(=C2=A0
    


    Major ISPs are IPv6 enabled i=
n the aspect of the backbone, not the last mile to users. Some of them depl=
oyed IPv6 island that is not connected to the backbone.=C2=A0

    that doesn't sound like a=
n ipv6 deployment at all. bummer.
    =C2=A0
    There are=
 two cases I experienced last year :=C2=A0

    1) Chin=
a mobile is provisioning IPv6 to their users in Beijing over VoLTE, so I ca=
n receive IPv6 address in my handset. But I can not ping out (out of China)=
. =C2=A0


    I don&#=
39;t think you can provision ipv<anything> over 'volte' ... v=
olte is just: 'send voice over ip to handsets'. The LTE standard do=
es speak strongly about requiring ipv6 though, so probably any LTE deployme=
nt does have ipv6 as a component.

    perhaps you mean=
 that?
    =C2=A0
    2) The ISP in Fujian province, they de=
ployed IPv6 to the local network. We once setup IPv6-only DNS servers there=
 but we can not pull the zone from the master server in my lab in Beijing.<=
/div>

    Now the business of Chinese telcos are impacted by=
 the Internet company, so they are not motivated to move forward and increa=
se the investment in IPv6. The main force of IPv6 guys I know well are from=
 the research department , not from the operational department of these tel=
cos. The later has more voice in decision making from my impression.
    <=
/div>

    and again:
    =C2=A0 1) some o=
f the examples you provided are not reachable in the PRC, because of some P=
RC local decisions/actions
    =C2=A0 2) all of the examples you cite=
d (facebook, youtube, google, etc) are ipv6 enabled for the rest of the wor=
ld.
    =C2=A0 3) some of these properties even provide content from =
inside the prc, over ipv6
    =C2=A0
    I am betting there are=
 other, larger, problems with ipv6 deployment in the PRC, related to things=
 like: "Why can I not get to facebook.=
com?" while in the PRC.


    CERNET2 is=
 good but the example is not copied to other ISPs. IMHO academic guys spent=
 too much effort on transition protocols and tools as a reward to intellect=
ual challenges. few of them are really deployed in scale. Instead, too many=
 IPv6 transition choices make IPv6 adoption harder for telcos operational p=
eople who think IPv6 is not ready for productional network. Even in the res=
earch area, there are different voice/noise =C2=A0to hold back the IPv6 dev=
elopment, like SDN, non-ip solutions, even IPv9 (the freak!!!).=C2=A0
    =



    the rest of the world=
 basically disagrees though? ipv6 deployment is moving further and faster e=
very day... except in the PRC, it seems?
    =C2=A0
    In p=
olicy making layer, there exists some fears and exaggerating opinions with =
non-trivial group of advocates who try to convince Gov't that IPv6 may =
introduce new threats and impacts to current censorship,like IPsec, even th=
e fact that IPsec traffic is poor.

    <=
div>
    maybe don't do the censorship part then?
    =
=C2=A0
    In general, there are many challenges for IPv6 guys in =
China as far as I can tell. More=C2=A0consensus should be reached in the co=
mmunity to take real actions. The good news is that the global IPv6 traffic=
 is reaching 18% of total which exerts pressures on both industry and Gov&#=
39;t. In most Chinese people=E2=80=98s mind, it seems acceptable that China=
 fall little behind U.S or EU in many areas, but not India and=C2=A0Vietnam=
.=C2=A0 More IPv6 stories of those countries and regions can really help by=
 hurting the proud : )=C2=A0

    ok
    =C2=A0
    =C2=A0I=E2=80=99m expecting t=
o see changes in the coming years.=C2=A0

    <=
/div>

    terrific.
    =C2=A0
    

    ------------------------------
    Davey Song(=E5=AE=8B=E6=9E=97=E5=81=A5)
    BII Lab
    songlinjian@gmail.com

    =

    

    


    

--001a113ace70e97b8e054bb7005c--


From nobody Mon Mar 27 07:40:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4502127863 for ; Mon, 27 Mar 2017 07:40:23 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jnmSdaisTEwb for ; Mon, 27 Mar 2017 07:40:22 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B09127286 for ; Mon, 27 Mar 2017 07:40:21 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id w11so45605779wrc.3 for ; Mon, 27 Mar 2017 07:40:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:cc:to; bh=nDHBNjJ6Lrj3S6Qu9+nfjAU6tGVGSvM1tWeN821JJjk=; b=mNK4KSJvFDAjF0BuMlTQO32cbvMfkwdEW+eePf0xw6D+4qJ6ClC1CcQVLh3rhfXQST vpPg5xYGQT3Brd4c9rCY4iHs/z4umLejM/qarBY56+c0sbQmwBqv+J2H4tTkZoRLZhjd /yjLNeCn0Pm1xQqCes7cDzXO9kIhBHzD91QwqRnLqvaNuhTQ8yLvfF3+LXOKCg0NtUWy orHr+LLcTWruI3N1CrLO55U/WTFhiJonxUIOZLH6oijmaRjHcMnsDLRgY53Imbfb4kQm LQQ0lRqP+1FRbuuH44IAYCZITGrDYBA+oFuhKzx4Kwv/BC3JkyQjwc4rkIL2XRK/ytwv Eymg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=nDHBNjJ6Lrj3S6Qu9+nfjAU6tGVGSvM1tWeN821JJjk=; b=jNfstWsNtIURfMLcZrgi6DxqMM281HiHezEWw1pi07WBGmJnoeDEY+2Nf+ifAaJ9LS tPNgyp/bN7FJS7Ax9iAgswnm9c3EHdrvU02tMdey3kJoXQxkBQsftdUxMMkZptZu/ADH oHxPIOf+vujeQtJ57ghqs0xqRbvgSeq63HPWnajnIdML/sFiAlxxjrFy+peEbqmtrB9D H9p7HhEeqsjYYP99d46S4U4xCRHPf4BmGTpY9zHvH+O/hsROC90UfyBLd6hvCVA5HZqe sYiZe6v5Eznb1oDRGLj49tqrkLOCg7qkMlrIPKW1cFkrV8SH7k+q8H1NQ6lJs4mEPld4 ku+Q==
X-Gm-Message-State: AFeK/H1bPepwCZSBadfOqNrCAA9dlVKEHBYxMoU5cAOSMQvKJoABmqv4pF6tvtwjbHlGgA==
X-Received: by 10.223.164.150 with SMTP id g22mr22516978wrb.92.1490625620093;  Mon, 27 Mar 2017 07:40:20 -0700 (PDT)
Received: from t2001067c03700128f0d96c3feba5724e.v6.meeting.ietf.org (t2001067c03700128f0d96c3feba5724e.v6.meeting.ietf.org. [2001:67c:370:128:f0d9:6c3f:eba5:724e]) by smtp.gmail.com with ESMTPSA id z88sm990451wrb.26.2017.03.27.07.40.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 07:40:19 -0700 (PDT)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_C7435A0A-6DAD-480F-B8D0-FE70B7C8C23E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Need volunteers for jabber scribe and minute taker
Message-Id: <3B564151-F8C3-4851-ABB6-84D76FAEB942@gmail.com>
Date: Mon, 27 Mar 2017 09:40:14 -0500
Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= 
To: IPv6 List 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Mar 2017 14:40:24 -0000

--Apple-Mail=_C7435A0A-6DAD-480F-B8D0-FE70B7C8C23E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

We need volunteers for jabber scribes and a minute taker for the =
Thursday morning 6MAN session.

Please volunteer.  We are happy to talk to you about what is required.

Thanks,
Bob & Ole





--Apple-Mail=_C7435A0A-6DAD-480F-B8D0-FE70B7C8C23E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJY2SROAAoJEK7rdBF357uo8DMH+wRUaNTuctSYWI+syINzuO+9
j6SjpkZZAptvsEl8b7LEXhFaAJsoO5Tcf/iakB1QbuUvIWVctGkmtm9Xsta/ucb0
glZKyqkDTqmSpkBleplPz+IK50XOals+HTMY+WfqTvhT8hi5qFd8Umo1Qty/qrAZ
EZl08Pbm1DuU1FAmns5VdC9ohz8kE4digezZruneCDkfz9ton8KcyC3Jfrl7bv5W
zf6tabHrs339PxUhUpsTkn88DxmZJtlumVN5z/Kkp2aOugtIL4GjuaJgHTr0w3/s
xP7ah/vfNQsmlPRe9k6JUlP2nCPVzBptidsGkoI2Ikx6aPW9BPf37gC0rVZLS8c=
=U79x
-----END PGP SIGNATURE-----

--Apple-Mail=_C7435A0A-6DAD-480F-B8D0-FE70B7C8C23E--


From nobody Mon Mar 27 10:03:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC62F127077 for ; Mon, 27 Mar 2017 10:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.668
X-Spam-Level: 
X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 qD7DoWv2Zp_v for ; Mon, 27 Mar 2017 10:03:34 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADEDE127201 for ; Mon, 27 Mar 2017 10:03:33 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2RH3Vpu048564 for ; Mon, 27 Mar 2017 19:03:31 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E475D20B6D7 for ; Mon, 27 Mar 2017 19:03:31 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DAE2920B5B2 for ; Mon, 27 Mar 2017 19:03:31 +0200 (CEST)
Received: from [132.166.84.4] ([132.166.84.4]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2RH3Uuw006071 for ; Mon, 27 Mar 2017 19:03:31 +0200
Subject: Re: IETF: SixXS is shutting down
To: ipv6@ietf.org
References:  <70EDF6B4-CCFB-45BE-A377-8EBD1C899231@gmail.com> <635f4330-eae5-ad47-f4d5-da1402393993@massar.ch>   
From: Alexandre Petrescu 
Message-ID: <442b1fcf-deff-329c-6ea7-593dcaa2ff0a@gmail.com>
Date: Mon, 27 Mar 2017 12:03:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Mar 2017 17:03:36 -0000

Le 27/03/2017 à 00:31, Song Linjian (Davey) a écrit :
>
>> what's strange is the story ~10yrs back (more actually) that 'all
>> isps in china are ipv6 enabled' isn't really true, I guess? sad :(
>>
>
> Major ISPs are IPv6 enabled in the aspect of the backbone,

You tell major ISPs: the IPv6 blocks they got are mainly for the ISP
clients, and only secondarily for themselves :-)

It worked for me :-)

(basically, when an ISP asks for an IPv6 block to RIR, the RIR asks back
how many clients they have, and subsequently they dimension the size of
these IPv6 blocks; so the ISPs are bound to this).

Alex

> not the last mile to users. Some of them deployed IPv6 island that
> is not connected to the backbone.
>
> There are two cases I experienced last year :
>
> 1) China mobile is provisioning IPv6 to their users in Beijing over
> VoLTE, so I can receive IPv6 address in my handset. But I can not
> ping out (out of China).
>
> 2) The ISP in Fujian province, they deployed IPv6 to the local
> network. We once setup IPv6-only DNS servers there but we can not
> pull the zone from the master server in my lab in Beijing.
>
> Now the business of Chinese telcos are impacted by the Internet
> company, so they are not motivated to move forward and increase the
> investment in IPv6. The main force of IPv6 guys I know well are from
> the research department , not from the operational department of
> these telcos. The later has more voice in decision making from my
> impression.
>
> CERNET2 is good but the example is not copied to other ISPs. IMHO
> academic guys spent too much effort on transition protocols and
> tools as a reward to intellectual challenges. few of them are really
> deployed in scale. Instead, too many IPv6 transition choices make
> IPv6 adoption harder for telcos operational people who think IPv6 is
> not ready for productional network. Even in the research area, there
> are different voice/noise  to hold back the IPv6 development, like
> SDN, non-ip solutions, even IPv9 (the freak!!!).
>
> In policy making layer, there exists some fears and exaggerating
> opinions with non-trivial group of advocates who try to convince
> Gov't that IPv6 may introduce new threats and impacts to current
> censorship,like IPsec, even the fact that IPsec traffic is poor.
>
> In general, there are many challenges for IPv6 guys in China as far
> as I can tell. More consensus should be reached in the community to
> take real actions. The good news is that the global IPv6 traffic is
> reaching 18% of total which exerts pressures on both industry and
> Gov't. In most Chinese people‘s mind, it seems acceptable that China
> fall little behind U.S or EU in many areas, but not India and
> Vietnam.  More IPv6 stories of those countries and regions can
> really help by hurting the proud : )
>
> I’m expecting to see changes in the coming years.
>
> ------------------------------ Davey Song(宋林å¥) BII Lab
> songlinjian@gmail.com 
>
>
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


From nobody Mon Mar 27 14:01:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8583A129669 for ; Mon, 27 Mar 2017 14:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 M46B4HORj1Jd for ; Mon, 27 Mar 2017 14:01:30 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB07129659 for ; Mon, 27 Mar 2017 14:01:28 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2RL1QHV017115; Mon, 27 Mar 2017 23:01:26 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1A20220BA08; Mon, 27 Mar 2017 23:01:26 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0A58020B94A; Mon, 27 Mar 2017 23:01:26 +0200 (CEST)
Received: from [132.166.84.184] ([132.166.84.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2RL1JRK011600; Mon, 27 Mar 2017 23:01:24 +0200
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
References: <20170223134026.GI5069@gir.theapt.org> <58AF726A.3040302@foobar.org>  <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com>      <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>   
Cc: Mark Smith , 6man WG 
From: Alexandre Petrescu 
Message-ID: 
Date: Mon, 27 Mar 2017 16:00:58 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Mar 2017 21:01:32 -0000

Le 02/03/2017 à 20:24, 神明é”哉 a écrit :
> On Tue, Feb 28, 2017 at 4:04 AM, Alexandre Petrescu
>  wrote:
>
>> Finally, there is no advice of what bits to put between fe80:: and a
>> 64bit the Interface ID - zeros or ones?  linux says it's a fe80::/64 and
>> IIRC BSD says it's a fe80::/10.  The routing entries based on that can
>> make for interop problems.
>
> I don't know exactly what you mean by "BSD says it's a fe80::/10", but
> BSD variants use a 64-bit IID to configure (e.g) an ethernet interface
> with a link-local address, as specified in RFC4862 and RFC2464.  They
> also only recognize addresses that match fe80::/64 as on-link:
>
> Destination                       Gateway                       Flags      Netif
> fe80::%em0/64                     link#1                        U           em0
>
> On the other hand, BSDs' implementation of the IN6_IS_ADDR_LINKLOCAL()
> macro only checks the first 10 bits:
>
> #define IN6_IS_ADDR_LINKLOCAL(a)        \
>         (((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))

Tatuya, masking it that way it means that fe81::/10 is also recognized 
as an LL address prefix, right?  I think it is good, but just checking.

> If you mean this by "fe80::/10", yes, BSDs hardcorde /10 for
> link-local.

That '10' hardcoded is not a problem, because RFC4291 requires it to be 10.

>  But it has nothing to do with the length of IIDs.

I agree.

Alex

>
> --
> JINMEI, Tatuya
>


From nobody Mon Mar 27 14:24:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94603120727 for ; Mon, 27 Mar 2017 14:24:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.402
X-Spam-Level: 
X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fCXpBBvqPNVV for ; Mon, 27 Mar 2017 14:24:28 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D8D124234 for ; Mon, 27 Mar 2017 14:24:25 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id p22so50609239qka.3 for ; Mon, 27 Mar 2017 14:24:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=q8FVxNSYPtlO5AsMe9DW7Obk840oTSsECxusm+1dE/w=; b=fGGODl6kNTN2zm8o52ohEu2kldVpju9PGvUOopbn7UCxILjoE2/cJHrxfD6jPizv96 RRDh+SmJquSQ5Nlla94VwMFH6XFSyOJ8JfAFDpXhAlQYMx6PAjEvRGihhtjUon4E04pA 85Hb5QUTCTfa45rcdew3PcuIvHmfhvE3/QDu4w8JDS5HmMRWvmBjy68Tw8XfLSHisa2G BPCgCTLTq+zdWGnCvFd2BYnTnUMia5z5pXUmAtn+BFortwEW4hvFUdjZeH7m8qJmmQmR SG3npXADG1HM6OPUxY3+G64wt6YHQdiBmWw+jwSwCbBIBuJcg7YkcrwGNMRCvrEXXFbl MPRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=q8FVxNSYPtlO5AsMe9DW7Obk840oTSsECxusm+1dE/w=; b=BSmNU3zIlmRiDxPyHXIysqoIyhioxvI4zP4wY/SkusMJB6A0d2rNMXUhYlPJ1dgHOb 9utIZo/ZXz8DdbcIu9l6eysPw2r900wJZSF6KYnkGowcK8xqy1g/I9+A+RrAUVxdMAWK jzQ/8kS/rRGXNMFuCNKGHY5X9cGbJVt/+oZ9PfNlqTD6qrimM5Yu4EhnPpJ493w8wos3 BNhMNB3812e+ATtYjtEgE5HD+d4kmC1oZKjIMW9YYW0WR/g4wUJ6ZgAWJi4tzaQzEyNj F6voHgMsyAjbnrNbjXKdyrz79iD+oF1H43mzEXL8PWwFqy/1UPTooG40eqpdI9gjE+op w3ag==
X-Gm-Message-State: AFeK/H0xVmK+ihmg0xzKVpZ9bBqh+uFzJK0en/fHGF6yJqywR74X6eG16U+LGwj3cLPwF9jKGqGsFxIyv7jaTw==
X-Received: by 10.55.192.79 with SMTP id o76mr11420151qki.19.1490649864886; Mon, 27 Mar 2017 14:24:24 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Mon, 27 Mar 2017 14:24:24 -0700 (PDT)
In-Reply-To: 
References: <20170223134026.GI5069@gir.theapt.org> <58AF726A.3040302@foobar.org>  <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com>      <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>    
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Mon, 27 Mar 2017 14:24:24 -0700
X-Google-Sender-Auth: oRDbe9E72aSm9ssOoxUYEaUQ8Nw
Message-ID: 
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Alexandre Petrescu 
Cc: 6man WG 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Mar 2017 21:24:30 -0000

At Mon, 27 Mar 2017 16:00:58 -0500,
Alexandre Petrescu  wrote:

> > On the other hand, BSDs' implementation of the IN6_IS_ADDR_LINKLOCAL()
> > macro only checks the first 10 bits:
> >
> > #define IN6_IS_ADDR_LINKLOCAL(a)        \
> >         (((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))
>
> Tatuya, masking it that way it means that fe81::/10 is also recognized
> as an LL address prefix, right?  I think it is good, but just checking.

fe81::/10 is just an "abnormal" form of fe80::/10, but I guess you
actually meant fe81::/16.  Assuming so, your understanding is correct:
an address that matches fe81::/16 is recognized as unicast link-local
wherever the IN6_IS_ADDR_LINKLOCAL macro is used for the test.  For
example, BSD kernels consider this kind of address to be unicast
link-local in the validation of received RA:

    if (!IN6_IS_ADDR_LINKLOCAL(&saddr6)) {
        nd6log((LOG_ERR,
            "nd6_ra_input: src %s is not link-local\n",
            ip6_sprintf(ip6bufs, &saddr6)));
        goto bad;
    }
(this code only checks the first 10 bits).

--
JINMEI, Tatuya


From nobody Mon Mar 27 15:25:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A19129666 for ; Mon, 27 Mar 2017 15:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 thsRudw-vbbU for ; Mon, 27 Mar 2017 15:25:24 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C994C1286B1 for ; Mon, 27 Mar 2017 15:25:23 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2RMPLhA029313; Tue, 28 Mar 2017 00:25:21 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EBC5A20BA25; Tue, 28 Mar 2017 00:25:21 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DE8A420B590; Tue, 28 Mar 2017 00:25:21 +0200 (CEST)
Received: from [132.166.84.5] ([132.166.84.5]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2RMPLdT016379; Tue, 28 Mar 2017 00:25:21 +0200
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
References: <20170223134026.GI5069@gir.theapt.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com>      <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>     
Cc: 6man WG 
From: Alexandre Petrescu 
Message-ID: 
Date: Mon, 27 Mar 2017 17:25:02 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Mar 2017 22:25:25 -0000

Le 27/03/2017 à 16:24, 神明é”哉 a écrit :
> At Mon, 27 Mar 2017 16:00:58 -0500, Alexandre Petrescu
>  wrote:
>
>>> On the other hand, BSDs' implementation of the
>>> IN6_IS_ADDR_LINKLOCAL() macro only checks the first 10 bits:
>>>
>>> #define IN6_IS_ADDR_LINKLOCAL(a)        \ (((a)->s6_addr[0] ==
>>> 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))
>>
>> Tatuya, masking it that way it means that fe81::/10 is also
>> recognized as an LL address prefix, right?  I think it is good,
>> but just checking.
>
> fe81::/10 is just an "abnormal" form of fe80::/10,

Err, I dont think fe81::/10 is an abnormal LL.  I think fe81::/10, 
fe82::/10, ... febf::/10 are all normal forms of LL.

> but I guess you actually meant fe81::/16.

I did not mean fe81::/16, I meant fe81::/10.

fe80      is: 1111 1110 1000 0000
fe80::/10 is: 1111 1110 10
fe81::/10 is: 1111 1110 10

Alex

> Assuming so, your understanding is correct: an address that matches
> fe81::/16 is recognized as unicast link-local wherever the
> IN6_IS_ADDR_LINKLOCAL macro is used for the test.  For example, BSD
> kernels consider this kind of address to be unicast link-local in the
> validation of received RA:
>
> if (!IN6_IS_ADDR_LINKLOCAL(&saddr6)) { nd6log((LOG_ERR,
> "nd6_ra_input: src %s is not link-local\n", ip6_sprintf(ip6bufs,
> &saddr6))); goto bad; } (this code only checks the first 10 bits).
>
> -- JINMEI, Tatuya
>


From nobody Mon Mar 27 17:51:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DA112963F for ; Mon, 27 Mar 2017 17:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.402
X-Spam-Level: 
X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xwZE5PwXxDDA for ; Mon, 27 Mar 2017 17:51:01 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEC8128C81 for ; Mon, 27 Mar 2017 17:51:00 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id p22so53685789qka.3 for ; Mon, 27 Mar 2017 17:51:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YFKQetWGpdBuLmrfJG9+lq96pi9/FN4qcmB9lzG/X8A=; b=r9r7GsghkCnwWTc39EoZpjG/EEuavp54w6Y/Xim4pMt3jBoxzBhhJkUgnJq3hKfPmK a5kYbsr9yFZSNAOEHIQ4yAVfJx/JrJpb/OTKnzP4MCinKvIntynLNVYvCLer97YMnR0b rJwhQpwZlfl1thuQOORxwpXaJ1srBSoSnWJgnYRnIlPQy555BHMuVcRdEkxS8vtgDDuZ 2NcNLa4s7NNB1qZnJJO+ilwtlHpOJUkjFbE4cYUvgHpc4uGX6HYaMdMQXhOHI/W3odo3 2DPCOzj/z70gnob3em4POnKAn9ygifTin5GPJVgYSKCCwYkwHjmugAwox+0iBbEdm5cm jf9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YFKQetWGpdBuLmrfJG9+lq96pi9/FN4qcmB9lzG/X8A=; b=tZqfZKJShjYnVw/y8hiyIJdA28CQfP4u8fkG4daGkMnpWiCUqYj3kf7zyXeyY1qpA/ uDOK82vv/wt294oJofSQI/YRVuMQuwgpEfPUDXKtiEmTW1m110/wOhkGnDncFTSIa6Wc kbJlFYT1sHOtkfrVyl1qYqADQdAiKsla2nTtxvkzvBPmjMgEASpYJkbCZuKGYKbVnnHD V6gcSy6kSXGMBbEjQ6KhL5ytCk6sJmXsFM5iubgOmKQu7W43eYJB0ZTD6WzSMMsj7a0H 7q6LAQI7mlhrKopmzA8VEXKbNKqv22qJPlBleLtjVyZOv3KmkmOcEF3iciophczpdHq1 3yNw==
X-Gm-Message-State: AFeK/H2e+G+/8gpwDZJS/mqmr4GMbLX7Fs9ZL1FbBwfvl5B66tinTLy+xfm/5RqSeAbJD2UolNpMTBmfvBdjkg==
X-Received: by 10.55.165.205 with SMTP id o196mr22005371qke.20.1490662259885;  Mon, 27 Mar 2017 17:50:59 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Mon, 27 Mar 2017 17:50:59 -0700 (PDT)
In-Reply-To: 
References: <20170223134026.GI5069@gir.theapt.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com>      <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>      
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Mon, 27 Mar 2017 17:50:59 -0700
X-Google-Sender-Auth: yDztmfH-wbspcC2gJhjmwaJ1Hls
Message-ID: 
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Alexandre Petrescu 
Cc: 6man WG 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 00:51:03 -0000

At Mon, 27 Mar 2017 17:25:02 -0500,
Alexandre Petrescu  wrote:

> > fe81::/10 is just an "abnormal" form of fe80::/10,
>
> Err, I dont think fe81::/10 is an abnormal LL.  I think fe81::/10,
> fe82::/10, ... febf::/10 are all normal forms of LL.

By abnormal I meant setting the tenth bit is meaningless just as
illustrated here:

> fe80::/10 is: 1111 1110 10
> fe81::/10 is: 1111 1110 10

But in any case, I believe my previous message answered your main
question.

--
JINMEI, Tatuya


From nobody Mon Mar 27 17:53:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E35A1296F4 for ; Mon, 27 Mar 2017 17:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level: 
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 z3wSenVSTsyf for ; Mon, 27 Mar 2017 17:53:19 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0212F1296CE for ; Mon, 27 Mar 2017 17:53:19 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id f11so53670936qkb.0 for ; Mon, 27 Mar 2017 17:53:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5wCkLuyn38dxRIRFlvvFgZlnyV/CNvyEv1ZaxjJjefk=; b=nYvtuVTZOwRcK4PBzuVnXqKpgSMozMGY1oz4BCBkbaNuPhryL2ITCDddTnrHRog4LB um8/+gkHFbKexGXYlNoh4Jsab07HwOUY06pABkwZtc07XbPNN4oKxUSwOl61NgGIPl+t HgWuj8ahmHzKZrfAqlMpd/3VD6ZMo7a8xmnMzehMzC1TxzaumCHQ0yAInDIrUAtw12Mb Kpst41coMSochQBjgv1J5V+rljwI97XSoQQSuWtQL+j1/Suo/XD9QG+e2By+2ebhv31r HubXV2vVhSbpjVR9dqXpFqkOQ3msnGQw+9FMVGTFWo5yw+fI6C+nPr0beLPNAgN+wkMI Uk2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5wCkLuyn38dxRIRFlvvFgZlnyV/CNvyEv1ZaxjJjefk=; b=mfdHnlBj5AQtQU4nAXdf1JkmmdaZEV4lPbv8ZXjpMTFvXFwpNKdgjsZMWDnxfEN5Mz ll9SkkXHr5e7v+BfG+OZdEPBcw0jzYH85tBAWkHEXCqh726SKEietdxtSXpJB6rwer5A FjNpGmM8KQwTmnCNo5dWLZwCmzf9BIQnFm/3hvK8d91sOvyeQBWxjBSe69KASy5LlUO8 HvCdSrx9YWRN6jF6OlMclzXH2DxP1FkiE04x5wunbjR3qb0E9jbz8rUIKK3kx+IKxK4I /yjTKkAMXa7vslYSxBvvD9qO26qxVrQrJhp46Z/OgWnCS75MdY1nhtny9LLf0VZs7ilH vveg==
X-Gm-Message-State: AFeK/H3c6s6bszkCne27GHK+IbelMrgMHnPg0Etl7mXb/u+Y1rn1pAn50GhLzrYCr7x3nktGBWrQPCtGZLXukw==
X-Received: by 10.55.189.130 with SMTP id n124mr23949847qkf.235.1490662398125;  Mon, 27 Mar 2017 17:53:18 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Mon, 27 Mar 2017 17:53:17 -0700 (PDT)
In-Reply-To: 
References: <20170223134026.GI5069@gir.theapt.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com>      <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>       
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Mon, 27 Mar 2017 17:53:17 -0700
X-Google-Sender-Auth: J8g_MHiXv83_6iOp9DnBixt--uY
Message-ID: 
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Alexandre Petrescu 
Cc: 6man WG 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 00:53:20 -0000

On Mon, Mar 27, 2017 at 5:50 PM  wrote:

>> > fe81::/10 is just an "abnormal" form of fe80::/10,
>>
>> Err, I dont think fe81::/10 is an abnormal LL.  I think fe81::/10,
>> fe82::/10, ... febf::/10 are all normal forms of LL.
>
> By abnormal I meant setting the tenth bit is meaningless

Oops, it should be "the 16th bit".  Sorry for the noise.

--
JINMEI, Tatuya


From nobody Mon Mar 27 18:11:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8401297ED for ; Mon, 27 Mar 2017 18:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 mwV8d9UBLExX for ; Mon, 27 Mar 2017 18:11:46 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4841297CA for ; Mon, 27 Mar 2017 18:11:45 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2S1BiYB020590; Tue, 28 Mar 2017 03:11:44 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 11320200FF2; Tue, 28 Mar 2017 03:11:44 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 044BC200B59; Tue, 28 Mar 2017 03:11:44 +0200 (CEST)
Received: from [132.166.84.16] ([132.166.84.16]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2S1BgxG008017; Tue, 28 Mar 2017 03:11:43 +0200
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
References: <20170223134026.GI5069@gir.theapt.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com>      <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>     
Cc: 6man WG 
From: Alexandre Petrescu 
Message-ID: <4e4f9c9a-96d8-2c5a-3c9b-12ea5ca5f2da@gmail.com>
Date: Mon, 27 Mar 2017 20:11:24 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 01:11:48 -0000

Le 27/03/2017 à 16:24, 神明é”哉 a écrit :
> At Mon, 27 Mar 2017 16:00:58 -0500,
> Alexandre Petrescu  wrote:
>
>>> On the other hand, BSDs' implementation of the IN6_IS_ADDR_LINKLOCAL()
>>> macro only checks the first 10 bits:
>>>
>>> #define IN6_IS_ADDR_LINKLOCAL(a)        \
>>>         (((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))
>>
>> Tatuya, masking it that way it means that fe81::/10 is also recognized
>> as an LL address prefix, right?  I think it is good, but just checking.
>
> fe81::/10 is just an "abnormal" form of fe80::/10, but I guess you
> actually meant fe81::/16.  Assuming so, your understanding is correct:
> an address that matches fe81::/16 is recognized as unicast link-local
> wherever the IN6_IS_ADDR_LINKLOCAL macro is used for the test.  For
> example, BSD kernels consider this kind of address to be unicast
> link-local in the validation of received RA:
>
>     if (!IN6_IS_ADDR_LINKLOCAL(&saddr6)) {
>         nd6log((LOG_ERR,
>             "nd6_ra_input: src %s is not link-local\n",
>             ip6_sprintf(ip6bufs, &saddr6)));
>         goto bad;
>     }
> (this code only checks the first 10 bits).

If this code runs on an Ethernet interface, then I think it is wrong. 
BEcause the link-local prefix on an Ethernet interface is fe80::/64, and 
not fe80::/10.

IN6_IS_ADDR_LINK_LOCAL run on Ethernet should use a mask of 64bits, not 
10bits, as it currently does.

In general, a generic IN6_IS_ADDR_LINKLOCAL is good to use a /10 mask. 
But some different IN6_IS_ADDR_LINK_LOCAL_ETHERNET is good with mask /64.

fe81::1 on Ethernet is not a Link Local address.

fe81::1 in general _is_ a Link Local address.

(and, yes, ideally, it would be good to make that 64 a parameter even of 
Ethernet, but that is a separate discussion).

Alex

>
> --
> JINMEI, Tatuya
>


From nobody Mon Mar 27 18:16:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3EB1297CB for ; Mon, 27 Mar 2017 18:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 DVGjUG4Bgz7l for ; Mon, 27 Mar 2017 18:16:30 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575601200F1 for ; Mon, 27 Mar 2017 18:16:30 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2S1GS6F024494; Tue, 28 Mar 2017 03:16:28 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C330E201917; Tue, 28 Mar 2017 03:16:28 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B687220110A; Tue, 28 Mar 2017 03:16:28 +0200 (CEST)
Received: from [132.166.84.16] ([132.166.84.16]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2S1GRhx008998; Tue, 28 Mar 2017 03:16:28 +0200
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
References: <20170223134026.GI5069@gir.theapt.org>    <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>        
Cc: 6man WG 
From: Alexandre Petrescu 
Message-ID: 
Date: Mon, 27 Mar 2017 20:16:09 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 01:16:31 -0000

Le 27/03/2017 à 19:53, 神明é”哉 a écrit :
> On Mon, Mar 27, 2017 at 5:50 PM  wrote:
>
>>>> fe81::/10 is just an "abnormal" form of fe80::/10,
>>>
>>> Err, I dont think fe81::/10 is an abnormal LL.  I think fe81::/10,
>>> fe82::/10, ... febf::/10 are all normal forms of LL.
>>
>> By abnormal I meant setting the tenth bit is meaningless
>
> Oops, it should be "the 16th bit".  Sorry for the noise.

Well, I agree setting the 16th bit can be meaningless, because it is 
beyond the first hextet.

fe80:1::/10 is too long, because that "1" is way beyond the 10th bit.

But fe81::/10 is not meaningless.

fe80::/10 is not more meaningful than fe81::/10.

Actually one can wonder why RFC writers decided to write fe80::/10 when 
they could have written fe81::/10 equaly well.  Or even fe90::/10 or 
febf::/10.  All these designate the same 10bits - the mask 1111 1110 10.

Alex

>
> --
> JINMEI, Tatuya
>


From nobody Tue Mar 28 00:02:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4942F126C7B for ; Tue, 28 Mar 2017 00:02:50 -0700 (PDT)
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 autolearn_force=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 eeyQHZfg5a9L for ; Tue, 28 Mar 2017 00:02:48 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728FB129874 for ; Tue, 28 Mar 2017 00:02:42 -0700 (PDT)
X-Quarantine-ID: <5P0b75E0Q8MC>
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <20[...]
Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 01AC01BC37 for ; Tue, 28 Mar 2017 07:02:44 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
From: Simon Hobson 
In-Reply-To: 
Date: Tue, 28 Mar 2017 08:02:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20170223134026.GI5069@gir.theapt.org>    <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>         
To: 6man WG 
X-Mailer: Apple Mail (2.1510)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 07:02:50 -0000

Alexandre Petrescu  wrote:

> Actually one can wonder why RFC writers decided to write fe80::/10 =
when they could have written fe81::/10 equaly well.  Or even fe90::/10 =
or febf::/10.  All these designate the same 10bits - the mask 1111 1110 =
10.

I thought this was answered a good few messages ago. It is customary to =
always write the "lowest value that fits" - ie the one where all the =
non-prefix bits are zero.
So fe80::/10 fits - all the bits after the first 10 are zero
fe81::/10 does not fit - when you mask off the non-prefix bits you get a =
different value

So while in terms of maths, after doing the masking you get the same =
result, by not applying the "all host bits are zero" rule - you have =
introduced confusion for humans.

As pointed out, 172.17.0.0/12 might make as much sense as 172.16.0.0/12 =
IFF you ignore this feature. Applying the mask to 172.17.0.0/12 gives =
you non-zero host bits - hence why we don't use that.
It's all to do with consistency and avoidance of confusion. And we need =
as much of that as we can - I know plenty of supposedly network capable =
people who cannot understand the concept of 172.16.1.0/23 being a valid =
IP address !

But to be frank, I still can't see what the proposal is about - just =
what use case does it solve ?


From nobody Tue Mar 28 05:47:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C53129525 for ; Tue, 28 Mar 2017 05:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 cle6h75tcNHK for ; Tue, 28 Mar 2017 05:47:25 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19A2128BB6 for ; Tue, 28 Mar 2017 05:47:24 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2SClMTO193831 for ; Tue, 28 Mar 2017 14:47:22 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9F1CD202653 for ; Tue, 28 Mar 2017 14:47:22 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9592F205FE1 for ; Tue, 28 Mar 2017 14:47:22 +0200 (CEST)
Received: from [132.166.84.132] ([132.166.84.132]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2SClI6Q020006 for ; Tue, 28 Mar 2017 14:47:20 +0200
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: ipv6@ietf.org
References: <20170223134026.GI5069@gir.theapt.org>  <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>          
From: Alexandre Petrescu 
Message-ID: <1b6154d2-14a7-0d85-7a81-18a5367c0330@gmail.com>
Date: Tue, 28 Mar 2017 07:46:59 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 12:47:27 -0000

Le 28/03/2017 à 02:02, Simon Hobson a écrit :
> Alexandre Petrescu  wrote:
>
>> Actually one can wonder why RFC writers decided to write fe80::/10
>> when they could have written fe81::/10 equaly well.  Or even
>> fe90::/10 or febf::/10.  All these designate the same 10bits - the
>> mask 1111 1110 10.
>
> I thought this was answered a good few messages ago.

I did not see?

> It is customary to always write the "lowest value that fits"

I did not know it was customary?  Maybe it should be documented.

As opposed to IPv4 decimal notation, in IPv6 hexa it's very difficult to
compare visually two IPv6 addresses, and tell which is lower value.

> - ie the one where all the non-prefix bits are zero. So fe80::/10
> fits - all the bits after the first 10 are zero fe81::/10 does not
> fit - when you mask off the non-prefix bits you get a different
> value

Well, makes sense.

But from this to say that LL addresses are _only_ those that start with
fe80 there is a long way.

> So while in terms of maths, after doing the masking you get the same
> result, by not applying the "all host bits are zero" rule - you have
> introduced confusion for humans.

Ok.

But humans introduce further confusion when mandating these host bits to
be 0.

These bits are not necessarily 0 - they can be whatever.

That is a need to say 'whatever' - not necessarily '0'.

> As pointed out, 172.17.0.0/12 might make as much sense as
> 172.16.0.0/12 IFF you ignore this feature. Applying the mask to
> 172.17.0.0/12 gives you non-zero host bits -

A-ha!  I did not know that.

> hence why we don't use that. It's all to do with consistency and
> avoidance of confusion. And we need as much of that as we can - I
> know plenty of supposedly network capable people who cannot
> understand the concept of 172.16.1.0/23 being a valid IP address !

But there should be a way to say that 172.16.0.0/12 is just one valid 
example, not the only one.

That 172.17.0.0/12 is also a private address.

Just like when one types 'ls abc*' vs typing 'ls abcd'.

That is the need.

> But to be frank, I still can't see what the proposal is about - just
> what use case does it solve ?

Well, the discussion is issued from the following observations:
- rfc4291bis calls it fe80::/10 with a 64bit IID, whereas rfc2464bis
   calls it fe80::/64 - which is right?
- BSD code recognizes an LL address by its 10 first bits only (not by
   64): it drops an ND message if not convinced.  That is reason enough
   to visit the problem closely.
- much f2f conversation calls ULA an "fd00" and an LL an "fe80".  This
   goes very far when assigning addresses on interfaces.  Few if any
   assign an "fe81" or an "fc00", although both are correct LL and ULA
   respectively.

And I think it is so because of the textual representation of IPv6
addresses.

Alex

>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


From nobody Tue Mar 28 06:20:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F799129539 for ; Tue, 28 Mar 2017 06:20:16 -0700 (PDT)
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 autolearn_force=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 8KtKYZi_HLMb for ; Tue, 28 Mar 2017 06:20:13 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED34129680 for ; Tue, 28 Mar 2017 06:20:12 -0700 (PDT)
X-Quarantine-ID: <6V-9beGwcH_8>
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <20[...]
Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 070041BC37 for ; Tue, 28 Mar 2017 13:20:23 +0000 (UTC)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
From: Simon Hobson 
In-Reply-To: <1b6154d2-14a7-0d85-7a81-18a5367c0330@gmail.com>
Date: Tue, 28 Mar 2017 14:19:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <33465746-86AA-4F1E-974F-63208A6928AA@thehobsons.co.uk>
References: <20170223134026.GI5069@gir.theapt.org>  <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>           <1b6154d2-14a7-0d85-7a81-18a5367c03 30@gmail.com>
To: ipv6@ietf.org
X-Mailer: Apple Mail (2.1510)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 13:20:16 -0000

Alexandre Petrescu  wrote:

>> It is customary to always write the "lowest value that fits"
>=20
> I did not know it was customary?  Maybe it should be documented.

It probably is somewhere - but I'm not a walking encyclopaedia of RFCs 1

> As opposed to IPv4 decimal notation, in IPv6 hexa it's very difficult =
to
> compare visually two IPv6 addresses, and tell which is lower value.
>=20
>> - ie the one where all the non-prefix bits are zero. So fe80::/10
>> fits - all the bits after the first 10 are zero fe81::/10 does not
>> fit - when you mask off the non-prefix bits you get a different
>> value
>=20
> Well, makes sense.
>=20
> But from this to say that LL addresses are _only_ those that start =
with
> fe80 there is a long way.
>=20
>> So while in terms of maths, after doing the masking you get the same
>> result, by not applying the "all host bits are zero" rule - you have
>> introduced confusion for humans.
>=20
> Ok.
>=20
> But humans introduce further confusion when mandating these host bits =
to
> be 0.
>=20
> These bits are not necessarily 0 - they can be whatever.

It depends on the context. If you are talking about a HOST address, then =
clearly the host identifier part of the address will be non-zero. If you =
are talking about a subnet (or prefix on IPv6 terminology) then it's =
non-sensical to have the host identifier non-zero.

Taking a simple example. If you talk about 192.168.0.123/24 then I'd =
take that as meaning the host with host identifier "123" in the subnet =
192.168.0.0/24. If you used it in the context of anything other than =
talking about a host address then I;d take you task for not using the =
*network* address of 192.168.0.0/24.

>> hence why we don't use that. It's all to do with consistency and
>> avoidance of confusion. And we need as much of that as we can - I
>> know plenty of supposedly network capable people who cannot
>> understand the concept of 172.16.1.0/23 being a valid IP address !
>=20
> But there should be a way to say that 172.16.0.0/12 is just one valid =
example, not the only one.
>=20
> That 172.17.0.0/12 is also a private address.

172.17.0.0/12 is a HOST address, it is not a NETWORK address. As =
explained above, if you apply the right operations, it comes down to =
being HOST 1.0.0 in NETWORK 172.16.0.0/12. There is absolutely no =
confusion here, that's really basic IPv4 operations. Sadly a lot of =
people can't cope with these basics !

> Just like when one types 'ls abc*' vs typing 'ls abcd'.

Those two commands are not the same. The first is about all files =
starting abc (analogous to all IPs or hosts in a subnet), the second is =
about the one file abcd (analogous to a single IP/host in a network).

>> But to be frank, I still can't see what the proposal is about - just
>> what use case does it solve ?
>=20
> Well, the discussion is issued from the following observations:
> - rfc4291bis calls it fe80::/10 with a 64bit IID, whereas rfc2464bis
>  calls it fe80::/64 - which is right?

Right, so this is really nothing about using masks, prefix notation, etc =
- it's purely that somewhere along the line there's been an =
inconsistency in definition. One definition says one thing, another says =
something else.
By one definition, fe81:: is a link local address, while =
by another definition it isn't.
I would suggest that the way to deal with that is to discuss which is =
correct and have one or both RFCs updated so they say the same thing. =
Unless there's something in the context that makes them both right.
Given that there are implementations "in the wild" relying on =
fe80::/64, it might be hard to settle on the wider ranging =
definition and accept that the rest of fe80::/10 is effectively lost to =
other uses - having been lost in the gap between the definitions.



From nobody Tue Mar 28 06:53:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3542C129528 for ; Tue, 28 Mar 2017 06:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 9joB72IA9H2j for ; Tue, 28 Mar 2017 06:53:23 -0700 (PDT)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id DE9001296B5 for ; Tue, 28 Mar 2017 06:53:22 -0700 (PDT)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Mar 2017 13:53:21 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B4841D788D; Tue, 28 Mar 2017 06:53:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=BXvF1avBg/SgfQHhp9nIX1QmDOo=; b= FlW22ruEmlF13LUXKu4ooIu9I+C3PzDTlfWGz+2T9gPZtzbZFXH2PO/ekH816VyM 5GouiP7WGmT1cOhpabI5Gl8ddrmQbIduxJMxoNU5hZJrCriKTo9iOlthkGTTFJKc N/1jBzuAS0UwEGToftmWqfHwXdZ33OxwD2D10IInYRE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=aR7CrEVPUjvp2FUOWkYHE8/ 8jpesgGFvu/W+Wx4WSsieTH6/d6JazKZr+SgweBQKblLdz64Va9iwxYsQQjw2obg nnMq9waY8Vn3fuDXNq8UNsTW4w3SJwo7iQVtZ4bD59Gl5sx5L0eepN4FyXBGWDrS 5oTEbKYfdHUxFcBMUJfE=
Received: from h.hanazo.no (dhcp-8e77.meeting.ietf.org [31.133.142.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 8F46FD788B; Tue, 28 Mar 2017 06:53:21 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D648BA588159; Tue, 28 Mar 2017 08:53:20 -0500 (CDT)
From: otroan@employees.org
Message-Id: <280A3E09-956C-4803-A940-0DDEA5F87A93@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_8B428D1D-78FF-4BDC-AA2B-3A8E2AB9D774"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
Date: Tue, 28 Mar 2017 08:53:18 -0500
In-Reply-To: <1b6154d2-14a7-0d85-7a81-18a5367c0330@gmail.com>
Cc: 6man WG 
To: Alexandre Petrescu 
References: <20170223134026.GI5069@gir.theapt.org>  <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>           <1b6154d2-14a7-0d85-7a81-18a5367c0330@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 13:53:26 -0000

--Apple-Mail=_8B428D1D-78FF-4BDC-AA2B-3A8E2AB9D774
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Alexandre,

I think we have spent enough time on this subject now.
If you want to discuss this further I suggest you do that off-line.

Best regards,
Ole

> On 28 Mar 2017, at 07:46, Alexandre Petrescu =
 wrote:
>=20
>=20
>=20
> Le 28/03/2017 =C3=A0 02:02, Simon Hobson a =C3=A9crit :
>> Alexandre Petrescu  wrote:
>>=20
>>> Actually one can wonder why RFC writers decided to write fe80::/10
>>> when they could have written fe81::/10 equaly well.  Or even
>>> fe90::/10 or febf::/10.  All these designate the same 10bits - the
>>> mask 1111 1110 10.
>>=20
>> I thought this was answered a good few messages ago.
>=20
> I did not see?
>=20
>> It is customary to always write the "lowest value that fits"
>=20
> I did not know it was customary?  Maybe it should be documented.
>=20
> As opposed to IPv4 decimal notation, in IPv6 hexa it's very difficult =
to
> compare visually two IPv6 addresses, and tell which is lower value.
>=20
>> - ie the one where all the non-prefix bits are zero. So fe80::/10
>> fits - all the bits after the first 10 are zero fe81::/10 does not
>> fit - when you mask off the non-prefix bits you get a different
>> value
>=20
> Well, makes sense.
>=20
> But from this to say that LL addresses are _only_ those that start =
with
> fe80 there is a long way.
>=20
>> So while in terms of maths, after doing the masking you get the same
>> result, by not applying the "all host bits are zero" rule - you have
>> introduced confusion for humans.
>=20
> Ok.
>=20
> But humans introduce further confusion when mandating these host bits =
to
> be 0.
>=20
> These bits are not necessarily 0 - they can be whatever.
>=20
> That is a need to say 'whatever' - not necessarily '0'.
>=20
>> As pointed out, 172.17.0.0/12 might make as much sense as
>> 172.16.0.0/12 IFF you ignore this feature. Applying the mask to
>> 172.17.0.0/12 gives you non-zero host bits -
>=20
> A-ha!  I did not know that.
>=20
>> hence why we don't use that. It's all to do with consistency and
>> avoidance of confusion. And we need as much of that as we can - I
>> know plenty of supposedly network capable people who cannot
>> understand the concept of 172.16.1.0/23 being a valid IP address !
>=20
> But there should be a way to say that 172.16.0.0/12 is just one valid =
example, not the only one.
>=20
> That 172.17.0.0/12 is also a private address.
>=20
> Just like when one types 'ls abc*' vs typing 'ls abcd'.
>=20
> That is the need.
>=20
>> But to be frank, I still can't see what the proposal is about - just
>> what use case does it solve ?
>=20
> Well, the discussion is issued from the following observations:
> - rfc4291bis calls it fe80::/10 with a 64bit IID, whereas rfc2464bis
>  calls it fe80::/64 - which is right?
> - BSD code recognizes an LL address by its 10 first bits only (not by
>  64): it drops an ND message if not convinced.  That is reason enough
>  to visit the problem closely.
> - much f2f conversation calls ULA an "fd00" and an LL an "fe80".  This
>  goes very far when assigning addresses on interfaces.  Few if any
>  assign an "fe81" or an "fc00", although both are correct LL and ULA
>  respectively.
>=20
> And I think it is so because of the textual representation of IPv6
> addresses.
>=20
> Alex
>=20
>>=20
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--Apple-Mail=_8B428D1D-78FF-4BDC-AA2B-3A8E2AB9D774
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJY2mrPAAoJEL7aWKiYQt92TIwP/RnCSYr4Wlk8wNo/CTD2CMzm
Ikhs/o1qN/bkTi5KV+MFhRFgd4dmtMTopyOMDacXLMNAqfiPZ+da9qnTRGuttKSk
Lk+Z+fo098dTgdrZg7X+goBD1Aq8i2PbefUQJMNC1GgpmKsdJkH5ObwmSI4B0Y1/
XbA6q/XlM+REWNPQTc+PLRtUcSxiH9TPtXjko8cnQOSpqw9RH9abIBI/YTHNw5Gr
Pp3/bNcvJrnbjQE8+zoXRjkvfEjQUAXoPkK8lgnl4JZnnIS73pv9lqHcdD0OV+hm
DSPDlXimhvXzPmEyafvB15wRF6UzItJebT+f98uKp0gHftqnbV/UMktNqp8wwAG5
nyWr7Kcc66uNUnbgXhJLvr9gGRtl2qzXa2K8A5uf98IO1Z6SCJgYK21O3jsNtSs/
axfA6gzsXFugYw1BvcW9NlDEJkBW3SM9l4f+aCMZaHc4E0vi+CacIpK3hl7It1il
QeuPLO4/LlTyLUYALvr2Yt76eiWBBpp3vhYibkSu0y/oZOBtqsoumKkGTNYthF+t
/ZATOdULOSf/LDS5DrfED8RLIVi10mrug5vE5ffpKd9CD2TyajQBw3tWfr9go7wX
cOWp5uO57sNTFhM0RLsQthr4eIRcmk1/xXTbh/sCLN8R6jC6RkieFy00hOhmQBov
AdsBjjcjzOyYAiCbdD+V
=5WCh
-----END PGP SIGNATURE-----

--Apple-Mail=_8B428D1D-78FF-4BDC-AA2B-3A8E2AB9D774--


From nobody Tue Mar 28 08:17:21 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E371289C3 for ; Tue, 28 Mar 2017 08:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 g4Exlmtan0FM for ; Tue, 28 Mar 2017 08:17:17 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722C2128B88 for ; Tue, 28 Mar 2017 08:17:17 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2SFHCTb017157; Tue, 28 Mar 2017 17:17:12 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4CD3520BFD9; Tue, 28 Mar 2017 17:17:12 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3DDDF207FC2; Tue, 28 Mar 2017 17:17:12 +0200 (CEST)
Received: from [132.166.84.91] ([132.166.84.91]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2SFHAbP021079; Tue, 28 Mar 2017 17:17:11 +0200
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt and rfc2464bis
To: otroan@employees.org
References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>           <1b6154d2-14a7-0d85-7a81-18a5367c0330@gmail.com> <280A3E09-956C-4803-A940-0DDEA5F87A93@employees.org>
Cc: 6man WG 
From: Alexandre Petrescu 
Message-ID: 
Date: Tue, 28 Mar 2017 10:16:51 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <280A3E09-956C-4803-A940-0DDEA5F87A93@employees.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 15:17:20 -0000

Ole,

With all due respect.

Who do you think I should contact off-line?

I do not agree with rfc2464bis saying:
> 5.  Link-Local Addresses
>
>    The IPv6 link-local address [I-D.ietf-6man-rfc4291bis] for an
>    Ethernet interface is formed by appending the Interface Identifier,
>    as defined above, to the prefix FE80::/64.

I have not seen a resolution to it.

You may qualify my messages as being too many, but all I am trying to 
say is to clarify it.

Yours,

Alex

Le 28/03/2017 à 08:53, otroan@employees.org a écrit :
> Alexandre,
>
> I think we have spent enough time on this subject now.
> If you want to discuss this further I suggest you do that off-line.
>
> Best regards,
> Ole
>
>> On 28 Mar 2017, at 07:46, Alexandre Petrescu  wrote:
>>
>>
>>
>> Le 28/03/2017 à 02:02, Simon Hobson a écrit :
>>> Alexandre Petrescu  wrote:
>>>
>>>> Actually one can wonder why RFC writers decided to write fe80::/10
>>>> when they could have written fe81::/10 equaly well.  Or even
>>>> fe90::/10 or febf::/10.  All these designate the same 10bits - the
>>>> mask 1111 1110 10.
>>>
>>> I thought this was answered a good few messages ago.
>>
>> I did not see?
>>
>>> It is customary to always write the "lowest value that fits"
>>
>> I did not know it was customary?  Maybe it should be documented.
>>
>> As opposed to IPv4 decimal notation, in IPv6 hexa it's very difficult to
>> compare visually two IPv6 addresses, and tell which is lower value.
>>
>>> - ie the one where all the non-prefix bits are zero. So fe80::/10
>>> fits - all the bits after the first 10 are zero fe81::/10 does not
>>> fit - when you mask off the non-prefix bits you get a different
>>> value
>>
>> Well, makes sense.
>>
>> But from this to say that LL addresses are _only_ those that start with
>> fe80 there is a long way.
>>
>>> So while in terms of maths, after doing the masking you get the same
>>> result, by not applying the "all host bits are zero" rule - you have
>>> introduced confusion for humans.
>>
>> Ok.
>>
>> But humans introduce further confusion when mandating these host bits to
>> be 0.
>>
>> These bits are not necessarily 0 - they can be whatever.
>>
>> That is a need to say 'whatever' - not necessarily '0'.
>>
>>> As pointed out, 172.17.0.0/12 might make as much sense as
>>> 172.16.0.0/12 IFF you ignore this feature. Applying the mask to
>>> 172.17.0.0/12 gives you non-zero host bits -
>>
>> A-ha!  I did not know that.
>>
>>> hence why we don't use that. It's all to do with consistency and
>>> avoidance of confusion. And we need as much of that as we can - I
>>> know plenty of supposedly network capable people who cannot
>>> understand the concept of 172.16.1.0/23 being a valid IP address !
>>
>> But there should be a way to say that 172.16.0.0/12 is just one valid example, not the only one.
>>
>> That 172.17.0.0/12 is also a private address.
>>
>> Just like when one types 'ls abc*' vs typing 'ls abcd'.
>>
>> That is the need.
>>
>>> But to be frank, I still can't see what the proposal is about - just
>>> what use case does it solve ?
>>
>> Well, the discussion is issued from the following observations:
>> - rfc4291bis calls it fe80::/10 with a 64bit IID, whereas rfc2464bis
>>  calls it fe80::/64 - which is right?
>> - BSD code recognizes an LL address by its 10 first bits only (not by
>>  64): it drops an ND message if not convinced.  That is reason enough
>>  to visit the problem closely.
>> - much f2f conversation calls ULA an "fd00" and an LL an "fe80".  This
>>  goes very far when assigning addresses on interfaces.  Few if any
>>  assign an "fe81" or an "fc00", although both are correct LL and ULA
>>  respectively.
>>
>> And I think it is so because of the textual representation of IPv6
>> addresses.
>>
>> Alex
>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>


From nobody Tue Mar 28 08:30:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D8212947D for ; Tue, 28 Mar 2017 08:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 7SxPN2Y9QZ63 for ; Tue, 28 Mar 2017 08:30:50 -0700 (PDT)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6AB12953B for ; Tue, 28 Mar 2017 08:30:43 -0700 (PDT)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Mar 2017 15:30:42 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 205BBD788B; Tue, 28 Mar 2017 08:30:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=+pH4IylU3xn9n7iTcztaK9/0pXM=; b= GjnDKKELVs+nZX+lnzMrM6ZlPnpUfLN3JnRtNwUivax3IZLzZqsWYxbVFHQ01gGM aZINkCWzw4cOmUPJE3LdOzcEbyN78pJuFq9b4RUaPxZg7EQNuZla4tfwqqTqBgtU 9qnDQ+GZetj0g1GXWYHGtkzGsVklp180JpkXl3EuAcI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=nIejo3hIRtBgDNE0dYSbFpL RKJgwRZJdoHaJNGeWHnhRlxLjztU+9deutvHFXXszRSVN6YWcXuI1tNuedumXAL2 36UnxHHZE2trRSV5LnP+1lb6B4NLghXnsw0OxPy8QHywqm/3C+mw2VA66xecnNN/ qqKLVzXbQi9ni8fRxYX0=
Received: from h.hanazo.no (dhcp-8e77.meeting.ietf.org [31.133.142.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 037F4D788A; Tue, 28 Mar 2017 08:30:42 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 673E4A59DED2; Tue, 28 Mar 2017 10:30:41 -0500 (CDT)
From: otroan@employees.org
Message-Id: <20BEF7EB-CA19-444C-92C4-F8A94E7B06F8@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_74E64B07-398B-4AD0-B8F2-CBC9BE628641"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt and rfc2464bis
Date: Tue, 28 Mar 2017 10:30:40 -0500
In-Reply-To: 
Cc: 6man WG 
To: Alexandre Petrescu 
References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>           <1b6154d2-14a7-0d85-7a81-18a5367c0330@gmail.com> <280A3E09-956C-4803-A940-0DDEA5F87A93@employees.org> 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 15:30:52 -0000

--Apple-Mail=_74E64B07-398B-4AD0-B8F2-CBC9BE628641
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Alexandre,

> Who do you think I should contact off-line?

=46rom the chairs perspective it seems like you are in the rough seeing =
a problem here.
Since we are both at the IETF, why don't we and whomever else is =
interested sit down and talk this over?

> I do not agree with rfc2464bis saying:
>> 5.  Link-Local Addresses
>>=20
>>   The IPv6 link-local address [I-D.ietf-6man-rfc4291bis] for an
>>   Ethernet interface is formed by appending the Interface Identifier,
>>   as defined above, to the prefix FE80::/64.
>=20
> I have not seen a resolution to it.
>=20
> You may qualify my messages as being too many, but all I am trying to =
say is to clarify it.

Then write a draft to that effect. I am unclear on what you are trying =
to achieve, and from the thread it doesn't appear many others get that =
either.

Best regards,
ole

--Apple-Mail=_74E64B07-398B-4AD0-B8F2-CBC9BE628641
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJY2oGhAAoJEL7aWKiYQt92sdsP/0bJTjC7rhmsDOmuM5PT9WoD
matUVeTzMrElyw/cRffSAHFntCpvrkEkHpUt5soEYmFvhZ0e/R5brqeZPd8Pb5TB
qRkn+EgovUQgU80iSd19yhHq4lDX5SOdcPtQhbHP7QDFuHtLgIaUvNGgLk0utJDl
Pn1C8cQTtbrPlp/OWNf9G6m/1rC3UJ+1iJv0lCkE+0+IIyMFXb4B6SJsjmCr0SVs
whTWnqJvsp1arhLajGin2e6+7sVxhYenXBzeZ2I0bphYHB6vqaZgBcc34rfhDmeh
KEMv2q+Mm7q38KDkV/+WHS0ig/oJtiirzCDsVWriuroahIQ9nxE4ArjDpEvWtUwR
a3FdNmnwZ0bQQ7HEUJvfFZpomvp4BsW0hvgf6Db0EJsoc2RViAsJvjjtCVIg/Jew
nyzDYIHKe5QEndnQ9cqcidWblV1YK2L+LhAfdHQTFKw5YunOifTpAr30sQtT/wYt
aGDOs0fTFgSgVxHdP4o8fTBUDEBOfpAfLEswLnrt/FbkmASWKX75P9I5y9UIYR0r
y+rD6jvj0ck7Hm5xnAmYW8N8bXSmiiYNrHKxlQ+eenpqMYtlNVwwaCFWm47zzpSC
O2U0bIU9Gws45uCWpEKh1Q15nI3GuJXU2eKS3bjy/PoYw1ijxVOeWvmzpbvXUCeW
w7TiZtrdQFNsE5ONX1iZ
=tkMI
-----END PGP SIGNATURE-----

--Apple-Mail=_74E64B07-398B-4AD0-B8F2-CBC9BE628641--


From nobody Tue Mar 28 08:41:46 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD86129449 for ; Tue, 28 Mar 2017 08:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level: 
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qAofDZwoa2kD for ; Tue, 28 Mar 2017 08:41:41 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DE7120725 for <6man@ietf.org>; Tue, 28 Mar 2017 08:41:37 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id i34so67590547qtc.0 for <6man@ietf.org>; Tue, 28 Mar 2017 08:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:from:date:message-id:subject:to; bh=Z8E21qpnm/zv7mZABvom9rVN2DbS9Vn1paGg7Ayo8rY=; b=g0sRZymyXnAgoUmADWDpFCl6Aag4CRK9x0G39gjBx7FktYPZ7iaI84ok7rL4sBE7ca W2EVjSHfyrcLMSZJfU/XsXa+mz3cYyEdiVbAzqIGrYDwLJp9QGLluRAmM0q7E2n4uZKS AT1Dek9wxHEL/nkuwwL7bvuVRUPSOJXurqpO9bCqmWUASqq9Omg+sToDjfLmx2RLL5W7 vkMuI2u0nz1pZNUxRLY6DG+s5/OpxDgJBQkqzzGV3sklxRRaVXu10Q4o/tUM4zn0eyNb XUv+Z4aXKg6fCDn21YvNy8M2HJtEvUL5eL1d1+AmlCXNoyyA0d48mUE8F/ojdviq/RVW cf6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Z8E21qpnm/zv7mZABvom9rVN2DbS9Vn1paGg7Ayo8rY=; b=g6vuFkuo4QiciMBLHLlArFUUwGfTUYY33SKl6sqbhqBQ4whmLlIfKl52MQ5rOtL0AY qzjyo53h/Ubpi5Cr1+JMzWAr0NeOQVvzXfS2oMONOXQd3ws37Ujm2vMozPIyBEfBFrrR /1DLi9QiSfnDKevRc3w8xWVtPMP24xrCysZBdL69Qvt5uHINwLUZvhIRJA79cAzC/lSq t7ncP3IaSitnRhQEvp/tftccvX73t2gWBCPPlWMxwEwHH5N345iUu7oAivutU7xMAjfM HjfUliP6qxo9Fjvk99KbctOqCUwgQMc5NFATIp+NlChlpvnlJyl2f+aUixPgUc7x2bUS hajw==
X-Gm-Message-State: AFeK/H1d0zFutkxQYwsnpiA9wRYgX2VEHyPxXNu4Tqzqc4JLS5w9xW8uBwFKs2uuT0fQpQPbaD1hbZenyieUhA==
X-Received: by 10.237.42.194 with SMTP id t60mr29332773qtd.269.1490715695729;  Tue, 28 Mar 2017 08:41:35 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Tue, 28 Mar 2017 08:41:35 -0700 (PDT)
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Tue, 28 Mar 2017 08:41:35 -0700
X-Google-Sender-Auth: QfnltsKZahKcbWu9MGuQ5N0zXZI
Message-ID: 
Subject: comments on draft-pioxfolks-6man-pio-exclusive-bit-01
To: "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 15:41:42 -0000

Some random comments and questions on
draft-pioxfolks-6man-pio-exclusive-bit-01:

- What should the host do if the X flag changes from on to off?

- Is there any intent to provide a larger prefix (i.e. smaller plen)
  than the prefix whose length is used for the traditional SLAAC?  For
  example, is it part of the intended usage to advertise a /56 with
  X=on when /64 is the length for SLAAC in that link?  If so, the
  following interpretation of Section 4.2.2 may not be really
  reasonable:
   o  interpret the A bit as it it were 1 (A=1)
  In fact, the X flag allows newer hosts that understand the flag to
  do more than the traditional A flag means: the host can generate an
  address on a different interface than the receiving interface of the
  RA, and it can even re-advertise the prefix in a "downstream" link.
  This is so even if we assume the traditional SLAAC prefix length.

- Perhaps this draft should say routers SHOULD NOT set the L flag of a
  PIO if it sets the X flag.

- I don't follow the following part of section 4.2.2.2:

   from an exclusive prefix to any available interface; it is not
   required to configure the address on the link over which the PIO-X RA
   was received (i.e. it is under no obligation to form addresses such
   that they would be classified as on-link (according to the definition
   in  section 4, item 1).

  The item of RFC5942 is this:

   1.  The assignment of an IPv6 address -- whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
       or manual configuration -- MUST NOT implicitly cause a prefix
       derived from that address to be treated as on-link and added to
       the Prefix List.  A host considers a prefix to be on-link only
       through explicit means, such as those specified in the on-link
       definition in the Terminology section of [RFC4861] (as modified
       by this document) or via manual configuration.  Note that the
       requirement for manually configured addresses is not explicitly
       mentioned in [RFC4861].

  First off, this items is not a "definition" but a requirement.
  Secondly, my interpretation of the requirement is just that we
  cannot assume a particular prefix as on-link derived from an
  address.  I don't see a clear relationship between this and the
  draft text, which states that the host can configure an address on a
  different interface.

  BTW, there's a missing closing parenthesis in the text.

--
JINMEI, Tatuya


From nobody Tue Mar 28 09:23:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4EA128B44 for ; Tue, 28 Mar 2017 09:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.402
X-Spam-Level: 
X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LjFBEJZwaIZo for ; Tue, 28 Mar 2017 09:23:45 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F57C128D40 for <6man@ietf.org>; Tue, 28 Mar 2017 09:23:43 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id p22so70127828qka.3 for <6man@ietf.org>; Tue, 28 Mar 2017 09:23:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:from:date:message-id:subject:to; bh=8WlbRUJFnwiSCzYJanzgTwHYeEzFVAYUH44Ui/mCK3Q=; b=TtIYDIP9Y6M5JY5omaFuO1iZyQtl6l/0FKcBSDDClRcp8fKNuyb5Bi5tvxpzZb/Oal 4oY9n3xX2BKbQczCfXN5LxnfRAAXzyE9eVkEGZO6MExs0qqVlz8SFt+rKziZ0lD7wvQu Telg1woe2MUKPMGB7y3s3Y/LWgxtX71Po+Mqz49vxpxf6TUhh9dHuSGedOxmt0h67hT7 wkbCqaIlnoho8Qws/5h1A4RTvB3uhPP4LYjKuS4/0MtVCXKNtoXmdU6eRG0oqZ352bUM o6s8SDZTLBcyHuPKMqkB8pexm0pCPOb9oCVo8mvfSVkfSjIfuxC8Q0V3oOH5Z/2Z3kwx PhYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=8WlbRUJFnwiSCzYJanzgTwHYeEzFVAYUH44Ui/mCK3Q=; b=HZATJSDSXw0NKkR2qqtT/1xGcJaV+WvBgXLI3YTMNGiXdUWFjIKZ36QGQpALzz7/t1 MkwVQe8m3bWLKzY520e6khlVi143ZJb1hhUXoFel7T0H94A8sAunB5S2gGSKaCIugUdX BqwAihKF1KzUWpXT9DJVi3naAkabxAime5PgV+ZL6YQv0PdrGJ9Z/ZfgJ0w6rSVIgqsH MyDbXiJv295KoxXOlFvqWt0VJLItBNdS/A8PdajaO5YEW49WfydzHV8cSoqwL5XHB4Ib HPL5o3c0spvp74DEa2vsXHABadcU6rELE8TI501CP/pxQ4rjarsIm4y7FZKEC4xfEWc/ p2OQ==
X-Gm-Message-State: AFeK/H0hntoDLT1mHJHrBeyE4s+2N63ECWl0uJgtniqkDgdOGvWphcLrJS35F3Z4tiLbyzMrPosQnsrt3HYG0A==
X-Received: by 10.55.165.205 with SMTP id o196mr25161268qke.20.1490718221904;  Tue, 28 Mar 2017 09:23:41 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Tue, 28 Mar 2017 09:23:41 -0700 (PDT)
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Tue, 28 Mar 2017 09:23:41 -0700
X-Google-Sender-Auth: 0ad1fsqtpP6IHWj7HEwkNt-zrBE
Message-ID: 
Subject: distinction between on-link and subnet prefix for rfc4291bis
To: "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 16:23:47 -0000

On seeing a discussion about this issue at the IEPG meeting,
http://iepg.org/2017-03-27-ietf98/JobSnijders_IPv6_prefix_length_IEPG_Chicago_2017.pdf
it occurred to me that the distinction between on-link and subnet
prefixes may help the "/64" discussion for rfc4291bis.

The presentation shows an example of manual interface configuration on
page 4 of http://iepg.org/2017-03-27-ietf98/JobSnijders_IPv6_prefix_length_IEPG_Chicago_2017.pdf

$ sudo ip -6 addr add 2001:728:1808:1::21/126 dev eth1

as a counter example in the real world operation against the /64
requirement of rfc4291bis:

   [...]  However, the Interface ID of
   all unicast addresses, except those that start with the binary value
   000, is required to be 64 bits long.
(this logically means the subnet prefix is required to be 64 bits long).

Actually, with the distinction between on-link and subnet prefixes,
these can coexist.  The above ip command is actually a short cut of
the following:
- configure a 128-bit IPv6 address (whose IID is 64 bits long)
- configure a /128 on-link prefix (that happens to cover the
  configured address) for that link

In my own draft (draft-jinmei-6man-prefix-clarify-00) I explained it's
already completely valid within the spec of ND and SLAAC: we could
advertise a /126 PIO with L=1, and it doesn't violate the IID
requirement of rfc4291bis (as it's an on-link prefix).  And, we could
have the host configure an IPv6 address that happens to match the /126
prefix via DHCPv6.  The end result is exactly the same as above.

"Architecturally," the configured address is still considered to have
a 64-bit IID, '0:0:0:21', but in practice it shouldn't matter for
operators - the host do not consider addresses to be on-link (and so
not perform ND, for example) unless the address matches the 126-bit
on-link prefix.  After all, that's what the operator using /126 wants,
right?

In the case of manual configuration like the above example of ip
command, it may be still moot as there's no protocol specification
about manually configuring on-link prefixes (and standard protocol
doesn't talk much about manual address configuration).  But I believe
the concept for the ND and SLAAC can be quite reasonably extended to
such cases.

If we can agree on this interpretation, I guess it's easy to resolve
the rfc4291bis row.  Operators who like non /64 prefixes won't have to
be too sensitive about the length of IID, since it doesn't matter for
them in practice.  We might even keep the current text of rfc4291bis,
but it might help if it could also mention the distinction of
(generalized sense of) on-link and subnet prefixes.

One thing I'm not sure is whether this is acceptable to those who want
to keep the hardcoded 64-bit IID length.  If the important part of
this spec for those people is to prevent operators from using
narrower on-link prefixes such as /126 when the IID length is 64 bits
long, then this proposed resolution won't work for them.  If that was
the case, please just ignore this message - I just wanted to help find
a way forward, not intending to add more fuel to the heated debate.

--
JINMEI, Tatuya


From nobody Tue Mar 28 09:26:25 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E2B129686; Tue, 28 Mar 2017 09:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3GVFnW2l0w8H; Tue, 28 Mar 2017 09:26:19 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF8612971E; Tue, 28 Mar 2017 09:26:12 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id e75so61717426itd.1; Tue, 28 Mar 2017 09:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SZk/0GfUvfQUyTmUW1tO8QTQYHF/BhxNFqShPFA25l4=; b=sy2+D6yyPQEwGlrCK0Dfn8VzcCYzf9H9Io9JMTWHl0uqANihTIHacuQB+nntYNiAD7 NMS6sxZSp1NeZBJGp9Q4d3NBkqWh78dd/uU8iDAJq92feWB99HGQaZFvajiDuZlI3DxT E1rEaYxqcxuhg9rJepX/wy3vhAlZqNgDfhxtWU6EhZqpwfUwghE7iRlZZSEDZJSQeTEc bGbXkGCHvfdnlLKs/O5eQ/v7fqXxhCxtMveibtRsmpa/tnHNtvth5irDLvKnaxygh7WQ SgtVtRW4TdOfSHQQocXqAJYLBGkrvDIhgRcGdPA+plgPx3nziQ1/r08/6PuIkCW334Wf CQDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=SZk/0GfUvfQUyTmUW1tO8QTQYHF/BhxNFqShPFA25l4=; b=rM8siMWXAhr3BjxUTQgi1HzQ6kSXPp8issmCjkCkkD16WEZOMXyMBgLtP2/ztigXTk jyCC9JTIE4aQoayun6YkVBEJtc1uZxr6Q/x7wulDA4sd5ciKbBKVqWTTG9uJQKIaZxOh w9lE8/F7bCKQNvJWBRZ6kcsRpLTrH9uxyaa8lnH2htXOs+VFGtpXdbY1ODBco8sqinZp b34ADiG/dDiy0xuXH7cxre4G7S6KsoOWECBJUC0KxKlyb9nen7mxgmVAx3mvK/ZwizzS ltdZ5aORcNQlC9/BKCw0H9QSb99CMy2RlfH8Lva/Dey+z/1K3FQZzIbHSzslbH5Zn05/ 9ijg==
X-Gm-Message-State: AFeK/H3XwL4twPg+Ps3JkE0I6BNvUxvBwZB6Z2sqEX+/awdQZuZK6xLdEjCpmwfBvsELCQ==
X-Received: by 10.36.70.210 with SMTP id j201mr7969318itb.109.1490718371004; Tue, 28 Mar 2017 09:26:11 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z204sm2127905ioe.53.2017.03.28.09.26.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 09:26:10 -0700 (PDT)
Subject: Anotegr issue in rfc4291bis [was draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation]
To: "Mudric, Dusan (Dusan)" , "Lubashev, Igor" , Fred Baker , Alexandre Petrescu 
References:  <5265b781-ab49-18ff-55fc-1647b6192a1c@gmail.com>  <51c4ba37-59e8-dd56-1d2d-d549302a2d0d@gmail.com> <20170328062926.GP2367@Space.Net> <229cce4e-a392-63b1-7544-ab79063c5b75@gmail.com> <6BE8068C-4FC9-4EBE-B27D-84C592E192A5@gmail.com> <5b1a95f6d5c345b8ae9b435a85d2c30a@usma1ex-dag1mb5.msg.corp.akamai.com> <9142206A0C5BF24CB22755C8EC422E4585A274C6@AZ-US1EXMB03.global.avaya.com>
Cc: 6man , draft-ietf-6man-rfc4291bis.all@ietf.org
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <16943362-8331-7311-9084-4f33c40f46ba@gmail.com>
Date: Wed, 29 Mar 2017 05:26:13 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E4585A274C6@AZ-US1EXMB03.global.avaya.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 16:26:23 -0000

*Change of subject and mailing list*

On 29/03/2017 03:14, Mudric, Dusan (Dusan) wrote:
> RFC 4291 does not well define the address syntax. It combines the prefix and the address syntax into one:
> 
> Section 2.3
> "      the node address      2001:0DB8:0:CD30:123:4567:89AB:CDEF
>       and its subnet number 2001:0DB8:0:CD30::/60
> 
>       can be abbreviated as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60"
> 
> This is not a good example. The prefix-length of 60 does not mean the four bits after 'CD3' must be zero.

No, of course not, the example would be equally valid if it showed
 2001:0db8:0:cd3f:123:4567:89ab:cdef
 2001:0db8:0:cd30::/60
 2001:0db8:0:cd3f:123:4567:89ab:cdef/60

...
> The prefix-length should not be used in the address syntax (e.g. use 2001:0DB8:0:CD30:123:4567:89AB:CDEF address and not 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60

If there is a / it is a prefix, I agree. I think the text is misleading for
that reason. This could be fixed in 4291bis. *The simplest way is to delete
the text starting
"When writing both a node address and a prefix of that node address"
through the end of the section*.

(As far as I can see, if we want to express as a single item both an
address and its applicable subnet prefix, we need new notation, e.g.
2001:db8:0:cd3f:123:4567:89ab:cdef//60.)

> The prefix syntax must define that all bits outside the prefix-length must be set to zero. So, fe90::/10, fe81::/10 are not the valid LL prefixes.

They are completely equal, because /10 says "only look at the first 10 bits".
It might be confusing, but it's not wrong IMHO.

Maybe we need RFC5952bis, because RFC5952 does not discuss prefix notation in detail.

    Brian

> 
> With these changes, do we still need the address mask?
> 
> Dusan
> 
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lubashev, Igor
> Sent: Tuesday, March 28, 2017 9:25 AM
> To: Fred Baker; Alexandre Petrescu
> Cc: v6ops list
> Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation
> 
> The way I put it in the draft:
> 
> '[Sec 1.1] Depending on the context, netmask and prefix length notations can specify either a "group of addresses" or "a group of addresses and a specific address within that group". ...
> 
> [Sec 4.1] To be a valid definition for just a group of addresses, the address part MUST NOT have any bits outside of the mask set."' 
> 
> So it is all about the context.  I.e. the output of "ip addr" vs "ip route" on Linux.
> 
> - Igor
> 
> -----Original Message-----
> From: Fred Baker [mailto:fredbaker.ietf@gmail.com] 
> Sent: Tuesday, March 28, 2017 7:56 AM
> To: Alexandre Petrescu 
> Cc: v6ops list 
> Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation
> 
> 
>> On Mar 28, 2017, at 7:49 AM, Alexandre Petrescu  wrote:
>>
>> Is there some mandate to mandate that the host bits are 0 when we talk about the subnet mask?
> 
> When we're talking about subnet masks (or lengths), we aren't talking about addresses. We identify an address (which might be ::) and give it a length, but that is simply for notational convenience - if an address is important, we don't have to specify it separately. The "prefix" part would be the bitwise AND of the address and the mask or length.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PltSWhkoDeatKmZk5zfNYvyTAwOGGXs1QxoG61Typ2k&s=9uH3IB_DbRwssRzuN8MTq_GsOzak8m7UmOaFkoX1Gro&e= 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PltSWhkoDeatKmZk5zfNYvyTAwOGGXs1QxoG61Typ2k&s=9uH3IB_DbRwssRzuN8MTq_GsOzak8m7UmOaFkoX1Gro&e= 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Tue Mar 28 09:29:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA44126C26 for ; Tue, 28 Mar 2017 09:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 OyE-mQtM8uPy for ; Tue, 28 Mar 2017 09:29:28 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC1612951E for <6man@ietf.org>; Tue, 28 Mar 2017 09:29:26 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id v76so57199722ywg.0 for <6man@ietf.org>; Tue, 28 Mar 2017 09:29:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rYUDlZ1orYDvne9h9pmwUQ6ho7RtqSs0fhYrG1G84a4=; b=QpAUJXwed/B6Iv4pgZAE2K06/gbDwlpaEC11ooAeI3E5SiWBpGFvlcL+jfkleLar+d C/26IhfrzrLT7pmJA+2+Uto7ZvYtQ7cfAmA3ixhmKvtVfSKnJ6Yh3acYBnVcUJYiMGcH zR7fZqO1i9bAcbXAWgrF989EwKMoH4gjjY6vhzt/v6uKKePvuKvBqcpoLSVjqPSDxYgG ev3wemRtE87iBxcOsoJlkoJ3Rpm9Y/oN8YFMmYi9HioCD9CiIk49kEwEQV1ilo35Lpln rl8bSK/js5oqTlnCDpeHkKHuyZGBZJ28U9WrkJKpAk+mYo6MZq+/ja5rJq/hqsvuC6bU X73w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rYUDlZ1orYDvne9h9pmwUQ6ho7RtqSs0fhYrG1G84a4=; b=Lh0H8qzspZe8hjaSl/vnSubV44GS2ysOqeMC1DAl9o0UK7bXIEepyO70NyzD9qizve Qj/VWeJxBLmqgK5E37z2hmZvEKckHthwCZ59pjZZ4c8hAHhqVt0rRnOhGEM8Lw5MggP+ b3F/L2HPThLUMlah2+s+FcoKK5o2OCDxBMSSGXcmJZIK3/lcDagun5msqNeCnzakQglr QEVe4Fe3A+scIIKG1gCS/Tjw6JGQgX2h7hbuUynDIiMlRP9hQyflt0QYmF6o0gzwOqWs XkPR4PzPSGKPKPeaxFAAdRNDpVtsKqRtMrdkOWy1gRlXIJ6r3O7prg/xwnlpfonTLR74 mP7g==
X-Gm-Message-State: AFeK/H06AlA54z7zWShHeVi+55ipLtocEv3sHKxNtw5x/43+GUklutNpp+P27+fFGv7fbYsCkzLlDX9St+7PT9YP
X-Received: by 10.129.183.18 with SMTP id v18mr20721423ywh.217.1490718565087;  Tue, 28 Mar 2017 09:29:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.50.7 with HTTP; Tue, 28 Mar 2017 09:29:04 -0700 (PDT)
In-Reply-To: 
References: 
From: Erik Kline 
Date: Tue, 28 Mar 2017 09:29:04 -0700
Message-ID: 
Subject: Re: distinction between on-link and subnet prefix for rfc4291bis
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Cc: "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1bddf28edc32054bccf66e"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 16:29:30 -0000

--94eb2c1bddf28edc32054bccf66e
Content-Type: multipart/alternative; boundary=94eb2c1bddf288c3d5054bccf6e5

--94eb2c1bddf288c3d5054bccf6e5
Content-Type: text/plain; charset=UTF-8

>
> If we can agree on this interpretation, I guess it's easy to resolve
> the rfc4291bis row.  Operators who like non /64 prefixes won't have to
> be too sensitive about the length of IID, since it doesn't matter for
> them in practice.  We might even keep the current text of rfc4291bis,
> but it might help if it could also mention the distinction of
> (generalized sense of) on-link and subnet prefixes.
>

"it doesn't matter for them in practice": exactly.

I really do not think there was ever any real problem here.  Just (a)
misinterpretations/miunderstandings and (b) people who want to do SLAAC on
/65s, /80s, and so on.

--94eb2c1bddf288c3d5054bccf6e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    If we can agree on this interpretation, I guess =
it's easy to resolve
    
the rfc4291bis row.=C2=A0 Operators who like non /64 prefixes won't hav=
e to
    
be too sensitive about the length of IID, since it doesn't matter for
them in practice.=C2=A0 We might even keep the current text of rfc4291bis,<=
br>
but it might help if it could also mention the distinction of
    
(generalized sense of) on-link and subnet prefixes.
    "it doesn't matter for them in practice": exactl=
y.

    I really do not think there was ever any real p=
roblem here.=C2=A0 Just (a) misinterpretations/miunderstandings and (b) peo=
ple who want to do SLAAC on /65s, /80s, and so on.
    

--94eb2c1bddf288c3d5054bccf6e5--

--94eb2c1bddf28edc32054bccf66e
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy
MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L
KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N
LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7
oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8
kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm
MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo
dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud
DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg
PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i
YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh
bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX
iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S
toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2
/5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c
UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw
jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgfSKY7IrPN70JgYiVKDQZSaSNS9l5Lw5m
711TOD95M/cwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzI4
MTYyOTI1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAAtmfPt2/N+IvrMQ/ZJp8EvP9IRnl/vzIH0ldOAzaiP8TV3rw0O6
4iuxY3DTAizCjE6wC3wNcSsVuJga3kgi7WUYZh3nkPkvnUmhVv1Aa16AwMiIMUlZSgMJ7JI5yV9K
4aAriP6vhWbrqQ51AnxTe3uThR1pAx2xCkcKWOAKYUh7dG1zc0Yw1bzTGF3n2dHyElPhLO2ngz0k
68gG/SG8IpqaiV549HUz5+Io1sgbEc/X7kUeOz3hGE8/e6bbhafgjam7/CVicdCtf5neT1025b+X
Gm1cyVZ83jJQjdyc0ZuvNpETJZSGINIwnMKGBlWoztvJAzW8GpVWAp5kkt30e24=
--94eb2c1bddf28edc32054bccf66e--


From nobody Tue Mar 28 09:52:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36701129449 for ; Tue, 28 Mar 2017 09:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
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 CjIVDpe-oW_m for ; Tue, 28 Mar 2017 09:52:39 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D633812944B for <6man@ietf.org>; Tue, 28 Mar 2017 09:52:38 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id y18so28446593itc.1 for <6man@ietf.org>; Tue, 28 Mar 2017 09:52:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=VgUIwUG+5PX/zJgQfD6sOxXPNImtKU8yVMckuaqdCng=; b=RX3Ho9wcUCohB4/gCkVSsZANLMOz1Nv5sAjWVStonHh5G0wgca8UB/nexkYgEu9XQv VVjJe1A44Zf3/O7rA6VJe/WMMyJXomB82c12R/5ZLi55GiMRs6JVMzgou+OEEPYdzR08 k2Q1DncRJYWtaWn6/4wR4Aqer/nlyMTK4O/I9EHefvfxcq27Y1hauLyIkzstP7Izt/4+ Wj/9Z2X83BmOsACLuFSXKb7GPtxTO4l8ImsgBoKLK0hfaHZeAcpYeCuqaBCR/Jv712a0 W8DFDhmY0Ji/YP7bl1YnQzHxRYZFmlqHvI+o76hSRM4gu7oimTk59ugevL8BNf1LFotf N2uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VgUIwUG+5PX/zJgQfD6sOxXPNImtKU8yVMckuaqdCng=; b=SWkjf+wDvNyynDQu3O8UX8zlpvUDtgyMFfXDy3JddUKYtpcqwqWDtgZqlBGLOy8Ldm S1GeHHOllHhHYkXWpCyVFvoSJJ0aKVMXIYf3+SBdx6h9YgJYfxkyIxOtNeAuRh+jN6RS HFUIjEnOLuc9s19pf20bpIeNbDJTlOLTRA693lOyLPmWToM4ph156BxplOvzKTMzU8BQ 9BOAk22YbjxlWVwPRwFooWktBBeuMoZ0+Kt9eLNjwCes2dbLxOGChtzzLXO2KDPdUAS6 qrn/BBSJd1NgSob1nh2AsCmoHA1sN7PStKPyzyzAR11zXqZtzLkvVj1pTCQxBVoEhFtH BpJQ==
X-Gm-Message-State: AFeK/H0GAdG4QMpr0JvDpxRnAEw551X5ClTXVvugyTaF0aHuSPFeoirG0oa32Z4TBavDRg==
X-Received: by 10.36.236.130 with SMTP id g124mr299093ith.32.1490719958064; Tue, 28 Mar 2017 09:52:38 -0700 (PDT)
Received: from localhost (dhcp-919f.meeting.ietf.org. [31.133.145.159]) by smtp.gmail.com with ESMTPSA id r85sm1762570itc.13.2017.03.28.09.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 09:52:36 -0700 (PDT)
Date: Tue, 28 Mar 2017 11:52:35 -0500
From: Job Snijders 
To: Erik Kline 
Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= , "6man@ietf.org" <6man@ietf.org>
Subject: Re: distinction between on-link and subnet prefix for rfc4291bis
Message-ID: <20170328165235.m5hv664qulnpbwbv@Vurt.local>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 16:52:41 -0000

On Tue, Mar 28, 2017 at 09:29:04AM -0700, Erik Kline wrote:
> > If we can agree on this interpretation, I guess it's easy to resolve
> > the rfc4291bis row.  Operators who like non /64 prefixes won't have
> > to be too sensitive about the length of IID, since it doesn't matter
> > for them in practice.  We might even keep the current text of
> > rfc4291bis, but it might help if it could also mention the
> > distinction of (generalized sense of) on-link and subnet prefixes.
> 
> "it doesn't matter for them in practice": exactly.
> 
> I really do not think there was ever any real problem here.  Just (a)
> misinterpretations/miunderstandings and (b) people who want to do
> SLAAC on /65s, /80s, and so on.

I think (a) is a problem that needs to be addressed.

Kind regards,

Job


From nobody Tue Mar 28 09:57:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948E8129405 for ; Tue, 28 Mar 2017 09:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 VRQx4pPkRGDU for ; Tue, 28 Mar 2017 09:57:47 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E75F12944B for ; Tue, 28 Mar 2017 09:57:47 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id s68so95566754vke.3 for ; Tue, 28 Mar 2017 09:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=kxsN8dqBBzJJ1onOmk+rrMr7MP3gn05DP1KJ4tW8p/Q=; b=Tmr2IhMGoXjs05ihPeGY6YkpVmHg6bBmHxyojFyrChhHxyZm1h8N55fZencQyEvpVg d4+nhBo5//OZMq0iXQtF/d5K6hoYxCqc2wpT3uttZ8uG59eMlBhuqs61EYLqFs8s6770 7nHlIM6utT+kik8wy2N4NhcqKOxDWPbJePuERnFQbo6JEp5FT/lreADtHjhFw44xekDo LvsS+sgew9RbzPKvc46KsumPSjeiBQMFHS58/G0cWXOoI/XQIBcfiQoI2bwMjcH+PnmT mK3ihzX00YDnpkni9r9n0NhxArJFY9NMtRm0yiLPY8OGE+CcGAGjEUZz2Elj6ZLJOWFq Ge2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kxsN8dqBBzJJ1onOmk+rrMr7MP3gn05DP1KJ4tW8p/Q=; b=Fyzu/LyDP4dZOmthpbgmGAeHbmbvnPTEA3Z1x+nCiwn7AkV2xUl+FyBu3/NrN5Ulwd /loY9wcQiJ6EAnHTtxZ+5wKQZPJzBWjME+OGYO+twXe+PLSH08q0l3EVR0a4ky4R1QfO Kt4LRRum+EMEvbxoiDAKneSQ6AVt+pj7+9F8F0FuBZhDCzTVYJJ3ndJ3ZfMzqFKyOWKC g1C7w1TJ9rMMsPWHpWNxTNripZhIWck/VJ/Gl5hRU9IbbDxXrAzGxtWZZmhW1kfZbah7 UQzPRFz4bXJxW8g8K3VBMH4iQA0ItjU0OTehpWaEbreQ15iByD9ei2beAOltHIhlYmt6 li0A==
X-Gm-Message-State: AFeK/H3SqISBdSFGVW25kDMNqbpTL18K7aaAUmfpSsZoRtDjjkCZd/u326cZu0Sg2GcPALuHBrGfWAOmZd9IOQ==
X-Received: by 10.31.92.20 with SMTP id q20mr10821925vkb.146.1490720266221; Tue, 28 Mar 2017 09:57:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.3.131 with HTTP; Tue, 28 Mar 2017 09:57:45 -0700 (PDT)
From: Alexandre Petrescu 
Date: Tue, 28 Mar 2017 11:57:45 -0500
Message-ID: 
Subject: Comments on PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01
To: IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary=001a114e1d94ed8215054bcd5b48
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 16:57:50 -0000

--001a114e1d94ed8215054bcd5b48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In addition to asking how is this draft helping with DHCPv6 Prefix
Delegation,

I suggest addition of the following references.

Where draft-pioxfolks-6man-pio-exclusive-bit-01 says:
>    There are several initiatives that propose network side practices
>    that provide customer isolation, enhanced operational scalability,
>    power efficiency, security and other benefits in IPv6 network
>    deployments.  Some of these involve isolating a host (or RA accepting
>    client node) so that the host is the only node to receive a specific
>    prefix, including
>
>    o  DHCPv6 Prefix Delegation to hosts (       draft-templin-v6ops-pdhost>), and
>
>    o  advertising a unique prefix per host via unique RAs.
>       (       per-host>).

it makes sense to add:

    o  Prefix Delegation extensions to ND protocol have been introduced
       in ,  and , and
       probably earlier.

Alex

Le 04/03/2017 =C3=A0 06:31, Alexandre Petrescu a =C3=A9crit :
> I do not oppose a slot presenting PIO-X if time allows.
>
> However, as I understand it, PIO-X has a single goal - that to
> accomodate 64share.
>
> I wonder whether PIO-X could work with DHCPv6-PD?  Would PIO-X help
> DHCPv6-PD deployment?
>
> This is what I am going to ask at the mic.
>
> Alex
>
>
>
> Le 01/03/2017 =C3=A0 11:27, Erik Kline a =C3=A9crit :
>> Ole,
>>
>> It's on me to get a -02 of PIO-X written and uploaded.  Might it be
>> possible to get 5 minutes on that?
>>
>> -ek
>>
>> On 27 February 2017 at 06:16, > > wrote:
>>
>>     The 6MAN chairs are planning the meeting in Chicago at IETF98.
>>
>>     If you have a draft you would like to discuss, please send your
>>     request for agenda time to the 6man chairs.   Please include in the
>>     request, the title of the presentation, file name of the draft, the
>>     speaker's name (and email), and how much time you would like.
>>
>>     We will prioritise drafts that are working group items and drafts
>>     that have been actively discussed on the list.
>>
>>     We expect at least half of each talk=E2=80=99s presentation time to =
be used
>>     for open discussion,
>>     please plan your presentation accordingly.
>>
>>     New drafts not discussed on the mailing list prior to the meeting,
>>     or drafts that do not appear to have support from the working group
>>     are unlikely to get time at the meeting.
>>
>>     Please have agenda items to us by 2017-03-15.
>>
>>     Regards,
>>
>>     Bob & Ole
>>
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     ipv6@ietf.org 
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     
>>     --------------------------------------------------------------------
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--001a114e1d94ed8215054bcd5b48
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    In addition to asking h=
ow is this draft helping with DHCPv6 Prefix Delegation,

    I suggest ad=
dition of the following references.

    Where draft-pioxfolks-6man-pio-e=
xclusive-bit-01 says:
    >=C2=A0=C2=A0=C2=A0 There are several initiativ=
es that propose network side practices
    >=C2=A0=C2=A0=C2=A0 that provi=
de customer isolation, enhanced operational scalability,
    >=C2=A0=C2=
=A0=C2=A0 power efficiency, security and other benefits in IPv6 network
    =
>=C2=A0=C2=A0=C2=A0 deployments.=C2=A0 Some of these involve isolating a=
 host (or RA accepting
    >=C2=A0=C2=A0=C2=A0 client node) so that the h=
ost is the only node to receive a specific
    >=C2=A0=C2=A0=C2=A0 prefix=
, including
    > 
    >=C2=A0=C2=A0=C2=A0 o=C2=A0 DHCPv6 Prefix Delega=
tion to hosts (<https://tools.i=
etf.org/html/
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-templin=
-v6ops-pdhost>), and
    > 
    >=C2=A0=C2=A0=C2=A0 o=C2=A0 advertis=
ing a unique prefix per host via unique RAs.
    >=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 (<https://tools.ietf.org/html/draft-ietf-v6ops-unique-=
ipv6-prefix-
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 per-host>).=


    it makes sense to add:

    =C2=A0=C2=A0=C2=A0 o=C2=A0 Prefix Del=
egation extensions to ND protocol have been introduced 
    =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 in <draft-kaiser-nd-pd-02>, <draft-lutchann-=
ipv6-delegate-
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 option-00> and &l=
t;draft-haberman-ipngwg-auto-prefix-02>, and 
    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 probably earlier.

    Alex

    Le 04/03/2017 =C3=A0 0=
6:31, Alexandre Petrescu a =C3=A9crit :
    > I do not oppose a slot pres=
enting PIO-X if time allows.
    > 
    > However, as I understand it, =
PIO-X has a single goal - that to
    > accomodate 64share.
    > 
    &=
gt; I wonder whether PIO-X could work with DHCPv6-PD?=C2=A0 Would PIO-X hel=
p
    > DHCPv6-PD deployment?
    > 
    > This is what I am going to=
 ask at the mic.
    > 
    > Alex
    > 
    > 
    > 
    > L=
e 01/03/2017 =C3=A0 11:27, Erik Kline a =C3=A9crit :
    >> Ole,
    &g=
t;>
    >> It's on me to get a -02 of PIO-X written and uploade=
d.=C2=A0 Might it be
    >> possible to get 5 minutes on that?
    >=
>
    >> -ek
    >>
    >> On 27 February 2017 at 06:16, =
<otroan@employees.org
    >=
;> <mailto:otroan@employees.o=
rg>> wrote:
    >>
    >>=C2=A0=C2=A0=C2=A0=C2=A0 The 6=
MAN chairs are planning the meeting in Chicago at IETF98.
    >>
    &g=
t;>=C2=A0=C2=A0=C2=A0=C2=A0 If you have a draft you would like to discus=
s, please send your
    >>=C2=A0=C2=A0=C2=A0=C2=A0 request for agenda =
time to the 6man chairs.=C2=A0=C2=A0 Please include in the
    >>=C2=
=A0=C2=A0=C2=A0=C2=A0 request, the title of the presentation, file name of =
the draft, the
    >>=C2=A0=C2=A0=C2=A0=C2=A0 speaker's name (and =
email), and how much time you would like.
    >>
    >>=C2=A0=C2=
=A0=C2=A0=C2=A0 We will prioritise drafts that are working group items and =
drafts
    >>=C2=A0=C2=A0=C2=A0=C2=A0 that have been actively discusse=
d on the list.
    >>
    >>=C2=A0=C2=A0=C2=A0=C2=A0 We expect at=
 least half of each talk=E2=80=99s presentation time to be used
    >>=
=C2=A0=C2=A0=C2=A0=C2=A0 for open discussion,
    >>=C2=A0=C2=A0=C2=A0=
=C2=A0 please plan your presentation accordingly.
    >>
    >>=
=C2=A0=C2=A0=C2=A0=C2=A0 New drafts not discussed on the mailing list prior=
 to the meeting,
    >>=C2=A0=C2=A0=C2=A0=C2=A0 or drafts that do not =
appear to have support from the working group
    >>=C2=A0=C2=A0=C2=A0=
=C2=A0 are unlikely to get time at the meeting.
    >>
    >>=C2=
=A0=C2=A0=C2=A0=C2=A0 Please have agenda items to us by 2017-03-15.
    >=
>
    >>=C2=A0=C2=A0=C2=A0=C2=A0 Regards,
    >>
    >>=
=C2=A0=C2=A0=C2=A0=C2=A0 Bob & Ole
    >>
    >>=C2=A0=C2=A0=
=C2=A0=C2=A0 --------------------------------------------------------------=
------
    >>=C2=A0=C2=A0=C2=A0=C2=A0 IETF IPv6 working group mailing =
list
    >>=C2=A0=C2=A0=C2=A0=C2=A0 i=
pv6@ietf.org <mailto:ipv6@ietf.org<=
/a>>
    >>=C2=A0=C2=A0=C2=A0=C2=A0 Administrative Requests:     https://www.ietf.org/mailm=
an/listinfo/ipv6
    >>=C2=A0=C2=A0=C2=A0=C2=A0 <https://www.ietf.org/mailman/listi=
nfo/ipv6>
    >>=C2=A0=C2=A0=C2=A0=C2=A0 ----------------------=
----------------------------------------------
    >>
    >>
    &=
gt;>
    >>
    >> -------------------------------------------=
-------------------------
    >> IETF IPv6 working group mailing list<=
br>>> ipv6@ietf.org
    >> =
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    >> -----------=
---------------------------------------------------------
    >>
    &g=
t; 
    > ---------------------------------------------------------------=
-----
    > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailma=
n/listinfo/ipv6
    > -----------------------------------------------=
---------------------
    > 

    

--001a114e1d94ed8215054bcd5b48--


From nobody Tue Mar 28 10:20:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072C712944B for ; Tue, 28 Mar 2017 10:20:40 -0700 (PDT)
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 autolearn_force=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 ttg5VJ2gxUpP for ; Tue, 28 Mar 2017 10:20:36 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 17A62129441 for ; Tue, 28 Mar 2017 10:20:36 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1csunK-0000CoC; Tue, 28 Mar 2017 19:20:34 +0200
Message-Id: 
To: ipv6@ietf.org
Subject: Re: comments on draft-pioxfolks-6man-pio-exclusive-bit-01 
From: Philip Homburg 
Sender: pch-bF054DD66@u-1.phicoh.com
In-reply-to: Your message of "Tue, 28 Mar 2017 08:41:35 -0700 ."  
Date: Tue, 28 Mar 2017 19:20:33 +0200
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 17:20:40 -0000

In the context of DHCPv6 and RA, it is often brought up that there 
should (ideally) be only one way of doing something.

Given how much this looks like DHCPv6 PD, maybe this draft should have
a clearer section why this does not duplicate DHCPv6 PD.

In Section 1, if I mentally replace 'X bit' with DHCPv6 PD then just about
everything there is still true.

The draft doesn't seem to even try to describe why DHCPv6 PD doesn't work.



From nobody Tue Mar 28 11:09:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EC912778D for ; Tue, 28 Mar 2017 11:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 1EY7BUjL_8wc for ; Tue, 28 Mar 2017 11:09:11 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A8D12944B for <6man@ietf.org>; Tue, 28 Mar 2017 11:09:10 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id p77so59092165ywg.1 for <6man@ietf.org>; Tue, 28 Mar 2017 11:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=sMKBoKJYlrMIzMjwapgdA0iOGnQIR1NA+xBJumOmtAA=; b=Z8gTxlNuee0IbdEmNVoahsPvAImxm7V/0KaVN0RuVqv8FJGX7T5Qct/E/XDsquOMPn W/HAfcs7wdhXm59dDT6Sx7al+m1/8lgVSaeA2zKIDoKvCqGJUR12AUceChSlz24UBl+V M+rCjQf2wwW1qnC72M763eZXzSBwsczHA6NriadjcgtWeVfQGrhXEKAwyQfNN5KQKTzY dWj5Z695hyb2x1pTt8Bgujkmo/9vdzG3H83PLDQZEnZv8VwiuVY1N058hnarNmqtsmvx EF7scr0uzidbmZowFLEPi62BzwLyIeKcoQ5dY2WlI6FBAgWlv96dYv53/XAkfvU7RTR/ mBGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=sMKBoKJYlrMIzMjwapgdA0iOGnQIR1NA+xBJumOmtAA=; b=eoWL0EFA3TNlW9YEvjOQnrOC3gh8aRr886OMSLP7qwncVBZhf7/+mcWoONoLAKpa17 /dH2B2bnQkrY2+QDBeeqOJPVHHKcCEKeQx+Eq2nnq3IdccCWcayN/MFXSGps2KwrtG5G 9joScisJuAuESn/T6rEISmiGXya+ubQ0WKxSl3rT9qUrcLJMwHBWuB7zBYFRBOLvbpHO 6KhtHXnDrWrSPtI3r+J/aNJ1NDbq1Rgt9lTDOt3T+lpB7hMBaeZH+4rZgfEoxtZ6it+p YL027SrIcE/mwpl5+4+Id04VyqfhIbab7m7edLuvKN2m3B5QQnXnqasvH3FS3VKoA8Ew xhKw==
X-Gm-Message-State: AFeK/H3xqlymdZhjEP2+DlZo5sbBfl3PF20rXCr+noyWOtkO/l3q6EeODTdp2wFjHBlr0bgs5MF4X6FoJ9OmpGPG
X-Received: by 10.37.69.5 with SMTP id s5mr20339648yba.184.1490724549630; Tue, 28 Mar 2017 11:09:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.50.7 with HTTP; Tue, 28 Mar 2017 11:08:49 -0700 (PDT)
In-Reply-To: <149072444449.1156.17120983379046018035.idtracker@ietfa.amsl.com>
References: <149072444449.1156.17120983379046018035.idtracker@ietfa.amsl.com>
From: Erik Kline 
Date: Tue, 28 Mar 2017 11:08:49 -0700
Message-ID: 
Subject: Fwd: New Version Notification for draft-pioxfolks-6man-pio-exclusive-bit-02.txt
To: 6man <6man@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1142326e442f89054bce5b0c"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 18:09:14 -0000

--001a1142326e442f89054bce5b0c
Content-Type: multipart/alternative; boundary=001a1142326e3d8bb3054bce5b39

--001a1142326e3d8bb3054bce5b39
Content-Type: text/plain; charset=UTF-8

I've posted a -02 in advance of Thursday morning.


---------- Forwarded message ----------
From: 
Date: 28 March 2017 at 11:07
Subject: New Version Notification for
draft-pioxfolks-6man-pio-exclusive-bit-02.txt
To: Erik Kline , Mikael Abrahamsson <
mikael.abrahamsson@t-systems.se>, Mikael Abrahamsson <
Mikael.Abrahamsson@t-systems.se>



A new version of I-D, draft-pioxfolks-6man-pio-exclusive-bit-02.txt
has been successfully submitted by Erik Kline and posted to the
IETF repository.

Name:           draft-pioxfolks-6man-pio-exclusive-bit
Revision:       02
Title:          IPv6 Router Advertisement Prefix Information Option
eXclusive Flag
Document date:  2017-03-27
Group:          Individual Submission
Pages:          15
URL:            https://www.ietf.org/internet-drafts/draft-pioxfolks-6man-
pio-exclusive-bit-02.txt
Status:         https://datatracker.ietf.org/doc/draft-pioxfolks-6man-pio-
exclusive-bit/
Htmlized:       https://tools.ietf.org/html/draft-pioxfolks-6man-pio-
exclusive-bit-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pioxfolks-6man-
pio-exclusive-bit-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-pioxfolks-6man-pio-
exclusive-bit-02

Abstract:
   This document defines a new control bit in the IPv6 RA PIO flags
   octet that indicates that the node receiving this RA is the exclusive
   receiver of all traffic destined to any address within that prefix.

   Termed the eXclusive flag (or "X flag"), nodes that recognize this
   can perform some optimizations to save time and traffic (e.g. disable
   ND and DAD for addresses within this prefix) and more immediately
   pursue the benefits of being provided multiple addresses (vis.
   [RFC7934] section 3).  Additionally, network infrastructure nodes
   (routers, switches) can benefit by minimizing the number of {link
   layer, IP} address pairs required to offer network connectivity (vis.
   [RFC7934] section 9.3).

   Use of the X flag is backward compatible with existing IPv6 standards
   compliant implementations.




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

--001a1142326e3d8bb3054bce5b39
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I've posted a -02 in advance of Thursday morning.=



    ---------- Forwarded me=
ssage ----------
    From:  <internet-drafts@ietf.or=
g>
    Date: 28 March 2017 at 11:07
    Subject: New Version No=
tification for draft-pioxfolks-6man-pio-exclusive-bit-02.txt
    To: Erik Kl=
ine <ek@google.com>, Mikael Abra=
hamsson <mikael.abrah=
amsson@t-systems.se>, Mikael Abrahamsson <Mikael.Abrahamsson@t-systems.se>

    =


    
A new version of I-D, draft-pioxfolks-6man-pio-exclusive-bit-02.txt
has been successfully submitted by Erik Kline and posted to the
    
IETF repository.
    

    
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-pioxfolks-6man-pio-exclusive-bit
    
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
    
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 Router Advertisement Prefix I=
nformation Option eXclusive Flag
    
Document date:=C2=A0 2017-03-27
    
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
    
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft=
-pioxfolks-6man-pio-exclusive-bit-02.txt
    
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-pioxfolks-6man-pio=
-exclusive-bit/
    
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusi=
ve-bit-02
    
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-pioxfolks-6=
man-pio-exclusive-bit-02
    
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-pioxf=
olks-6man-pio-exclusive-bit-02
    

    
Abstract:
    
=C2=A0 =C2=A0This document defines a new control bit in the IPv6 RA PIO fla=
gs
    
=C2=A0 =C2=A0octet that indicates that the node receiving this RA is the ex=
clusive
    
=C2=A0 =C2=A0receiver of all traffic destined to any address within that pr=
efix.
    

    
=C2=A0 =C2=A0Termed the eXclusive flag (or "X flag"), nodes that =
recognize this
    
=C2=A0 =C2=A0can perform some optimizations to save time and traffic (e.g. =
disable
    
=C2=A0 =C2=A0ND and DAD for addresses within this prefix) and more immediat=
ely
    
=C2=A0 =C2=A0pursue the benefits of being provided multiple addresses (vis.=

    
=C2=A0 =C2=A0[RFC7934] section 3).=C2=A0 Additionally, network infrastructu=
re nodes
    
=C2=A0 =C2=A0(routers, switches) can benefit by minimizing the number of {l=
ink
    
=C2=A0 =C2=A0layer, IP} address pairs required to offer network connectivit=
y (vis.
    
=C2=A0 =C2=A0[RFC7934] section 9.3).
    

    
=C2=A0 =C2=A0Use of the X flag is backward compatible with existing IPv6 st=
andards
    
=C2=A0 =C2=A0compliant implementations.
    

    

    

    

    
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
    

    


    

--001a1142326e3d8bb3054bce5b39--

--001a1142326e442f89054bce5b0c
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy
MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L
KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N
LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7
oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8
kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm
MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo
dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud
DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg
PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i
YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh
bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX
iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S
toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2
/5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c
UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw
jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg2yCpK65VJr5a3e7rf1Cb6NV8qJD/vTDX
D/j9f/lvzu0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzI4
MTgwOTEwWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAJsfr0hROnA9xBnWLu0wzxLQOzXf+Dl20KaUDTwWSMxtfAsihA09
HISz68NA7i5cB0ZY8agATyyfpbYTax+IPk384PltlYJG5micwsA+0SM9Azh8ok4ujXP4Ce9DK5AK
uZNrDa5yykUb0ekzUnVFi+0sXk5cH0baJwwXbWApx/eoogJQK58HMBiTjc1pWtX+rlrwQ9VFB+bB
VCJBbQb2Dz/uuD3QEgKsHfzYuODCKOCvaheY7DsPfv0NNmIfrdzowa8urxktOeItrKlwcxS9TVG0
0uNQvJw1keNasRkzS617edGDyTbdqkI/8Ke47uvz0kMpWthyJ+8XBojzy9tjE70=
--001a1142326e442f89054bce5b0c--


From nobody Tue Mar 28 11:10:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C519D129456 for ; Tue, 28 Mar 2017 11:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 H2VMAbnIWllT for ; Tue, 28 Mar 2017 11:10:29 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4F7129480 for ; Tue, 28 Mar 2017 11:10:29 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id d191so59251165ywe.2 for ; Tue, 28 Mar 2017 11:10:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wyL6jOLx9sbNxn5OTfTl+i0oYFlGYUu52G+6BiP135c=; b=n69wHGedcYScCtDEtlfgGun85NDyie/9gfo6k2/NXw4xV+7a088fF8aTlALLtFPSB4 gql7rxgmQVPSsFtGgf/Fqlp7GTT/2ntnUrMIn9bONhj85wMcrdnAXA+nQZWsxUpssEIK O5OFVUoqBfRZx9eSMTndS+s3YIsLZmE03Rm+b56h4Vsk82tqU0i8xQvEC0fYRbxI7eED WWCTm5z0CKicN/Kz10weIl1pI8AOB7gvAqi7iJpP/q9svvXxhLXG0Aq86/GbE6JcuCZV yx7iGG0i0ujJvlztVFE1Buh5/9JGxu1SfrSR7ZPDNCO2NBSMEE3pd60J9ThQiFvGXVxA Mj/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wyL6jOLx9sbNxn5OTfTl+i0oYFlGYUu52G+6BiP135c=; b=RpCwd9SuqOjp7AUSxJ41pBgRvKW9TA6/bUqLSdxhe3RlmdtWq7p27h/EMlgvf/yCIs upgjAOkMaju0OTjiKi7ipQp9W3haxwF7oDdHvYd38fkvYNvSuWreWJTidUhM0im65pAy xI36b+kdFae9EY3kW5WDBXolCO4VPeYdO8Lx1lUQAGj5rK2ovfDklxsY8DffnyQSni0w ecJ97UQyg9mXsWKlA8/dQmAimTFGwVvGK7WTZ3f5gcbrNHQlxaPyQYOuomGXe8Y2KF5l ZGDN5Sa2Vv7QNx9pqitl3zfxD7lcTYK7jPIndCPG1WMtEAKJiQpO2VlAZzWp7YsclgKz cXBg==
X-Gm-Message-State: AFeK/H1XJLiwKj5AyjUfXb+eO6qlCp4Lhxj7+M5SEw+CsR1pDpyzceBQeuqeYrHf95XWA6xAyzlwqWZa/B1njGq+
X-Received: by 10.13.242.198 with SMTP id b189mr21251269ywf.243.1490724628460;  Tue, 28 Mar 2017 11:10:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.50.7 with HTTP; Tue, 28 Mar 2017 11:10:08 -0700 (PDT)
In-Reply-To: 
References:  
From: Erik Kline 
Date: Tue, 28 Mar 2017 11:10:08 -0700
Message-ID: 
Subject: Re: comments on draft-pioxfolks-6man-pio-exclusive-bit-01
To: Philip Homburg 
Cc: IETF IPv6 Mailing List 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0356ecf7ab67054bce5f8a"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 18:10:32 -0000

--94eb2c0356ecf7ab67054bce5f8a
Content-Type: multipart/alternative; boundary=94eb2c0356ecf08347054bce5f0e

--94eb2c0356ecf08347054bce5f0e
Content-Type: text/plain; charset=UTF-8

This was a piece of feedback we received in Seoul.  I hadn't updated the
document until last night (just posted now).

I've added a small section describing some of the differences in semantics
with 3633.

On 28 March 2017 at 10:20, Philip Homburg 
wrote:

> In the context of DHCPv6 and RA, it is often brought up that there
> should (ideally) be only one way of doing something.
>
> Given how much this looks like DHCPv6 PD, maybe this draft should have
> a clearer section why this does not duplicate DHCPv6 PD.
>
> In Section 1, if I mentally replace 'X bit' with DHCPv6 PD then just about
> everything there is still true.
>
> The draft doesn't seem to even try to describe why DHCPv6 PD doesn't work.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--94eb2c0356ecf08347054bce5f0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    This was a piece of feedback we received in Seoul.=C2=A0 I=
 hadn't updated the document until last night (just posted now).
    I've added a small section describing some of the differen=
ces in semantics with 3633.

    On 28 March 2017 at 10:20, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
    In the context of DHCPv6 and RA, it is often brought up t=
hat there
    
should (ideally) be only one way of doing something.
    

    
Given how much this looks like DHCPv6 PD, maybe this draft should have
    
a clearer section why this does not duplicate DHCPv6 PD.
    

    
In Section 1, if I mentally replace 'X bit' with DHCPv6 PD then jus=
t about
    
everything there is still true.
    

    
The draft doesn't seem to even try to describe why DHCPv6 PD doesn'=
t work.
    

    

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


    

--94eb2c0356ecf08347054bce5f0e--

--94eb2c0356ecf7ab67054bce5f8a
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy
MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L
KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N
LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7
oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8
kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm
MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo
dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud
DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg
PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i
YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh
bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX
iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S
toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2
/5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c
UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw
jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgR+WuXGmJWqlWDpbakvslImYJCil5ZrJE
lNe7aJu3O4IwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzI4
MTgxMDI4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAA7NEUwscImFpQ82O7GjPO58yJ3dkkmn5HEomT9+qA5Zxv3u8Fd8
xGXv6UIaUS2bCxCy4CpzmEJqVwX4J2NZkZlnpp9IvUNT5BeiGP+xA9aNajtJXoKKs06UI1tsS569
PwTFCBlsrtuNq8jSYjE5h/fNHtTmx3Z3i7FbLA56ED60N4j3wwQk8gfKM5fsOKZ8GextzDeyCHcG
DPplJjo2UZ80MCw9iWAxfFgek+0KJ93IpKlIPIdDZJDeTSIHhqW0j9tstaHjBMbFAmuh7fmr6qhk
b2joXETigKd1DRBMwXIC/GNX1sXJ46jw5x1mpg1XN29hZ+GmQ8f8VDF4mDGF/Pc=
--94eb2c0356ecf7ab67054bce5f8a--


From nobody Tue Mar 28 11:16:07 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5671293F4; Tue, 28 Mar 2017 11:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ddDHQ-Ulocet; Tue, 28 Mar 2017 11:16:03 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624EF1294AB; Tue, 28 Mar 2017 11:16:03 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id e75so65319449itd.1; Tue, 28 Mar 2017 11:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=aKp5Ptr4XA8A3Pd4hJxyVvkyLm/I3SBCXhU+eJt4Uxo=; b=lmOKPW9LlEUiKM9lAYBc7qYQGhwKnywVLpLZ1c8PFUutC7GSLrMXU10vm62IrkVnHu GMJHgA5JsTSEJzMEcUKTXD+/S28nV17y8GZIDkjscOCaLxgify2eAqu1YMoCIEAQfnnZ 6IgzA/ZovSgNwCQNXHhk0QqYg1ePxP9clbRfZCEwk8Edz7dOTzir36jYl2qBQHE9nALJ kguVKwZr6htcZvxyBU+eo9AZ2MROmXTFWR+TU8eYVk3XE253/Lil2IcyyiNtYpxF4sNx C9BvpRvaVFVLyvFL1KMfJEhWgZGuGGC2HdB242gC+xX8L70i90FvKI2CI2wljUd7rHtW om+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=aKp5Ptr4XA8A3Pd4hJxyVvkyLm/I3SBCXhU+eJt4Uxo=; b=oLO1Sww/L1d9R+kxi2enJQYuFFVkVx+mnnjsA+JhCPPdkk4du8B7TGTDcTuVjX9KY2 Km2RvIgRZP2RnDL0ciNdXB/+AguOlrT7yPOSYxmqaKALXB36lK2DK9EifWOb7EwK1B9W KAeDiN6ROyMx+orsFC6xz3lxKWBvzAvuMhCs9MsjCSjbyq8L/eQv7HscDsMYVWPWNkwl HKaBQsyVtCYPe9+8TubJHIVyJr3QH5quzgn4cPtDjEargvAW65Mevq/qMRgzZ/l8mGEX o1gK0gyfftmj86RehxHW06hINfoheCgiwOeReJQzlxSJ7o5IsUQfED+wcO3aEc84G/o/ rKSw==
X-Gm-Message-State: AFeK/H0GiiASjwm9x15G18TFjhaVUdNBoAs3xoib3UbhZzeFQDRXFr+/P3C4YxoQNEbTKw==
X-Received: by 10.107.143.131 with SMTP id r125mr32377686iod.148.1490724961922;  Tue, 28 Mar 2017 11:16:01 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v136sm1883825ita.0.2017.03.28.11.16.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 11:16:01 -0700 (PDT)
Subject: Re: Anotegr issue in rfc4291bis [was draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation]
To: "Mudric, Dusan (Dusan)" , "Lubashev, Igor" , Fred Baker , Alexandre Petrescu 
References:  <5265b781-ab49-18ff-55fc-1647b6192a1c@gmail.com>  <51c4ba37-59e8-dd56-1d2d-d549302a2d0d@gmail.com> <20170328062926.GP2367@Space.Net> <229cce4e-a392-63b1-7544-ab79063c5b75@gmail.com> <6BE8068C-4FC9-4EBE-B27D-84C592E192A5@gmail.com> <5b1a95f6d5c345b8ae9b435a85d2c30a@usma1ex-dag1mb5.msg.corp.akamai.com> <9142206A0C5BF24CB22755C8EC422E4585A274C6@AZ-US1EXMB03.global.avaya.com> <16943362-8331-7311-9084-4f33c40f46ba@gmail.com>
Cc: 6man , draft-ietf-6man-rfc4291bis.all@ietf.org
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <03fd3c35-b191-4806-7d6a-d3f9379a4da9@gmail.com>
Date: Wed, 29 Mar 2017 07:16:04 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <16943362-8331-7311-9084-4f33c40f46ba@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 18:16:06 -0000

1. If you are puzzled about "Anotegr" it's a badly mangled "Another"

2. I just had a conversation about this issue with the editor of rfc4291bis.
The issue really is that
2001:0db8:0:cd30:123:4567:89ab:cdef/60
is invalid if intended as a prefix and should be expressed as
2001:0db8:0:cd30::/60
but it's valid if intended as an address qualified by the applicable prefix.

The problem is that the syntax doesn't distinguish the legal from
the illegal use, because it does not express the intended interpretation.
So the interpretation and validity is context-dependent.

Regards
   Brian

On 29/03/2017 05:26, Brian E Carpenter wrote:
> *Change of subject and mailing list*
> 
> On 29/03/2017 03:14, Mudric, Dusan (Dusan) wrote:
>> RFC 4291 does not well define the address syntax. It combines the prefix and the address syntax into one:
>>
>> Section 2.3
>> "      the node address      2001:0DB8:0:CD30:123:4567:89AB:CDEF
>>       and its subnet number 2001:0DB8:0:CD30::/60
>>
>>       can be abbreviated as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60"
>>
>> This is not a good example. The prefix-length of 60 does not mean the four bits after 'CD3' must be zero.
> 
> No, of course not, the example would be equally valid if it showed
>  2001:0db8:0:cd3f:123:4567:89ab:cdef
>  2001:0db8:0:cd30::/60
>  2001:0db8:0:cd3f:123:4567:89ab:cdef/60
> 
> ...
>> The prefix-length should not be used in the address syntax (e.g. use 2001:0DB8:0:CD30:123:4567:89AB:CDEF address and not 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60
> 
> If there is a / it is a prefix, I agree. I think the text is misleading for
> that reason. This could be fixed in 4291bis. *The simplest way is to delete
> the text starting
> "When writing both a node address and a prefix of that node address"
> through the end of the section*.
> 
> (As far as I can see, if we want to express as a single item both an
> address and its applicable subnet prefix, we need new notation, e.g.
> 2001:db8:0:cd3f:123:4567:89ab:cdef//60.)
> 
>> The prefix syntax must define that all bits outside the prefix-length must be set to zero. So, fe90::/10, fe81::/10 are not the valid LL prefixes.
> 
> They are completely equal, because /10 says "only look at the first 10 bits".
> It might be confusing, but it's not wrong IMHO.
> 
> Maybe we need RFC5952bis, because RFC5952 does not discuss prefix notation in detail.
> 
>     Brian
> 
>>
>> With these changes, do we still need the address mask?
>>
>> Dusan
>>
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lubashev, Igor
>> Sent: Tuesday, March 28, 2017 9:25 AM
>> To: Fred Baker; Alexandre Petrescu
>> Cc: v6ops list
>> Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation
>>
>> The way I put it in the draft:
>>
>> '[Sec 1.1] Depending on the context, netmask and prefix length notations can specify either a "group of addresses" or "a group of addresses and a specific address within that group". ...
>>
>> [Sec 4.1] To be a valid definition for just a group of addresses, the address part MUST NOT have any bits outside of the mask set."' 
>>
>> So it is all about the context.  I.e. the output of "ip addr" vs "ip route" on Linux.
>>
>> - Igor
>>
>> -----Original Message-----
>> From: Fred Baker [mailto:fredbaker.ietf@gmail.com] 
>> Sent: Tuesday, March 28, 2017 7:56 AM
>> To: Alexandre Petrescu 
>> Cc: v6ops list 
>> Subject: Re: [v6ops] draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation
>>
>>
>>> On Mar 28, 2017, at 7:49 AM, Alexandre Petrescu  wrote:
>>>
>>> Is there some mandate to mandate that the host bits are 0 when we talk about the subnet mask?
>>
>> When we're talking about subnet masks (or lengths), we aren't talking about addresses. We identify an address (which might be ::) and give it a length, but that is simply for notational convenience - if an address is important, we don't have to specify it separately. The "prefix" part would be the bitwise AND of the address and the mask or length.
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PltSWhkoDeatKmZk5zfNYvyTAwOGGXs1QxoG61Typ2k&s=9uH3IB_DbRwssRzuN8MTq_GsOzak8m7UmOaFkoX1Gro&e= 
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PltSWhkoDeatKmZk5zfNYvyTAwOGGXs1QxoG61Typ2k&s=9uH3IB_DbRwssRzuN8MTq_GsOzak8m7UmOaFkoX1Gro&e= 
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>


From nobody Tue Mar 28 11:18:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09231297C2 for ; Tue, 28 Mar 2017 11:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 0_4KkwZ7yoMA for ; Tue, 28 Mar 2017 11:18:28 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB36C1294AB for ; Tue, 28 Mar 2017 11:18:28 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id y18so123959728itc.0 for ; Tue, 28 Mar 2017 11:18:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=tWYYH4SXEFfGK8M+MXvOqy7vkyOdQTfRqaipI5DlAqA=; b=qGt4s0+VGqYyLvK+L5UhOSfKIypTWWO5HO/m32iUUmbFtzKKXYv7IZt88J30Bc8S0W SSYpcAPMFHs2kMqMlEIUE9DNrUWpwhBMmltlfgnUcCXIlCJc9rVMFcchiWYJw2lmxYOS 1bSSvMtktwaWq5QsmBMUJxot/Tw7awaYxLZ0doCtIRjYUd95iwQP50Z/EY9CJirPnM/w FNmF0DqhXmxjV1FnbVsE9plj3ZMOVCOUR0Tg7dgIzZfn4bC3xyLbTXMsL/dE8bF3AUNY Ra4iahEDANc/ipk2AGGFFVSFfRIo40utszHYRHLdYs8RzXs2o2f0ZXlGP26WDlZa0byu B5jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=tWYYH4SXEFfGK8M+MXvOqy7vkyOdQTfRqaipI5DlAqA=; b=qelOFUhd/kYDjysgmUiaDFAhALwN9C1YYFcF0wvv168NLvkDwmEWJy/AKhT+XDR5FN e4Q3hnOCpNYdmwnbq8afwhFhiyqaxCUNunkMAiXVgoJFeRJd7xU0qlpsWOsPHlE9kMls J6AJh5wI/Ioo7huBNcOIKaY57FryCbE8LCUGmlOkdf8yzWYXMLr/atQxPfbNAtutYHW5 Tnu3+eS1rMNwerJk3L0H5jqMFPJuF7KxCXHzD65k4jzcxmFdmy4EJ7W72pwje15tnjZB 2Kb33ec35Brut+Y0Y8CaLZhYltzUyTftW8RKgjUG72wYk1kuRVxCbkxRMYcHyOcFm/Ep moCg==
X-Gm-Message-State: AFeK/H3/w1IK26YOD/N/UxeFAAk7Dq8BKTP3pPAXN8ifBlSfNbxv4B6+ITZA7q1gp/KoUg==
X-Received: by 10.107.203.7 with SMTP id b7mr28169516iog.115.1490725108010; Tue, 28 Mar 2017 11:18:28 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 123sm2291250iow.28.2017.03.28.11.18.27 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 11:18:27 -0700 (PDT)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
To: 6man 
References: <149072338991.1228.10342495694037829468@ietfa.amsl.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Wed, 29 Mar 2017 07:18:31 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <149072338991.1228.10342495694037829468@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 18:18:31 -0000

Honestly, this impresses nobody:

>         Authors         : Daniel Voyer
>                           Daniel Bernier
>                           John Leddy
>                           Clarence Filsfils
>                           Stefano Previdi
>                           Stefano Salsano
>                           Antonio Cianfrani
>                           David Lebrun
>                           Olivier Bonaventure
>                           Prem Jonnalagadda
>                           Milad Sharif
>                           Hani Elmalky
>                           Ahmed Abdelsalam
>                           Robert Raszuk
>                           Arthi Ayyangar
>                           Dirk Steinberg
>                           Wim Henderickx


From nobody Tue Mar 28 11:28:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF65129438 for ; Tue, 28 Mar 2017 11:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 JVZYW5Lnzxlf for ; Tue, 28 Mar 2017 11:28:30 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB81E1297EB for ; Tue, 28 Mar 2017 11:28:29 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id e75so65732420itd.1 for ; Tue, 28 Mar 2017 11:28:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=yd9bw0i29a6RZd5/SJK7569Ut+PnMuZd1yDRDIldUmA=; b=h1Rr0PQmSUMk66QbXChJP803o24fdBer/uvpszw7I6UGaP1AedCjSv6Yb4wWO9CKdw gIITEE5AyPPTLWbgzpi+zX6pB1hJxww9jy8Yt4cl6JqRmB7/5X9SHwYgcKdbF5Pyn4Ub GcQxDtaTI85TomYEIz/i2zN9evRoj0x7ysUac8ZeHyplKcReohCbedbgHgbE+OZqDTe8 AMGXgQ6TYJthl4yEIXP8tCnDGjrHVr9jCEHKwmUd9i7jz+GDcjJassBytEPKpnPwIpBZ BuyOzMLINMpgxGcJ/6Z0Md6EdTQX2kHiLZ3LO/yKBL8mF+1zIxvHruI0qy/JIGlL/7QW dpwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=yd9bw0i29a6RZd5/SJK7569Ut+PnMuZd1yDRDIldUmA=; b=KzTq/rugje9VHw/ep/wEMOMmNuCV8Kro6kh+u7Dee4dBotIxwBzjKiuwOYrgIEr94F Q2hsgDmVX9VBr8gY9u0u8hdESN+iePr/epvVrPFrKIW5Lkyw28tR2LMMPYOAXkOx/U6o J8BxRI3fdj9KprgJByinliJFSoyfhdL2905+MAUOp+gOEip1uRLAMvdPb4erTHZnogn5 A0HoyUaPlXkzMjxng8TNf2nf0Mt0gbNl5C5Z9FNB3X286GsxchOrz3+xf2P0p880qdHJ qj7xklqa2jdrsrFwtxK+rs9dSq/jM6X++0SccDEQP1vV6ZiVwxxuDRhBL2BZyKKH99LV YXlg==
X-Gm-Message-State: AFeK/H032vEgJxV6UtG3rP4JDsRuXQHbgh2Wmpnr49hcdFUpQQShnlqViZpnspEopfJ58w==
X-Received: by 10.36.230.65 with SMTP id e62mr6031367ith.3.1490725709191; Tue, 28 Mar 2017 11:28:29 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g64sm2301956iof.25.2017.03.28.11.28.28 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 11:28:28 -0700 (PDT)
From: Brian E Carpenter 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
To: 6man 
References: <149072338991.1228.10342495694037829468@ietfa.amsl.com>
Organization: University of Auckland
Message-ID: <0667344d-ad0c-2e7c-2e67-be913d5293ca@gmail.com>
Date: Wed, 29 Mar 2017 07:28:32 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <149072338991.1228.10342495694037829468@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 18:28:31 -0000

> Hence, a context-less ban of
> IPv6 extension header insertion does not make sense.

RFC2460bis isn't contextless. The context is the Internet and therefore
the requirements for interoperable communication between any two nodes on
the Internet. I don't see any conflict between that and a additional
specification for local use of a feature that does not meet those requirements.

I think this draft would be much easier to consider without that sort
of phrasing.

    Brian


From nobody Tue Mar 28 12:26:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BDC129A0D; Tue, 28 Mar 2017 12:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 5dbeL5Auo9fs; Tue, 28 Mar 2017 12:26:22 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E92512955E; Tue, 28 Mar 2017 12:26:20 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HJAABruNpY/yYyC4dTChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPRWGBCweDW4oPkVGIF401gUtDKoV4AhqDCz8YAQIBAQEBAQE?= =?us-ascii?q?BA2gogmI3AwwhCAMBAQEBAQEBAQECAQFIAg9BAQEYAQEBAQIBEhEROgsMBgEID?= =?us-ascii?q?QQEAQEBAgIGHQMCBB8RFAEICQEEAQ0FCBqFXINxAw0IAQ2iV4pjgiYmAocIDYM?= =?us-ascii?q?RAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VEhG6CUUaBFSoVgm8ugjEFlhCGF?= =?us-ascii?q?joBhnuHGgGPKYZCim+Iex85gQRZFUGFDoFKdQEBiEMBgQwBAQE?=
X-IPAS-Result: =?us-ascii?q?A2HJAABruNpY/yYyC4dTChkBAQEBAQEBAQEBAQcBAQEBAYM?= =?us-ascii?q?PRWGBCweDW4oPkVGIF401gUtDKoV4AhqDCz8YAQIBAQEBAQEBA2gogmI3AwwhC?= =?us-ascii?q?AMBAQEBAQEBAQECAQFIAg9BAQEYAQEBAQIBEhEROgsMBgEIDQQEAQEBAgIGHQM?= =?us-ascii?q?CBB8RFAEICQEEAQ0FCBqFXINxAw0IAQ2iV4pjgiYmAocIDYMRAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWBC4VEhG6CUUaBFSoVgm8ugjEFlhCGFjoBhnuHGgGPKYZ?= =?us-ascii?q?Cim+Iex85gQRZFUGFDoFKdQEBiEMBgQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.36,237,1486443600"; d="scan'208";a="233312216"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Mar 2017 15:26:19 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2017 15:28:51 -0400
Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Tue, 28 Mar 2017 15:26:04 -0400
From: "Mudric, Dusan (Dusan)" 
To: Brian E Carpenter , "Lubashev, Igor" , Fred Baker , "Alexandre Petrescu" 
CC: 6man , "draft-ietf-6man-rfc4291bis.all@ietf.org" 
Subject: RE: Another issue in rfc4291bis [was draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation]
Thread-Topic: Another issue in rfc4291bis [was draft-lubashev-ipv6-addr-mask: IPv6 Address/Mask Notation]
Thread-Index: AdKn+BehtAGJM4ZiS7+dEBwjD94F5A==
Date: Tue, 28 Mar 2017 19:26:01 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E4585A2777A@AZ-US1EXMB03.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.11.85.49]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 19:26:26 -0000

PiA+IFRoZXkgYXJlIGNvbXBsZXRlbHkgZXF1YWwsIGJlY2F1c2UgLzEwIHNheXMgIm9ubHkgbG9v
ayBhdCB0aGUgZmlyc3QgMTAgYml0cyIuDQo+ID4gSXQgbWlnaHQgYmUgY29uZnVzaW5nLCBidXQg
aXQncyBub3Qgd3JvbmcgSU1ITy4NCg0KV2UgbWlnaHQgYmUgdXNlZCB0byB0aGlzIHN5bnRheCwg
YnV0IGEgbGl0dGxlIGNsZWFudXAgd2lsbCBoZWxwIG1ha2UgaXQgdW5hbWJpZ3VvdXMuIFdoeSBw
cmVzZW50aW5nIExMIHByZWZpeCBhcyBmZTgxOjovMTA/IFRoZSBub24temVybyBhZGRyZXNzIGJp
dHMgc2hvdWxkIG5vdCBiZSBwYXJ0IG9mIHRoZSBwcmVmaXguDQoNCj4gPiBNYXliZSB3ZSBuZWVk
IFJGQzU5NTJiaXMsIGJlY2F1c2UgUkZDNTk1MiBkb2VzIG5vdCBkaXNjdXNzIHByZWZpeA0KPiBu
b3RhdGlvbiBpbiBkZXRhaWwuDQoNCkFncmVlLg0KDQpEdXNhbg0KDQo+ID4gT24gMjgvMDMvMjAx
NyAyOjE2IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gDQo+IDEuIElmIHlvdSBhcmUg
cHV6emxlZCBhYm91dCAiQW5vdGVnciIgaXQncyBhIGJhZGx5IG1hbmdsZWQgIkFub3RoZXIiDQo+
IA0KPiAyLiBJIGp1c3QgaGFkIGEgY29udmVyc2F0aW9uIGFib3V0IHRoaXMgaXNzdWUgd2l0aCB0
aGUgZWRpdG9yIG9mIHJmYzQyOTFiaXMuDQo+IFRoZSBpc3N1ZSByZWFsbHkgaXMgdGhhdA0KPiAy
MDAxOjBkYjg6MDpjZDMwOjEyMzo0NTY3Ojg5YWI6Y2RlZi82MA0KPiBpcyBpbnZhbGlkIGlmIGlu
dGVuZGVkIGFzIGEgcHJlZml4IGFuZCBzaG91bGQgYmUgZXhwcmVzc2VkIGFzDQo+IDIwMDE6MGRi
ODowOmNkMzA6Oi82MA0KPiBidXQgaXQncyB2YWxpZCBpZiBpbnRlbmRlZCBhcyBhbiBhZGRyZXNz
IHF1YWxpZmllZCBieSB0aGUgYXBwbGljYWJsZSBwcmVmaXguDQo+IA0KPiBUaGUgcHJvYmxlbSBp
cyB0aGF0IHRoZSBzeW50YXggZG9lc24ndCBkaXN0aW5ndWlzaCB0aGUgbGVnYWwgZnJvbSB0aGUg
aWxsZWdhbCB1c2UsDQo+IGJlY2F1c2UgaXQgZG9lcyBub3QgZXhwcmVzcyB0aGUgaW50ZW5kZWQg
aW50ZXJwcmV0YXRpb24uDQo+IFNvIHRoZSBpbnRlcnByZXRhdGlvbiBhbmQgdmFsaWRpdHkgaXMg
Y29udGV4dC1kZXBlbmRlbnQuDQo+IA0KPiBSZWdhcmRzDQo+ICAgIEJyaWFuDQo+IA0KPiBPbiAy
OS8wMy8yMDE3IDA1OjI2LCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gPiAqQ2hhbmdlIG9m
IHN1YmplY3QgYW5kIG1haWxpbmcgbGlzdCoNCj4gPg0KPiA+IE9uIDI5LzAzLzIwMTcgMDM6MTQs
IE11ZHJpYywgRHVzYW4gKER1c2FuKSB3cm90ZToNCj4gPj4gUkZDIDQyOTEgZG9lcyBub3Qgd2Vs
bCBkZWZpbmUgdGhlIGFkZHJlc3Mgc3ludGF4LiBJdCBjb21iaW5lcyB0aGUgcHJlZml4IGFuZA0K
PiB0aGUgYWRkcmVzcyBzeW50YXggaW50byBvbmU6DQo+ID4+DQo+ID4+IFNlY3Rpb24gMi4zDQo+
ID4+ICIgICAgICB0aGUgbm9kZSBhZGRyZXNzICAgICAgMjAwMTowREI4OjA6Q0QzMDoxMjM6NDU2
Nzo4OUFCOkNERUYNCj4gPj4gICAgICAgYW5kIGl0cyBzdWJuZXQgbnVtYmVyIDIwMDE6MERCODow
OkNEMzA6Oi82MA0KPiA+Pg0KPiA+PiAgICAgICBjYW4gYmUgYWJicmV2aWF0ZWQgYXMgMjAwMTow
REI4OjA6Q0QzMDoxMjM6NDU2Nzo4OUFCOkNERUYvNjAiDQo+ID4+DQo+ID4+IFRoaXMgaXMgbm90
IGEgZ29vZCBleGFtcGxlLiBUaGUgcHJlZml4LWxlbmd0aCBvZiA2MCBkb2VzIG5vdCBtZWFuIHRo
ZSBmb3VyDQo+IGJpdHMgYWZ0ZXIgJ0NEMycgbXVzdCBiZSB6ZXJvLg0KPiA+DQo+ID4gTm8sIG9m
IGNvdXJzZSBub3QsIHRoZSBleGFtcGxlIHdvdWxkIGJlIGVxdWFsbHkgdmFsaWQgaWYgaXQgc2hv
d2VkDQo+ID4gMjAwMTowZGI4OjA6Y2QzZjoxMjM6NDU2Nzo4OWFiOmNkZWYNCj4gPiAgMjAwMTow
ZGI4OjA6Y2QzMDo6LzYwDQo+ID4gIDIwMDE6MGRiODowOmNkM2Y6MTIzOjQ1Njc6ODlhYjpjZGVm
LzYwDQo+ID4NCj4gPiAuLi4NCj4gPj4gVGhlIHByZWZpeC1sZW5ndGggc2hvdWxkIG5vdCBiZSB1
c2VkIGluIHRoZSBhZGRyZXNzIHN5bnRheCAoZS5nLiB1c2UNCj4gPj4gMjAwMTowREI4OjA6Q0Qz
MDoxMjM6NDU2Nzo4OUFCOkNERUYgYWRkcmVzcyBhbmQgbm90DQo+ID4+IDIwMDE6MERCODowOkNE
MzA6MTIzOjQ1Njc6ODlBQjpDREVGLzYwDQo+ID4NCj4gPiBJZiB0aGVyZSBpcyBhIC8gaXQgaXMg
YSBwcmVmaXgsIEkgYWdyZWUuIEkgdGhpbmsgdGhlIHRleHQgaXMNCj4gPiBtaXNsZWFkaW5nIGZv
ciB0aGF0IHJlYXNvbi4gVGhpcyBjb3VsZCBiZSBmaXhlZCBpbiA0MjkxYmlzLiAqVGhlDQo+ID4g
c2ltcGxlc3Qgd2F5IGlzIHRvIGRlbGV0ZSB0aGUgdGV4dCBzdGFydGluZyAiV2hlbiB3cml0aW5n
IGJvdGggYSBub2RlDQo+ID4gYWRkcmVzcyBhbmQgYSBwcmVmaXggb2YgdGhhdCBub2RlIGFkZHJl
c3MiDQo+ID4gdGhyb3VnaCB0aGUgZW5kIG9mIHRoZSBzZWN0aW9uKi4NCj4gPg0KPiA+IChBcyBm
YXIgYXMgSSBjYW4gc2VlLCBpZiB3ZSB3YW50IHRvIGV4cHJlc3MgYXMgYSBzaW5nbGUgaXRlbSBi
b3RoIGFuDQo+ID4gYWRkcmVzcyBhbmQgaXRzIGFwcGxpY2FibGUgc3VibmV0IHByZWZpeCwgd2Ug
bmVlZCBuZXcgbm90YXRpb24sIGUuZy4NCj4gPiAyMDAxOmRiODowOmNkM2Y6MTIzOjQ1Njc6ODlh
YjpjZGVmLy82MC4pDQo+ID4NCj4gPj4gVGhlIHByZWZpeCBzeW50YXggbXVzdCBkZWZpbmUgdGhh
dCBhbGwgYml0cyBvdXRzaWRlIHRoZSBwcmVmaXgtbGVuZ3RoIG11c3QgYmUNCj4gc2V0IHRvIHpl
cm8uIFNvLCBmZTkwOjovMTAsIGZlODE6Oi8xMCBhcmUgbm90IHRoZSB2YWxpZCBMTCBwcmVmaXhl
cy4NCj4gPg0KPiA+IFRoZXkgYXJlIGNvbXBsZXRlbHkgZXF1YWwsIGJlY2F1c2UgLzEwIHNheXMg
Im9ubHkgbG9vayBhdCB0aGUgZmlyc3QgMTAgYml0cyIuDQo+ID4gSXQgbWlnaHQgYmUgY29uZnVz
aW5nLCBidXQgaXQncyBub3Qgd3JvbmcgSU1ITy4NCj4gPg0KPiA+IE1heWJlIHdlIG5lZWQgUkZD
NTk1MmJpcywgYmVjYXVzZSBSRkM1OTUyIGRvZXMgbm90IGRpc2N1c3MgcHJlZml4DQo+IG5vdGF0
aW9uIGluIGRldGFpbC4NCj4gPg0KPiA+ICAgICBCcmlhbg0KPiA+DQo+ID4+DQo+ID4+IFdpdGgg
dGhlc2UgY2hhbmdlcywgZG8gd2Ugc3RpbGwgbmVlZCB0aGUgYWRkcmVzcyBtYXNrPw0KPiA+Pg0K
PiA+PiBEdXNhbg0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBG
cm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBM
dWJhc2hldiwNCj4gPj4gSWdvcg0KPiA+PiBTZW50OiBUdWVzZGF5LCBNYXJjaCAyOCwgMjAxNyA5
OjI1IEFNDQo+ID4+IFRvOiBGcmVkIEJha2VyOyBBbGV4YW5kcmUgUGV0cmVzY3UNCj4gPj4gQ2M6
IHY2b3BzIGxpc3QNCj4gPj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtbHViYXNoZXYtaXB2
Ni1hZGRyLW1hc2s6IElQdjYgQWRkcmVzcy9NYXNrDQo+ID4+IE5vdGF0aW9uDQo+ID4+DQo+ID4+
IFRoZSB3YXkgSSBwdXQgaXQgaW4gdGhlIGRyYWZ0Og0KPiA+Pg0KPiA+PiAnW1NlYyAxLjFdIERl
cGVuZGluZyBvbiB0aGUgY29udGV4dCwgbmV0bWFzayBhbmQgcHJlZml4IGxlbmd0aCBub3RhdGlv
bnMgY2FuDQo+IHNwZWNpZnkgZWl0aGVyIGEgImdyb3VwIG9mIGFkZHJlc3NlcyIgb3IgImEgZ3Jv
dXAgb2YgYWRkcmVzc2VzIGFuZCBhIHNwZWNpZmljDQo+IGFkZHJlc3Mgd2l0aGluIHRoYXQgZ3Jv
dXAiLiAuLi4NCj4gPj4NCj4gPj4gW1NlYyA0LjFdIFRvIGJlIGEgdmFsaWQgZGVmaW5pdGlvbiBm
b3IganVzdCBhIGdyb3VwIG9mIGFkZHJlc3NlcywgdGhlIGFkZHJlc3MNCj4gcGFydCBNVVNUIE5P
VCBoYXZlIGFueSBiaXRzIG91dHNpZGUgb2YgdGhlIG1hc2sgc2V0LiInDQo+ID4+DQo+ID4+IFNv
IGl0IGlzIGFsbCBhYm91dCB0aGUgY29udGV4dC4gIEkuZS4gdGhlIG91dHB1dCBvZiAiaXAgYWRk
ciIgdnMgImlwIHJvdXRlIiBvbg0KPiBMaW51eC4NCj4gPj4NCj4gPj4gLSBJZ29yDQo+ID4+DQo+
ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEZyZWQgQmFrZXIgW21h
aWx0bzpmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IFR1ZXNkYXksIE1hcmNo
IDI4LCAyMDE3IDc6NTYgQU0NCj4gPj4gVG86IEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJl
LnBldHJlc2N1QGdtYWlsLmNvbT4NCj4gPj4gQ2M6IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3Jn
Pg0KPiA+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1sdWJhc2hldi1pcHY2LWFkZHItbWFz
azogSVB2NiBBZGRyZXNzL01hc2sNCj4gPj4gTm90YXRpb24NCj4gPj4NCj4gPj4NCj4gPj4+IE9u
IE1hciAyOCwgMjAxNywgYXQgNzo0OSBBTSwgQWxleGFuZHJlIFBldHJlc2N1DQo+IDxhbGV4YW5k
cmUucGV0cmVzY3VAZ21haWwuY29tPiB3cm90ZToNCj4gPj4+DQo+ID4+PiBJcyB0aGVyZSBzb21l
IG1hbmRhdGUgdG8gbWFuZGF0ZSB0aGF0IHRoZSBob3N0IGJpdHMgYXJlIDAgd2hlbiB3ZSB0YWxr
DQo+IGFib3V0IHRoZSBzdWJuZXQgbWFzaz8NCj4gPj4NCj4gPj4gV2hlbiB3ZSdyZSB0YWxraW5n
IGFib3V0IHN1Ym5ldCBtYXNrcyAob3IgbGVuZ3RocyksIHdlIGFyZW4ndCB0YWxraW5nIGFib3V0
DQo+IGFkZHJlc3Nlcy4gV2UgaWRlbnRpZnkgYW4gYWRkcmVzcyAod2hpY2ggbWlnaHQgYmUgOjop
IGFuZCBnaXZlIGl0IGEgbGVuZ3RoLCBidXQNCj4gdGhhdCBpcyBzaW1wbHkgZm9yIG5vdGF0aW9u
YWwgY29udmVuaWVuY2UgLSBpZiBhbiBhZGRyZXNzIGlzIGltcG9ydGFudCwgd2UgZG9uJ3QNCj4g
aGF2ZSB0byBzcGVjaWZ5IGl0IHNlcGFyYXRlbHkuIFRoZSAicHJlZml4IiBwYXJ0IHdvdWxkIGJl
IHRoZSBiaXR3aXNlIEFORCBvZiB0aGUNCj4gYWRkcmVzcyBhbmQgdGhlIG1hc2sgb3IgbGVuZ3Ro
Lg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiA+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPj4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6
Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v
cmdfbWFpDQo+ID4+DQo+IGxtYW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lDQWcmYz1CRnBXUXc4YnN1
S3BsMVNnaVpINjRRJnI9VVQzQms5Y2INCj4gTGVhSngNCj4gPj4NCj4gaGYzaUNyaElvVVdCOFlM
WlUyMzAyOXNNUUdRMmtZJm09UGx0U1doa29EZWF0S21aazV6Zk5ZdnlUQXdPRw0KPiBHWHMxUXhv
Rw0KPiA+PiA2MVR5cDJrJnM9OXVIM0lCX0RiUndzc1J6dU44TVRxX0dzT3phazhtN1VtT2FGa29Y
MUdybyZlPQ0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiA+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPj4gdjZvcHNAaWV0Zi5vcmcN
Cj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB
X193d3cuaWV0Zi5vcmdfbWFpDQo+ID4+DQo+IGxtYW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lDQWcm
Yz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2INCj4gTGVhSngNCj4gPj4NCj4gaGYz
aUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09UGx0U1doa29EZWF0S21aazV6Zk5ZdnlUQXdP
Rw0KPiBHWHMxUXhvRw0KPiA+PiA2MVR5cDJrJnM9OXVIM0lCX0RiUndzc1J6dU44TVRxX0dzT3ph
azhtN1VtT2FGa29YMUdybyZlPQ0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPj4gdjZv
cHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpDQo+ID4+DQo+IGxtYW5fbGlzdGluZm9fdjZv
cHMmZD1Ed0lDYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2INCj4gTGVhSngN
Cj4gPj4NCj4gaGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09WUd6Y3o2Z3Y4aGQ2Y0k2
RlRaYTRDRHZPVjRtWg0KPiBNTDJXWEROZQ0KPiA+PiBHdUpVMHhNJnM9bVF6QWEzdHhIZnEyalZr
TGZ0Z0E2TVFyVXhtelFoMmQzdHRtV0tnelBqVSZlPQ0KPiA+Pg0K


From nobody Tue Mar 28 13:01:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30D11295E7 for ; Tue, 28 Mar 2017 13:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 g02jIyVkMnFt for ; Tue, 28 Mar 2017 13:01:47 -0700 (PDT)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA0C1275AB for <6man@ietf.org>; Tue, 28 Mar 2017 13:01:47 -0700 (PDT)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Mar 2017 20:01:46 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 47F5DD788D; Tue, 28 Mar 2017 13:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=bxcJNMl/PcEAuxyMDX14z3eIDIQ=; b= NLawa2TweGYmHff+at6R1P7KIx1m458lVdqGtLHoiW96lPSWwDAmd/a/sLIhtfLW CFSmrO1RTrVBTmjH8eI1Z2GjojzKo5Yr7xvQoMxNsEjjjKjlKUheANzzKRmM2S0P 3ibyXIh9KMpMRJXTJKJQiOf5f7fx1SrgAhm2H7VEXOk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=sl/w+I9HCrdWwthsgV+NGtT e8YxUVIlufvxW8XJLoE3/i9IkJ7d6akyivF6QzlaJatu2m18NOWO5zuYHjjOat3X W1g6R1ivD2+KwmxxZhmsIvTcZpSHdM64gdhDUapMK93opCwdLpVBWY522p4mKbhY /hqv4iam9rYm2qHQwBTQ=
Received: from h.hanazo.no (dhcp-9178.meeting.ietf.org [31.133.145.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 38AAAD788A; Tue, 28 Mar 2017 13:01:46 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A6424A5BF70A; Tue, 28 Mar 2017 15:01:45 -0500 (CDT)
From: otroan@employees.org
Message-Id: <4DED73FC-C2A5-4E50-A270-A8EF83337D9A@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_9D019407-9BEB-4BA8-A975-406E09FBF003"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: comments on draft-pioxfolks-6man-pio-exclusive-bit-01
Date: Tue, 28 Mar 2017 15:01:44 -0500
In-Reply-To: 
Cc: "6man@ietf.org" <6man@ietf.org>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= 
References: 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 20:01:49 -0000

--Apple-Mail=_9D019407-9BEB-4BA8-A975-406E09FBF003
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

> - Perhaps this draft should say routers SHOULD NOT set the L flag of a
>  PIO if it sets the X flag.

I think this mechanism is fundamentally incompatible with a set L flag.
So that should be a MUST NOT set and MUST ignore on receive.

Cheers,
Ole

--Apple-Mail=_9D019407-9BEB-4BA8-A975-406E09FBF003
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJY2sEpAAoJEL7aWKiYQt92P3MP/iLf9/Q4ueE46H87pM/4ik58
hV67omnAC8SjkIbMbV+u6mZjQuDj6lj7zKe8N6U8jT0CjQP2AcYzJeyhXa+uVIss
TFk6+Ddt+BvUhskH2Pfl/d/kyzRuw19Sciw/BhOgcht4BaQjRGp0XPETzTPyGW8K
Kb9+0JPsSoqUW2NbJt1sip8E4Fh7vfBRqJUc81g7xO857UwbEqstL6kjyjKuun2i
srqBJfaSv1UB3gcl+RMgM5u3HIo1nVE1SWK+s3z2WLXFi6S26Wc4vvaE/Ao3rKro
ylGLyyNo+QvnoVinu4JPnKoUIGR7wsEahoW9kFXNT4ggKzxihElILQiUzbwxlM0Q
OY6xCYv4LtI9zauBYhb/+4fTmm7vO0PW8xHIMEU9mBA1xiMKl0y0Fo2UNTiVL44K
/rQiV5QjgiBbP5J0/KPUK3oM13CK4Y0RIcR5uQjDDEH2gMhZgjh/XFrttZq5+xbA
MUn8fm4RJRZJewXxlW6o07+wXX4lKi0r2TfBbhzSLIEMLpkaciu6OLiAIF4sE/ae
N86KNhkY0eGT67Kp8GJDlQ80dJchhOV1lASO0FFU4W9DoVIHJBzlWaL8KlnIcokW
xwP59f3QvJDjL+PxXFaT4V9o8S1DW8rmFfq4qvliouIX311xpo4zGhpj/ZzXrtm2
3iMafWkksfPuXbWzrSMe
=TT5H
-----END PGP SIGNATURE-----

--Apple-Mail=_9D019407-9BEB-4BA8-A975-406E09FBF003--


From nobody Tue Mar 28 13:08:26 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C178127078 for ; Tue, 28 Mar 2017 13:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 g8KTp9nZqZQB for ; Tue, 28 Mar 2017 13:08:22 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7849E124217 for ; Tue, 28 Mar 2017 13:08:22 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id r69so101812123vke.2 for ; Tue, 28 Mar 2017 13:08:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=tOg0KJ9KIL5zqRTFV44YYJ4mUm/ikhZfHBzCPCFrsds=; b=JnsEEJXTPHwB2e1E1pCfSbEMsnYMBVyoG/PyPk9eGW2sU9Tj/sa0zVtJKxWOgvmkQ9 emJDotUS2kmVTi6CzsgJ6VxJr9Y6D2zTgzWQknGktkg0dF6RY8WPXh6lSXZuBsiel00T zRuBaOgcIkgn0vNATaZhoSlDatIOfnXH6/xJKxImoVtVqo2dVx7JvkmXDxXq7mVtLC1P qpqygmJC6PA6TNAweCApKiI3qf7hKz/FQXOJvxIIc2QkTCOuKREotpgbQxy4Elld9u9g goBArGS0JnPku85u517wilqCg2op7izoy15yn89tqR1W0+rnqrgBRvLqg/nZkOU/h0uI fmGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tOg0KJ9KIL5zqRTFV44YYJ4mUm/ikhZfHBzCPCFrsds=; b=gfMROJ1/drnfjTmri9c6RlwRm+9MSOzrpV7V6QVZdEkW/1f/U5B96SeBq/pAm/dOtq Cr9SnlWmtM/6WYU0isl3wA/tCxL0BsK5DfO//8rWDnTDs/oi8bYgoPS9J4d1lsyfbLZY hTW38x52dZoiX4JRZN02q8NeLcPOpIRIVctG0+tfCg7rrSs+6ostMXCm1/Zd5uWz7M4D QdyjObItY8emJc1u0mQMamI7rBW0bXol2qpwCNJnzFGboc+Cm58HnHrl3ceJAmVcSdmW MQmrJOq1wBrTn/aZBrPunLYZeMP6GwBYLrkrDHVN+JB04lM9O6asgoP9GF/Yy2n2cuzS H59g==
X-Gm-Message-State: AFeK/H1segqMmVRRV9RzCl6/a+C91ChXmzIEYIWJiY7T2wP2dwWuqtp9ZjzPGzUO59x7d2CGofv9OUXl2WcYpg==
X-Received: by 10.176.83.124 with SMTP id y57mr1917668uay.141.1490731701336; Tue, 28 Mar 2017 13:08:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.181 with HTTP; Tue, 28 Mar 2017 13:07:51 -0700 (PDT)
From: Mark Smith 
Date: Wed, 29 Mar 2017 07:07:51 +1100
Message-ID: 
Subject: draft-voyer-6man-extension-header-insertion
To: 6man WG 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 20:08:25 -0000

They're missing the difference between encapsulation and insertion.

The increase and decrease in "packet" size that is occurring in their
6PE example is as the PDU crosses layer boundaries due to
encapsulation or decapsulation. This is occurring as the PDU travels
vertically between layers. From the IPv6 perspective, the 6PE layer is
a link layer below the network layer.

While the IPv6 packet traverses the 6PE domain, the IPv6's packet size
and structure is not changed in any way.

EH insertion is increasing the PDU size and changing the packet
structure while the packet travels horizontally within the IPv6 layer.
That will break things if the destination host doesn't expect the
packet size or structure to change, and they don't, because it is not
a described "within layer" packet processing behaviour in RFC2460. The
destination host expects that the packet received has a structure and
size that is the same as sent by the device identified in the source
address field, which is the host that originated the packet.

EH insertion makes the source address field both meaningless and
holding an incorrect value while the inserted EH is present. A
specification for EH insertion would need to state this very clearly.
Many of the negative consequences of EH insertion are because it makes
the packet's source address field meaningless and holding a incorrect
value.

The only things that are permitted to change while an IPv6 packet is
in flight (within the IPv6 layer) are values of a defined set of
fields specified in RFC2460 e.g., hop limit, flow label, traffic
class. Only field values change, no fields are added or removed - the
packet's structure and size stays the same after these modifications
if or when they occur.


Regards,
Mark.


From nobody Tue Mar 28 19:43:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989B61286AB for ; Tue, 28 Mar 2017 19:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
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 63vl6gQt_mlU for ; Tue, 28 Mar 2017 19:42:59 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFBE127337 for ; Tue, 28 Mar 2017 19:42:58 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id A0BDE7CB16 for ; Tue, 28 Mar 2017 22:42:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; s=sasl; bh=0ESQWS ISGk89s2po7rWQ02xOXF8=; b=B4yiXYPTgArjlwzwmODW2wj295Jq9eeeDuKvSn 3vicqOJZb3iPXqfpWgBRHLlunFWE223mnX711HKrT7s/V8gb4KuqAVA+tOyZ99zm Tn/kPLyB4AgywdIKmseaJsUyrhMJrNP2BHHh0c9N7vTXC1kL3gi1UXTjs9MmphpY woJeQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; q=dns; s=sasl; b= XV4rA++SVBeZWyfdVTUad3gEnjr6V8IwzTB6hmKWnaLNuEAiwax2GvJeg+mQxOj5 qaTYd8lasBSw0UCFfjJwK4qL3cW+1BlNV0LueA00XBNzkafvzFf8cfsaV07FPJzd Ouyrx/yUP5Y7403/JnFTjfL2cfFAn2TIN7EjcRvJpvE=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 9AA897CB14 for ; Tue, 28 Mar 2017 22:42:57 -0400 (EDT)
Received: from mail-qt0-f180.google.com (unknown [209.85.216.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 2AFA37CB13 for ; Tue, 28 Mar 2017 22:42:57 -0400 (EDT)
Received: by mail-qt0-f180.google.com with SMTP id n21so2340088qta.1 for ; Tue, 28 Mar 2017 19:42:57 -0700 (PDT)
X-Gm-Message-State: AFeK/H1MO9vguilmwW8OMTezrso22AXZ290rBMa4Sl9kA8J8gDMEA1eRLOmg8E9UedwfmeOr6mGleeZPH/iBDQ==
X-Received: by 10.200.53.45 with SMTP id y42mr28662391qtb.267.1490755376659; Tue, 28 Mar 2017 19:42:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.18.75 with HTTP; Tue, 28 Mar 2017 19:42:36 -0700 (PDT)
From: "C. M. Heard" 
Date: Tue, 28 Mar 2017 19:42:36 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
To: 6man WG 
Content-Type: text/plain; charset=UTF-8
X-Pobox-Relay-ID: 6A8BFE12-1429-11E7-A057-FC50AE2156B6-06080547!pb-smtp2.pobox.com
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 02:43:01 -0000

On Wed, 29 Mar 2017 07:28:32 +1300 Brian E Carpenter wrote:
> > Hence, a context-less ban of
> > IPv6 extension header insertion does not make sense.
>
> RFC2460bis isn't contextless. The context is the Internet and therefore
> the requirements for interoperable communication between any two nodes
> on the Internet. I don't see any conflict between that and a additional
> specification for local use of a feature that does not meet those
> requirements.
>
> I think this draft would be much easier to consider without that sort
> of phrasing.

Agreed, and in the same vein, I think that the draft would be more credible
if the first sentence of the abstract were changed along the following lines:

OLD:
   The network operator and vendor community has clearly indicated that
   IPv6 header insertion is useful and required.

NEW:
   Certain segments of the network operator and vendor community have
   clearly indicated that IPv6 header insertion is useful and required
   for their purposes.

//cmh


From nobody Wed Mar 29 08:33:35 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ED01296E1 for ; Wed, 29 Mar 2017 08:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 Kj5rdihnHQGb for ; Wed, 29 Mar 2017 08:33:31 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88241129526 for ; Wed, 29 Mar 2017 08:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490801609; bh=M52c0FCKZw2QoXm0wZ0Wb3k1thDpqzPxJWT+SkRxFOA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D6/ICsrFAGA+0xs1UK2Fi1lPk9f7CNUqtxzn5BpfltQvLQDdyM9C/04MvKJRj2EQ1hT9awrOnoruT0wfRDRm9MNZvF2vIq2dE6n3Y7nvOLvixYD5SXWmAplSt1z3T0XeLw2vr2yT57clBAS9ZKq9oHHopht8yUdmxhXNrrD4/8E=
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0149.outbound.protection.outlook.com [213.199.180.149]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-15-Hus9MjioODaoFbjYi4q1mQ-1; Wed, 29 Mar 2017 16:33:25 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 15:33:24 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 15:33:24 +0000
From: Tim Chown 
To: "C. M. Heard" 
CC: 6man WG 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Topic: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Index: AQHSqDYfWTtpVnOTu0uiU6CsaQBgZaGr8y2A
Date: Wed, 29 Mar 2017 15:33:24 +0000
Message-ID: <59B02E00-136D-4DDB-8707-F2DA61D4D3EA@jisc.ac.uk>
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:67c:370:128:7035:c113:5687:f48e]
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:Spt3RsRdO9ehkdNqqUwDp7F8JdqbAAfBojOwOZX2eQTk5bP8jhRDb9cmQUQ4pkckrrk8iC2FqeuvzdZkOxtfSZPcJgUTOvtUFB1OSb9kmBhbX3GnH4VqCiKyBCXZmc11bsscc9335j6ZJHoAnteiDc3/Tp/geR0epK4QVff9zGRhpL7/0wJxpU32KcWWMJzXQMQqgQqypF6S64YP1R5Dif3FXzasKij5Gp6S+vIwqSjqvsmdjYkBXYQoRNsIsuJdT/5c8Ml7TqM5AJ6qpEfrv0v5fT2pcLWhkPr9JwVFUWg67JvWtrME0VF9ZRdPhFegZYyThA8G6H2g0lycijIa/w==; 20:bCx3PiQA7SmEcyUh+OEhUcGPZKSTL3NoYJz0XnFOT/2hGQhfkGXRhEwXfCiMHsGryE9MQsouvZkPyJifRj43Ngu7B6S5P75jYotFJ34Wy1I6R8aBNcXonUUByg8YwANtkIxDi7nb0qn7ph1VpIgto6TWCKuzeR2AyADjMDnuz88=
x-ms-office365-filtering-correlation-id: 003f3182-cc97-4add-7087-08d476b8f069
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1137; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100324003535756);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406075)(20161123560025)(20161123564025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; 
x-forefront-prvs: 0261CCEEDF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(51444003)(24454002)(3280700002)(4326008)(6512007)(50226002)(99286003)(81166006)(3660700001)(36756003)(6246003)(8676002)(2906002)(6486002)(86362001)(6436002)(5250100002)(53936002)(305945005)(8936002)(102836003)(38730400002)(7736002)(6116002)(25786009)(229853002)(53546009)(110136004)(6506006)(5660300001)(57306001)(2950100002)(6916009)(33656002)(42882006)(189998001)(82746002)(83716003)(74482002)(50986999)(2900100001)(230783001)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: 
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 15:33:24.5164 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137
X-MC-Unique: Hus9MjioODaoFbjYi4q1mQ-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 15:33:33 -0000

SGksDQoNCj4gT24gMjkgTWFyIDIwMTcsIGF0IDAzOjQyLCBDLiBNLiBIZWFyZCA8aGVhcmRAcG9i
b3guY29tPiB3cm90ZToNCj4gDQo+IE9uIFdlZCwgMjkgTWFyIDIwMTcgMDc6Mjg6MzIgKzEzMDAg
QnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+Pj4gSGVuY2UsIGEgY29udGV4dC1sZXNzIGJhbiBv
Zg0KPj4+IElQdjYgZXh0ZW5zaW9uIGhlYWRlciBpbnNlcnRpb24gZG9lcyBub3QgbWFrZSBzZW5z
ZS4NCj4+IA0KPj4gUkZDMjQ2MGJpcyBpc24ndCBjb250ZXh0bGVzcy4gVGhlIGNvbnRleHQgaXMg
dGhlIEludGVybmV0IGFuZCB0aGVyZWZvcmUNCj4+IHRoZSByZXF1aXJlbWVudHMgZm9yIGludGVy
b3BlcmFibGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGFueSB0d28gbm9kZXMNCj4+IG9uIHRoZSBJ
bnRlcm5ldC4gSSBkb24ndCBzZWUgYW55IGNvbmZsaWN0IGJldHdlZW4gdGhhdCBhbmQgYSBhZGRp
dGlvbmFsDQo+PiBzcGVjaWZpY2F0aW9uIGZvciBsb2NhbCB1c2Ugb2YgYSBmZWF0dXJlIHRoYXQg
ZG9lcyBub3QgbWVldCB0aG9zZQ0KPj4gcmVxdWlyZW1lbnRzLg0KPj4gDQo+PiBJIHRoaW5rIHRo
aXMgZHJhZnQgd291bGQgYmUgbXVjaCBlYXNpZXIgdG8gY29uc2lkZXIgd2l0aG91dCB0aGF0IHNv
cnQNCj4+IG9mIHBocmFzaW5nLg0KPiANCj4gQWdyZWVkLCBhbmQgaW4gdGhlIHNhbWUgdmVpbiwg
SSB0aGluayB0aGF0IHRoZSBkcmFmdCB3b3VsZCBiZSBtb3JlIGNyZWRpYmxlDQo+IGlmIHRoZSBm
aXJzdCBzZW50ZW5jZSBvZiB0aGUgYWJzdHJhY3Qgd2VyZSBjaGFuZ2VkIGFsb25nIHRoZSBmb2xs
b3dpbmcgbGluZXM6DQo+IA0KPiBPTEQ6DQo+ICAgVGhlIG5ldHdvcmsgb3BlcmF0b3IgYW5kIHZl
bmRvciBjb21tdW5pdHkgaGFzIGNsZWFybHkgaW5kaWNhdGVkIHRoYXQNCj4gICBJUHY2IGhlYWRl
ciBpbnNlcnRpb24gaXMgdXNlZnVsIGFuZCByZXF1aXJlZC4NCj4gDQo+IE5FVzoNCj4gICBDZXJ0
YWluIHNlZ21lbnRzIG9mIHRoZSBuZXR3b3JrIG9wZXJhdG9yIGFuZCB2ZW5kb3IgY29tbXVuaXR5
IGhhdmUNCj4gICBjbGVhcmx5IGluZGljYXRlZCB0aGF0IElQdjYgaGVhZGVyIGluc2VydGlvbiBp
cyB1c2VmdWwgYW5kIHJlcXVpcmVkDQo+ICAgZm9yIHRoZWlyIHB1cnBvc2VzLg0KDQpXZWxsLCBJ
IHRoaW5rIGlmIHRoaXMgZG9jdW1lbnQgaXMgdG8gYmUgYWRvcHRlZCwgaXQgc2hvdWxkIHN0YXJ0
IGJ5IHNheWluZyBjbGVhcmx5IHdoeSBFSCDigJxpbnNlcnRpb27igJ0gYnkgZW5jYXBzdWxhdGlv
biBhcyBwZXIgUkZDMjQ2MC1iaXMgaXNu4oCZdCBzdWZmaWNpZW50IGluIHNwZWNpZmljIHNjZW5h
cmlvcy4NCg0KVGlt


From nobody Wed Mar 29 12:58:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463A41298AF for ; Wed, 29 Mar 2017 12:58:40 -0700 (PDT)
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, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fbgHwHL8xHPm for ; Wed, 29 Mar 2017 12:58:39 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D238F12989C for ; Wed, 29 Mar 2017 12:58:38 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id s68so30993260vke.3 for ; Wed, 29 Mar 2017 12:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=dsTH74Uil0PuFEQkt72LkahUimvnULfRquXH4dpbQig=; b=mb7xOiPyUNr3IkeZc4E0HwEs9a1J6AuAxukIeDoKxxg58HsZwdr9qk9hDh2Sfj+E69 riTFoAJW89syhzMqszwHlqLRuuiVMjy6dzu2DWvs6LdDWKcccF/HV6bW3iKi7ybENZXp 6ErXtoi3cAf5Ib6UF24TkM+xhITKXwn2FNGe3hEvC7aYikwGtFy3+8axfe/fsa2U8A4P RthaoFWeo0gWXv4zStvscW+cXO15WbwjWQ1GjZIfbO4gn8WKCFem5cTeG/Zc38K8yd5Q Xt9zwm1VU++8/uNoHAGjZgRyhf5+G2EefRATZ6q03usElADKpdiMShmscWI8z/I0bD9N C7UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dsTH74Uil0PuFEQkt72LkahUimvnULfRquXH4dpbQig=; b=rJa4YQlXedngAbIw6aGOBW6GR7DnqHauCU/BPpyErIIgdGMI8hOXw94qnUCyHo0/Du C16FPbS+hAaJB+eGKpEnr7VD9T/IZUE6TkDeiy878pdcDhwpUxtKtJd2rsBDO/pUyFHx 4WYi9+V6iF0/relRtWM/J7fPcwuYW1NIXLwePtPaARRS1ESHZk5lV4zmWVrC7nLSPY3G wW9PwtUCezLUyrhM+VMHMXrgwJMddePI9uY4C0ot9fOHrn3KaFnHwH69xEyrXUKH8664 xD0Ola1W6RsqczwnwY12Yah1sEe2ek0/6Fr5EVydyI4g/b20MpxyTK0t2Sr1K5mhQSNx MArA==
X-Gm-Message-State: AFeK/H06JlH1eMHyNrpZLZasDMHFCUalaKFpYZUagJNNW+82ki0LLP0Yuk6ETcBgw5npSULg152+bbj84omm+w==
X-Received: by 10.176.64.34 with SMTP id h31mr1233672uad.89.1490817517753; Wed, 29 Mar 2017 12:58:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.181 with HTTP; Wed, 29 Mar 2017 12:58:07 -0700 (PDT)
From: Mark Smith 
Date: Thu, 30 Mar 2017 06:58:07 +1100
Message-ID: 
Subject: Insertion of IPv6 Segment Routing Headers in a Controlled Domain
To: 6man WG 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 19:58:40 -0000

So having further about this, I have fundamental question that it
isn't answering.

Why can't IPv6-in-IPv6 encapsulation be used for this? What is missing
from IPv6 that "requires" that EH insertion is used instead of much
simpler, off-the-shelf encapsulation/decapsulation?



For example, using IPv6-in-IPv6 encapsulation, I don't think an SRH is
needed at all in the "2. Source Domain and Packet Journey" example.

When node 2 realises that the link between itself and 3 has failed, it
encapsulates the original SA=1, DA=9 packet in a new IPv6 header
("tunnelling" it). The new IPv6 header has an SA=2, DA=5, and is sent
towards node 4.

Node 4 forwards the packet onto node 5 using conventional destination
address based IPv6 forwarding.

Node 5 receives the packet, and as it is DA=5, decapsulates the inner
SA=1, DA=9 packet. Node 5 then submits that packet to the standard
IPv6 forwarding table, resulting in it being forwarded to Node 3,
which then forwards it to Node 9. All of this is happening using
conventional IPv6 destination based forwarding.

Encapsulation is solving this problem by effectively creating a
on-demand virtual link or tunnel between Node 2 and Node 5, getting
the original packet past the failure point to a point along the
original packet's forwarding path. Once there, it pops out of the
virtual link and is sent along its way. I don't think the insertion of
the EH and DA swapping method could be described the same way or could
be described as simply.

I think this IP-in-IPv6 encapsulation solution to the above example is
better because:

- there is no need for an additional header of any type - the path
information is inherent in the DA of the outer IPv6 header when sent
to node 5, and in the DA of the inner IPv6 packet (now "the packet")
when being sent by node 5 to node 9.

- Encapsulation/Decapsulation performed by nodes 2 and nodes 5 is
conventional IPv6-in-IPv6 encapsulation, specified in RFC2473, now
nearly 20 years old.

- In this example, nodes 4, 5 and 3 could be off-the-shelf IPv6
devices that support conventional IPv6 forwarding and conventional
IPv6-in-IPv6 encapsulation/decapsulation (i.e., "tunnelling").

- Encapsulation/decapsulation is a simpler, universal and proven
operation (literally being done every time an IPv6 packet is being
sent and received over any and all layer 2 links)  compared to the DA
address swapping that occurs at Nodes 2 and Nodes 5 in the described
method.

More complicated examples would may require more information to be
carried about the path between the inner and outer IPv6 headers
(although encapsulation inside encapsulation/tunnelling inside
tunnelling probably be used at a greater packet overhead host, with
simpler per-hop processing), however I don't think this example
demonstrates why EH insertion is required.


Regards,
Mark.


From nobody Wed Mar 29 13:08:37 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C5812994F for ; Wed, 29 Mar 2017 13:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 000fPmoIuNT4 for ; Wed, 29 Mar 2017 13:08:35 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01281298AF for ; Wed, 29 Mar 2017 13:08:34 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id s68so31309338vke.3 for ; Wed, 29 Mar 2017 13:08:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=peraAjJCR5CdlDti0KHMzxzrFucA/xXTYb2ZTB1nWtw=; b=BpscyPtoEpHfX0SgK4JvmnhktdHVNZ/f6ZFtQwjNRpEwem+qVa14nF59+nK14fe2ce 6T7ftZzOhT/4ym9HsWS4xnzm465uDULtZQbK7kRSDmt2euGRq/+enoRDaP+F2BcbUUJh nF9jlBxSJPTWeF0vQCN41Bf9Ah9elG+FY+tBF6dvCMhf9P+M8mvqHzLtdvFWdRTVrxhn QHhuDJbd5XoD6JfOoRiTP7wXR2nVPWpkQnNNgMM8bZYzt/mmfJ48hjXJ3wpoFrl+vkIu T6+dviuhgjL5cbUFNBml2jYaSx+i5GBGRyQlneS+Ja7aDmZfKc14aicPqjGfzdIRFiRN h1pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=peraAjJCR5CdlDti0KHMzxzrFucA/xXTYb2ZTB1nWtw=; b=fPvqcp91erED8EntYtjADX5QbWXYpA+jU10Yu6/UnSUFCDLpSBbcoQ1iow1uDrQ+g9 Ccvahh/sn5OnGiChGwPRcvBfw8IsDUmtb5HtAPUnGQV6vwsnoSWSIiySDEXbIpu53scJ F8wGa9vzDuVKbgqwvHfrD8Se0eXV5/dyBoGPWcu/7uTT7ZEvKTIUgt/rS3SznakTHV6d 18U177TePOLN4NIREb6aw8wHcFlwGbnez0y+44prKTsZkVD+CAtK+EnfIANOLF2Eaot4 EqxUi+cqKdmlg7fiMPvTpWQ3OJT3G+rmN96BMEzkK1x/xCwr72227XrkYM8eIUGLUkeS /9cw==
X-Gm-Message-State: AFeK/H0RDrTW8CiREyevvcIlz0agtOV04+R4qm80NFD/koQL+Gd4IDvWdfAMXcgAfWa09hj4WuvuEc8ofPRhkg==
X-Received: by 10.159.48.20 with SMTP id h20mr1130144uab.49.1490818113777; Wed, 29 Mar 2017 13:08:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.181 with HTTP; Wed, 29 Mar 2017 13:08:03 -0700 (PDT)
In-Reply-To: 
References: 
From: Mark Smith 
Date: Thu, 30 Mar 2017 07:08:03 +1100
Message-ID: 
Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain
To: 6man WG 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 20:08:36 -0000

On 30 March 2017 at 06:58, Mark Smith  wrote:
> So having further about this, I have fundamental question that it
> isn't answering.
>
> Why can't IPv6-in-IPv6 encapsulation be used for this? What is missing
> from IPv6 that "requires" that EH insertion is used instead of much
> simpler, off-the-shelf encapsulation/decapsulation?
>
>
>
> For example, using IPv6-in-IPv6 encapsulation, I don't think an SRH is
> needed at all in the "2. Source Domain and Packet Journey" example.
>
> When node 2 realises that the link between itself and 3 has failed, it
> encapsulates the original SA=1, DA=9 packet in a new IPv6 header
> ("tunnelling" it). The new IPv6 header has an SA=2, DA=5, and is sent
> towards node 4.
>
> Node 4 forwards the packet onto node 5 using conventional destination
> address based IPv6 forwarding.
>
> Node 5 receives the packet, and as it is DA=5, decapsulates the inner
> SA=1, DA=9 packet. Node 5 then submits that packet to the standard
> IPv6 forwarding table, resulting in it being forwarded to Node 3,
> which then forwards it to Node 9. All of this is happening using
> conventional IPv6 destination based forwarding.
>
> Encapsulation is solving this problem by effectively creating a
> on-demand virtual link or tunnel between Node 2 and Node 5, getting
> the original packet past the failure point to a point along the
> original packet's forwarding path. Once there, it pops out of the
> virtual link and is sent along its way. I don't think the insertion of
> the EH and DA swapping method could be described the same way or could
> be described as simply.
>
> I think this IP-in-IPv6 encapsulation solution to the above example is
> better because:
>
> - there is no need for an additional header of any type - the path
> information is inherent in the DA of the outer IPv6 header when sent
> to node 5, and in the DA of the inner IPv6 packet (now "the packet")
> when being sent by node 5 to node 9.

To clarify, what I mean by "no need for an additional header of any
type" is no additional header beyond the IPv6 encapsulation header
i.e. no SRH EH or similar between the outer and inner IPv6 packets. It
is the original IPv6 packet inside a vanilla IPv6 packet with the
outer IPv6 packet's next header field set to 41.


>
>
> - Encapsulation/Decapsulation performed by nodes 2 and nodes 5 is
> conventional IPv6-in-IPv6 encapsulation, specified in RFC2473, now
> nearly 20 years old.
>
> - In this example, nodes 4, 5 and 3 could be off-the-shelf IPv6
> devices that support conventional IPv6 forwarding and conventional
> IPv6-in-IPv6 encapsulation/decapsulation (i.e., "tunnelling").
>
> - Encapsulation/decapsulation is a simpler, universal and proven
> operation (literally being done every time an IPv6 packet is being
> sent and received over any and all layer 2 links)  compared to the DA
> address swapping that occurs at Nodes 2 and Nodes 5 in the described
> method.
>
> More complicated examples would may require more information to be
> carried about the path between the inner and outer IPv6 headers
> (although encapsulation inside encapsulation/tunnelling inside
> tunnelling probably be used at a greater packet overhead host, with
> simpler per-hop processing), however I don't think this example
> demonstrates why EH insertion is required.
>
>
> Regards,
> Mark.


From nobody Wed Mar 29 13:55:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913581294E7 for ; Wed, 29 Mar 2017 13:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 zWHmgIGosUzT for ; Wed, 29 Mar 2017 13:55:02 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6411812947E for ; Wed, 29 Mar 2017 13:55:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6102; q=dns/txt; s=iport; t=1490820902; x=1492030502; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dJCU+VO9OssotzY3ILnpsCZvI7qzlLK7V3s8YKglv4Q=; b=bJdFpo7ckkUCerTRbwUFk0QNEiDP8uSmSdw3mKbg8xC4U34pzGQf3bDU hFSNwjEpvlqimEUgYidBClM8b9UiZisgQfKi/oV+ICBPP+kaROY5PCDo1 NttovKJhJTaaIwB45uBUn+PHTfhgKdsYO7wDPGiBk1XlFdu26GEut8nYG M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BnAgBDHtxY/4oNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQsHg1uKEZEyH4gYjTaCDh8LhXgCGoMpPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEhEToLBQsCAQgYAgImAgICHwYLFRACBA4FiXIDDQgOrgmCJ?= =?us-ascii?q?ocsDYMfAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VDggUIgmKCUYFggykugjE?= =?us-ascii?q?FiR6TCDoBjheEOJEzim+IegEfOIEEWRVBEQGGRnWGeoEvgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.36,243,1486425600"; d="scan'208";a="404151826"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 20:55:01 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2TKt1ML005395 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 20:55:01 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 16:55:00 -0400
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 16:55:00 -0400
From: "Stefano Previdi (sprevidi)" 
To: Mark Smith 
CC: 6man WG 
Subject: Re: draft-voyer-6man-extension-header-insertion
Thread-Topic: draft-voyer-6man-extension-header-insertion
Thread-Index: AQHSqM675V7Fjd7qhECXJi5+wBz7Kw==
Date: Wed, 29 Mar 2017 20:55:00 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.25.2]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 20:55:04 -0000

DQo+IE9uIE1hciAyOCwgMjAxNywgYXQgMTA6MDcgUE0sIE1hcmsgU21pdGggPG1hcmt6enpzbWl0
aEBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gVGhleSdyZSBtaXNzaW5nIHRoZSBkaWZmZXJlbmNl
IGJldHdlZW4gZW5jYXBzdWxhdGlvbiBhbmQgaW5zZXJ0aW9uLg0KDQoNCm5vdCByZWFsbHk6DQoN
Ci4gYSBwYWNrZXQgaXMgcmVjZWl2ZWQgYXQgaW5ncmVzcyBvZiB0aGUgY29udHJvbGxlZCBkb21h
aW4NCi4gdGhlIHBhY2tldCBpcyBlbmNhcHN1bGF0ZWQgaW50byBhIG5ldyBvdXRlciBpcHY2IGhl
YWRlciB3aGVyZSBTQS9EQSBhcmUgaW50ZXJuYWwgdG8gdGhlIGRvbWFpbi4NCi4gZnJvbSBub3cg
b246DQogICAgLiB0aGlzIHBhY2tldCBpcyBhIHBhY2tldCBzb3VyY2VkIGFuZCBkZXN0aW5lZCB3
aXRoaW4gdGhlIGNvbnRyb2xsZWQgZG9tYWluLg0KICAgIC4gdGhlIG9yaWdpbmFsIHBhY2tldCBp
cyBlbmNhcHN1bGF0ZWQgYW5kIHdpbGwgcmVtYWluIHVudG91Y2hlZC91bm1vZGlmaWVkIChpLmUu
LCBub3Rpbmcgd2lsbCBiZSBpbnNlcnRlZCBpbnRvIHRoZSBvcmlnaW5hbCBwYWNrZXQpLg0KLiBh
IHBhY2tldCBzb3VyY2VkIGFuZCBkZXN0aW5lZCBpbnRlcm5hbGx5IGluIHRoZSBjb250cm9sbGVk
IGRvbWFpbiBjYW4gc2FmZWx5IGJlIGluY3JlYXNlZCBpbiBpdHMgc2l6ZSBhbmQgY2FuIGJlIHNh
ZmVseSBoYXZlIEVIcyBpbnNlcnRlZCBieSB0cmFuc2l0IG5vZGVzLg0KLiB3aGVuIHRoZSBwYWNr
ZXQgcmVhY2hlcyB0aGUgZWdyZXNzIG5vZGUgb2YgdGhlIGNvbnRyb2xsZWQgZG9tYWluLCB0aGUg
b3V0ZXIgZW5jYXBzdWxhdGlvbiBhbmQgYW55IGluc2VydGVkIEVIIGFyZSByZW1vdmVkLiBJT1cs
IHRoZSBwYWNrZXQgdGhhdCBsZWF2ZXMgdGhlIGRvbWFpbiBpcyBleGFjdGx5IHRoZSBzYW1lIHBh
Y2tldCB0aGF0IGVudGVyZWQgdGhlIGRvbWFpbi4NCi4gdGhlIHNpemUgb2YgdGhlIHBhY2tldCBp
bmNyZWFzZWQgaW5zaWRlIHRoZSBkb21haW4gZHVlIHRvIGVuY2Fwc3VsYXRpb24gb2YgY291cnNl
IGJ1dCBhbHNvIGR1ZSB0byBFSCBpbnNlcnRpb24gd2hpbGUgaW4gdHJhbnNpdCBpbiB0aGUgZG9t
YWluLiBUaGUgTVRVIHByb2JsZW0gZG9lc27igJl0IGV4aXN0IGluIHJlYWxpdHkgYmVjYXVzZSB0
aGUgTVRVIG9mIGludGVyZmFjZXMgaW4gdGhlIGNvbnRyb2xsZWQgZG9tYWluIGlzIHJvdWdobHkg
NCB0aW1lcyB3aGF0IGlzIGF0IHRoZSBpbmdyZXNzLg0KLiB0aGUgcG9pbnQgb2YgdGhlIGRyYWZ0
IGlzIHRvIHNheSB0aGF0IGlmIHRoZSBwYWNrZXQgaXMgc291cmNlZCBhbmQgZGVzdGluZWQgd2l0
aGluIGEgY29udHJvbGxlZCBkb21haW4sIGl0IGlzIHNhZmUgdG8gYWxsb3cgaW5zZXJ0aW9uIG9m
IEVIcyBieSB0cmFuc2l0IG5vZGVzLg0KDQpvbmNlIGFnYWluOiB0aGUgRUggaW5zZXJ0aW9uIGhh
cHBlbnMgaW50byB0aGUgb3V0ZXIgaGVhZGVyLCBub3QgaW50byB0aGUgb3JpZ2luYWwgcGFja2V0
Lg0KDQo+IA0KPiBUaGUgaW5jcmVhc2UgYW5kIGRlY3JlYXNlIGluICJwYWNrZXQiIHNpemUgdGhh
dCBpcyBvY2N1cnJpbmcgaW4gdGhlaXINCj4gNlBFIGV4YW1wbGUgaXMgYXMgdGhlIFBEVSBjcm9z
c2VzIGxheWVyIGJvdW5kYXJpZXMgZHVlIHRvDQo+IGVuY2Fwc3VsYXRpb24gb3IgZGVjYXBzdWxh
dGlvbi4gVGhpcyBpcyBvY2N1cnJpbmcgYXMgdGhlIFBEVSB0cmF2ZWxzDQo+IHZlcnRpY2FsbHkg
YmV0d2VlbiBsYXllcnMuIEZyb20gdGhlIElQdjYgcGVyc3BlY3RpdmUsIHRoZSA2UEUgbGF5ZXIg
aXMNCj4gYSBsaW5rIGxheWVyIGJlbG93IHRoZSBuZXR3b3JrIGxheWVyLg0KDQoNCnRoZSBleGFt
cGxlIG9mIDZwZSBvdXRsaW5lcyB0aGUgZmFjdCB0aGF0IHRoZSBwYWNrZXQsIHdoaWxlIHRyYW5z
aXRpbmcgd2l0aGluIGEgZG9tYWluLCBjYW4gIGluY3JlYXNlIGluIGl0cyBzaXplIGR1ZSB0byBs
YWJlbCBzdGFjayBiZWluZyBwdXNoZWQuDQoNCg0KPiBXaGlsZSB0aGUgSVB2NiBwYWNrZXQgdHJh
dmVyc2VzIHRoZSA2UEUgZG9tYWluLCB0aGUgSVB2NidzIHBhY2tldCBzaXplDQo+IGFuZCBzdHJ1
Y3R1cmUgaXMgbm90IGNoYW5nZWQgaW4gYW55IHdheS4NCg0KDQp0aGUgc2FtZSBpcyBpbiBvdXIg
YXBwcm9hY2g6DQoNCi4gdGhlIG9yaWdpbmFsIHBhY2tldCBpcyBlbmNhcHN1bGF0ZWQgaW50byBh
biBvdXRlciBoZWFkZXIgYW5kIGl0cyBzaXplIHdpbGwgbm90IGNoYW5nZS4NCi4gdGhlIGVuY2Fw
c3VsYXRpbmcgcGFja2V0IHdpbGwgZ2V0IEVIIGluc2VydGVkLg0KDQoNCj4gRUggaW5zZXJ0aW9u
IGlzIGluY3JlYXNpbmcgdGhlIFBEVSBzaXplIGFuZCBjaGFuZ2luZyB0aGUgcGFja2V0DQo+IHN0
cnVjdHVyZSB3aGlsZSB0aGUgcGFja2V0IHRyYXZlbHMgaG9yaXpvbnRhbGx5IHdpdGhpbiB0aGUg
SVB2NiBsYXllci4NCj4gVGhhdCB3aWxsIGJyZWFrIHRoaW5ncyBpZiB0aGUgZGVzdGluYXRpb24g
aG9zdCBkb2Vzbid0IGV4cGVjdCB0aGUNCj4gcGFja2V0IHNpemUgb3Igc3RydWN0dXJlIHRvIGNo
YW5nZSwgYW5kIHRoZXkgZG9uJ3QsIGJlY2F1c2UgaXQgaXMgbm90DQo+IGEgZGVzY3JpYmVkICJ3
aXRoaW4gbGF5ZXIiIHBhY2tldCBwcm9jZXNzaW5nIGJlaGF2aW91ciBpbiBSRkMyNDYwLiBUaGUN
Cj4gZGVzdGluYXRpb24gaG9zdCBleHBlY3RzIHRoYXQgdGhlIHBhY2tldCByZWNlaXZlZCBoYXMg
YSBzdHJ1Y3R1cmUgYW5kDQo+IHNpemUgdGhhdCBpcyB0aGUgc2FtZSBhcyBzZW50IGJ5IHRoZSBk
ZXZpY2UgaWRlbnRpZmllZCBpbiB0aGUgc291cmNlDQo+IGFkZHJlc3MgZmllbGQsIHdoaWNoIGlz
IHRoZSBob3N0IHRoYXQgb3JpZ2luYXRlZCB0aGUgcGFja2V0Lg0KPiANCj4gRUggaW5zZXJ0aW9u
IG1ha2VzIHRoZSBzb3VyY2UgYWRkcmVzcyBmaWVsZCBib3RoIG1lYW5pbmdsZXNzIGFuZA0KPiBo
b2xkaW5nIGFuIGluY29ycmVjdCB2YWx1ZSB3aGlsZSB0aGUgaW5zZXJ0ZWQgRUggaXMgcHJlc2Vu
dC4NCg0KDQpub3QgcmVhbGx5Og0KLiB0aGUgU0EgaXMgdW50b3VjaGVkIGJ5IHRoZSBFSCBpbnNl
cnRpb24uIFRoZSBTQSBpcyB0aGUgYWRkcmVzcyBvZiB0aGUgaW5ncmVzcyBub2RlIG9mIHRoZSBj
b250cm9sbGVkIGRvbWFpbi4NCi4gdGhlIERBIGlzIHVwZGF0ZWQgd2l0aCB0aGUgZmlyc3Qgc2Vn
bWVudCBvZiB0aGUgRUggKHdlIGFzc3VtZSB0aGUgaW5zZXJ0ZWQgRUggaXMgdGhlIFNSSCkuDQou
IHRoZSBEQSBpcyB1cGRhdGVkIGF0IGVhY2ggc2VnbWVudA0KDQoNCj4gQQ0KPiBzcGVjaWZpY2F0
aW9uIGZvciBFSCBpbnNlcnRpb24gd291bGQgbmVlZCB0byBzdGF0ZSB0aGlzIHZlcnkgY2xlYXJs
eS4NCj4gTWFueSBvZiB0aGUgbmVnYXRpdmUgY29uc2VxdWVuY2VzIG9mIEVIIGluc2VydGlvbiBh
cmUgYmVjYXVzZSBpdCBtYWtlcw0KPiB0aGUgcGFja2V0J3Mgc291cmNlIGFkZHJlc3MgZmllbGQg
bWVhbmluZ2xlc3MgYW5kIGhvbGRpbmcgYSBpbmNvcnJlY3QNCj4gdmFsdWUuDQoNCg0KYWdhaW4s
IG5vdCByZWFsbHkgaW4gdGhpcyBjYXNlOiB0aGUgU0EgaXMgdW50b3VjaGVkIGFuZCBpdCByZXBy
ZXNlbnRzIHRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIGNvbnRyb2xsZWQgZG9tYWluLg0KDQoNCj4g
VGhlIG9ubHkgdGhpbmdzIHRoYXQgYXJlIHBlcm1pdHRlZCB0byBjaGFuZ2Ugd2hpbGUgYW4gSVB2
NiBwYWNrZXQgaXMNCj4gaW4gZmxpZ2h0ICh3aXRoaW4gdGhlIElQdjYgbGF5ZXIpIGFyZSB2YWx1
ZXMgb2YgYSBkZWZpbmVkIHNldCBvZg0KPiBmaWVsZHMgc3BlY2lmaWVkIGluIFJGQzI0NjAgZS5n
LiwgaG9wIGxpbWl0LCBmbG93IGxhYmVsLCB0cmFmZmljDQo+IGNsYXNzLiBPbmx5IGZpZWxkIHZh
bHVlcyBjaGFuZ2UsIG5vIGZpZWxkcyBhcmUgYWRkZWQgb3IgcmVtb3ZlZCAtIHRoZQ0KPiBwYWNr
ZXQncyBzdHJ1Y3R1cmUgYW5kIHNpemUgc3RheXMgdGhlIHNhbWUgYWZ0ZXIgdGhlc2UgbW9kaWZp
Y2F0aW9ucw0KPiBpZiBvciB3aGVuIHRoZXkgb2NjdXIuDQoNCg0KSSB1bmRlcnN0YW5kIHdoYXQg
cmZjMjQ2MCBzcGVjaWZpZWQgYW5kIHRoZSByZWFzb24gb2Ygb3VyIGRyYWZ0IGlzIHRvIGV4cGxh
aW4gdGhhdCB0aGluZ3MgaGF2ZSBjaGFuZ2VkIGluIHRoZSBsYXN0IDIwIHllYXJzIGFuZCB3ZSBz
aG91bGQgdGFrZSB0aGVtIGludG8gY29uc2lkZXJhdGlvbi4NCg0Kcy4NCg0KDQo+IA0KPiANCj4g
UmVnYXJkcywNCj4gTWFyay4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5n
IGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJl
cXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCg0K


From nobody Wed Mar 29 13:55:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427A112998C for ; Wed, 29 Mar 2017 13:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 9BknGZVdmIqJ for ; Wed, 29 Mar 2017 13:55:27 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD95612947E for ; Wed, 29 Mar 2017 13:55:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2292; q=dns/txt; s=iport; t=1490820927; x=1492030527; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tPP+nvq/ZQsXXlq7ErGHH725xTvxWqmPa+JSl1Kksqc=; b=cGae2hRvlVKjdur/adNaxDe5VfvNuN/yGNyhdSjH/mh/F2JA30GzMeR9 Ntk3wbwsxduFinVJSfnYaZAZvCc4N0AkUw5juQNeioYdXXWBeZg/9MVww st9Kge4rP/6xBKsFntLATgVe5XiTK2fhROuSo4d4dnMQel/2L7Ujqqsmr M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAQBDHtxY/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQsHg1uKEZFRiBiNNoIOHwuFeAIagyk/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBASEROgsFCwIBCBgCAiYCAgIfBgsVEAIEDgUUiV4DDQgOrgmCJ?= =?us-ascii?q?ocsDYMfAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VDggWCaoJRggODBi6CMQW?= =?us-ascii?q?JHpMIOgGOF4Q4kTOKb4h6AR84gQRZFUERAYRGHYFjdQGIKIENAQEB?=
X-IronPort-AV: E=Sophos;i="5.36,243,1486425600"; d="scan'208";a="401890504"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2017 20:55:26 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2TKtQtg012033 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 20:55:26 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 16:55:25 -0400
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 16:55:25 -0400
From: "Stefano Previdi (sprevidi)" 
To: Brian E Carpenter 
CC: 6man 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Topic: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Index: AQHSqM7Klsyj10Ynt0KNZ6KXOrb2BQ==
Date: Wed, 29 Mar 2017 20:55:25 +0000
Message-ID: <433FDB25-C4B8-4F73-9EAF-FE2699D02E86@cisco.com>
References: <149072338991.1228.10342495694037829468@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.25.2]
Content-Type: text/plain; charset="utf-8"
Content-ID: <28B58DFAB3BF5F4386A64E866E925F91@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 20:55:37 -0000

DQo+IE9uIE1hciAyOCwgMjAxNywgYXQgODoxOCBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFu
LmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIb25lc3RseSwgdGhpcyBpbXBy
ZXNzZXMgbm9ib2R5Og0KDQoNCmhvbmVzdGx5LCB0aGUgZ29hbCB3YXMgbm90IHRvIGltcHJlc3Mg
eW91IG9yIGFueW9uZSBlbHNlLg0KDQpIYXZpbmcgc2FpZCB0aGF0LCBJ4oCZbSBzdXJlIHlvdSBh
Y2tub3dsZWRnZSB0aGUgZmFjdCB0aGF0IHRoZSBwZW9wbGUgaGVyZSBiZWxvdyBkZXNlcnZlIHRo
ZSBleHBlY3RlZCByZXNwZWN0IGZyb20gdGhpcyBjb21tdW5pdHkgZHVlIHRvIHRoZSBlZmZvcnQg
dGhleSBwdXQgaW50byB0aGUgd3JpdGluZyBvZjoNCg0KZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQt
cm91dGluZy1oZWFkZXINCmRyYWZ0LXZveWVyLTZtYW4tZXh0ZW5zaW9uLWhlYWRlci1pbnNlcnRp
b24NCmRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcNCmRyYWZ0
LWJhc2hhbmR5LWlzaXMtc3J2Ni1leHRlbnNpb25zDQoNCmFuZCBpbnRvIHRoZSB3cml0aW5nIG9m
IG11bHRpLXZlbmRvciBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4NCg0KVGhhbmtzLg0K
cy4NCg0KDQoNCj4gDQo+PiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRGFuaWVsIFZveWVyDQo+
PiAgICAgICAgICAgICAgICAgICAgICAgICAgRGFuaWVsIEJlcm5pZXINCj4+ICAgICAgICAgICAg
ICAgICAgICAgICAgICBKb2huIExlZGR5DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgQ2xh
cmVuY2UgRmlsc2ZpbHMNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVmYW5vIFByZXZp
ZGkNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVmYW5vIFNhbHNhbm8NCj4+ICAgICAg
ICAgICAgICAgICAgICAgICAgICBBbnRvbmlvIENpYW5mcmFuaQ0KPj4gICAgICAgICAgICAgICAg
ICAgICAgICAgIERhdmlkIExlYnJ1bg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgIE9saXZp
ZXIgQm9uYXZlbnR1cmUNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBQcmVtIEpvbm5hbGFn
YWRkYQ0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgIE1pbGFkIFNoYXJpZg0KPj4gICAgICAg
ICAgICAgICAgICAgICAgICAgIEhhbmkgRWxtYWxreQ0KPj4gICAgICAgICAgICAgICAgICAgICAg
ICAgIEFobWVkIEFiZGVsc2FsYW0NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBSb2JlcnQg
UmFzenVrDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgQXJ0aGkgQXl5YW5nYXINCj4+ICAg
ICAgICAgICAgICAgICAgICAgICAgICBEaXJrIFN0ZWluYmVyZw0KPj4gICAgICAgICAgICAgICAg
ICAgICAgICAgIFdpbSBIZW5kZXJpY2t4DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYg
d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJh
dGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2
DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQoNCg==


From nobody Wed Mar 29 13:55:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6821129998 for ; Wed, 29 Mar 2017 13:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 FJnWK-YIGHBn for ; Wed, 29 Mar 2017 13:55:45 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F314A129997 for ; Wed, 29 Mar 2017 13:55:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1028; q=dns/txt; s=iport; t=1490820941; x=1492030541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EH2TzkWBFdoHS4SQiO5kvPLKxbCh3VMHpgGkYrClq1I=; b=eKt7QLeOBlXp8C/gdCu0a+lr5CIbage59sLrqqzscsO/IB00lzsD7fqL G3uNaB6d/VRq0EUQUrLpo5W4qtafrRprpOpL5OUaj5r4imDXyyIouPHhT kgTSqtnf0MVe7nbo7gsosE58CmZkwvWvctray+9ZnfgpIHZhprKyQ6gru U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBDHtxY/4oNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQsHjWyRUYgYjTaCDh8LhXgCg0M/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEBATg0CwULAgEIGB4QIQYLJQIEDgWJcgMNCA6wL4csDYMfAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWGToIFgmqCUYIDgzSCMQWJHpMIOgGOF4Q4kTOKb4h?= =?us-ascii?q?6AR84gQRZFUERAYZGdQGIKIENAQEB?=
X-IronPort-AV: E=Sophos;i="5.36,243,1486425600"; d="scan'208";a="400952295"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 20:55:41 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2TKteYC006184 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 20:55:41 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 16:55:40 -0400
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 16:55:40 -0400
From: "Stefano Previdi (sprevidi)" 
To: Brian E Carpenter 
CC: 6man 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Topic: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Index: AQHSqM7SUZfBCPQnO06Tpecxh2xZ8Q==
Date: Wed, 29 Mar 2017 20:55:40 +0000
Message-ID: 
References: <149072338991.1228.10342495694037829468@ietfa.amsl.com> <0667344d-ad0c-2e7c-2e67-be913d5293ca@gmail.com>
In-Reply-To: <0667344d-ad0c-2e7c-2e67-be913d5293ca@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.25.2]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1D49C62261164F43B55CB8AE1ADD6285@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 20:55:53 -0000

> On Mar 28, 2017, at 8:28 PM, Brian E Carpenter  wrote:
>=20
>> Hence, a context-less ban of
>> IPv6 extension header insertion does not make sense.
>=20
> RFC2460bis isn't contextless. The context is the Internet and therefore
> the requirements for interoperable communication between any two nodes on
> the Internet. I don't see any conflict between that and a additional
> specification for local use of a feature that does not meet those require=
ments.


since we are in the process of updating rfc2460, your statement above could=
 easily be inserted into rfc2460bis.

s.

=20
>=20
> I think this draft would be much easier to consider without that sort
> of phrasing.
>=20
>    Brian
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Wed Mar 29 13:58:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B4C126DDF for ; Wed, 29 Mar 2017 13:58:54 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LPb-8Cvmd53D for ; Wed, 29 Mar 2017 13:58:51 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6697212944C for ; Wed, 29 Mar 2017 13:58:51 -0700 (PDT)
Received: from [192.168.178.240] (52D961A6.cm-11-1b.dynamic.ziggo.nl [82.217.97.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3A70F80146; Wed, 29 Mar 2017 22:58:49 +0200 (CEST)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
To: Tim Chown , "C. M. Heard" 
References:  <59B02E00-136D-4DDB-8707-F2DA61D4D3EA@jisc.ac.uk>
Cc: 6man WG 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Wed, 29 Mar 2017 22:57:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <59B02E00-136D-4DDB-8707-F2DA61D4D3EA@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 20:58:55 -0000

On 03/29/2017 05:33 PM, Tim Chown wrote:
> Hi,
> 
>> On 29 Mar 2017, at 03:42, C. M. Heard  wrote:
>>
>> On Wed, 29 Mar 2017 07:28:32 +1300 Brian E Carpenter wrote:
[....]
>>>
>>> I think this draft would be much easier to consider without that sort
>>> of phrasing.
>>
>> Agreed, and in the same vein, I think that the draft would be more credible
>> if the first sentence of the abstract were changed along the following lines:
>>
>> OLD:
>>   The network operator and vendor community has clearly indicated that
>>   IPv6 header insertion is useful and required.
>>
>> NEW:
>>   Certain segments of the network operator and vendor community have
>>   clearly indicated that IPv6 header insertion is useful and required
>>   for their purposes.
> 
> Well, I think if this document is to be adopted, it should start by saying clearly why EH “insertion†by encapsulation as per RFC2460-bis isn’t sufficient in specific scenarios.

As far as I understand, this doc is essentially making an argument
against the decision taken for rfc2460bis.

Since that ship has already sailed, I'm not sure whether it could be
adopted "as is".

Rather, it should probably make a case for updating RFCXXXX (whatever
number rfc2460bis receives).

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Mar 29 14:02:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C0212997C for ; Wed, 29 Mar 2017 14:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 rYYCX5uRHhfl for ; Wed, 29 Mar 2017 14:02:36 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD61129985 for ; Wed, 29 Mar 2017 14:02:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490821351; bh=um+HLP5W9Ng6uaZOVIcXUjsO8LValvL+rLqh2hG6654=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IhF9SQTkM0qjMmC/cRG6f9rpyq8xomqKsK2ckbc/FVdbgbS2y3HzjmeDsiP2vyvSC9ubNZc/fz9l/usBga92xkY0doWrmx/RPuM/Iu076ol9PzHHKkPPfQvlOmfVscfEqxKwYIIs4tYPfkSKJ0q2u2+6m+kYX7/Y26ak7QlxNXc=
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0242.outbound.protection.outlook.com [213.199.154.242]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-19-UldMCpXSMFegCriqEoiMgg-1; Wed, 29 Mar 2017 22:02:29 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 21:02:28 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::59f7:b9fe:6ca:9476%14]) with mapi id 15.01.1005.014; Wed, 29 Mar 2017 21:02:28 +0000
From: Tim Chown 
To: Fernando Gont 
CC: "C. M. Heard" , 6man WG 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Topic: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Index: AQHSqDYfWTtpVnOTu0uiU6CsaQBgZaGr8y2AgABarACAAAFEAA==
Date: Wed, 29 Mar 2017 21:02:27 +0000
Message-ID: <4F96EC34-4F80-4D4E-8070-44A14CE19493@jisc.ac.uk>
References:  <59B02E00-136D-4DDB-8707-F2DA61D4D3EA@jisc.ac.uk> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:67c:370:128:cd68:e80a:a15e:9093]
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:aFkzSY8+uLjpnZcspW4tyNV9Epnk8ha1qKqbQaJITmGaiTdvxNydSrc2CvpzL3Z3km39kkSmhY0nKhej2m6b9JVvZFFKpD6yZeJPZeO1s3vWriJy3LNcVJTPNSZjVlkhq1w40yvGfwC/BQ9umyIS/l2Hz79tDjUUdKJiAoRR9clGcJocZ8ThLfW7MPX9Q86bgi0Ql6OJpLvrlkupml/4hdtGxXApRdUfO3XWuLj229F1Z8lkk2SNpavAa41BAlq75GYmQCZmwEhoNmAXRCQYrwJzfUGinRriwn7PssiSJHpaP5+DbMQpjzZXufqMsScsyxGI8/eleo57bRJJHMjq0g==; 20:s/zg/TMSOQyewMPEOYo1PKUorNmMyVHCH/1IRNPk7plRcJCvmJu6//ou/uRnphapBnLZlzgJPmicQllz6InJ22kC2siOro8Uy9cMebhe70zPECcfdUBt5t8h7ZoR+5OjvQMWOR9JDRECSzdcjGfof9ZVGcqQ8AOJUITCP891w+0=
x-ms-office365-filtering-correlation-id: 447c1db0-b9c9-410a-2d58-08d476e6e87c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1138; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100324003535756);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006050)(93001050)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; 
x-forefront-prvs: 0261CCEEDF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39850400002)(39410400002)(39400400002)(24454002)(377454003)(2900100001)(8676002)(38730400002)(57306001)(5250100002)(53546009)(6246003)(25786009)(6916009)(50986999)(2950100002)(42882006)(76176999)(7736002)(50226002)(5660300001)(86362001)(189998001)(8936002)(81166006)(305945005)(74482002)(4326008)(2906002)(99286003)(6512007)(83716003)(6506006)(82746002)(33656002)(102836003)(36756003)(6486002)(3280700002)(54906002)(6436002)(230783001)(3660700001)(8656002)(229853002)(53936002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: 
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 21:02:27.9178 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138
X-MC-Unique: UldMCpXSMFegCriqEoiMgg-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 21:02:39 -0000

PiBPbiAyOSBNYXIgMjAxNywgYXQgMjE6NTcsIEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdv
cmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwMy8yOS8yMDE3IDA1OjMzIFBNLCBUaW0gQ2hvd24g
d3JvdGU6DQo+PiBIaSwNCj4+IA0KPj4+IE9uIDI5IE1hciAyMDE3LCBhdCAwMzo0MiwgQy4gTS4g
SGVhcmQgPGhlYXJkQHBvYm94LmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gT24gV2VkLCAyOSBNYXIg
MjAxNyAwNzoyODozMiArMTMwMCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gWy4uLi5dDQo+
Pj4+IA0KPj4+PiBJIHRoaW5rIHRoaXMgZHJhZnQgd291bGQgYmUgbXVjaCBlYXNpZXIgdG8gY29u
c2lkZXIgd2l0aG91dCB0aGF0IHNvcnQNCj4+Pj4gb2YgcGhyYXNpbmcuDQo+Pj4gDQo+Pj4gQWdy
ZWVkLCBhbmQgaW4gdGhlIHNhbWUgdmVpbiwgSSB0aGluayB0aGF0IHRoZSBkcmFmdCB3b3VsZCBi
ZSBtb3JlIGNyZWRpYmxlDQo+Pj4gaWYgdGhlIGZpcnN0IHNlbnRlbmNlIG9mIHRoZSBhYnN0cmFj
dCB3ZXJlIGNoYW5nZWQgYWxvbmcgdGhlIGZvbGxvd2luZyBsaW5lczoNCj4+PiANCj4+PiBPTEQ6
DQo+Pj4gIFRoZSBuZXR3b3JrIG9wZXJhdG9yIGFuZCB2ZW5kb3IgY29tbXVuaXR5IGhhcyBjbGVh
cmx5IGluZGljYXRlZCB0aGF0DQo+Pj4gIElQdjYgaGVhZGVyIGluc2VydGlvbiBpcyB1c2VmdWwg
YW5kIHJlcXVpcmVkLg0KPj4+IA0KPj4+IE5FVzoNCj4+PiAgQ2VydGFpbiBzZWdtZW50cyBvZiB0
aGUgbmV0d29yayBvcGVyYXRvciBhbmQgdmVuZG9yIGNvbW11bml0eSBoYXZlDQo+Pj4gIGNsZWFy
bHkgaW5kaWNhdGVkIHRoYXQgSVB2NiBoZWFkZXIgaW5zZXJ0aW9uIGlzIHVzZWZ1bCBhbmQgcmVx
dWlyZWQNCj4+PiAgZm9yIHRoZWlyIHB1cnBvc2VzLg0KPj4gDQo+PiBXZWxsLCBJIHRoaW5rIGlm
IHRoaXMgZG9jdW1lbnQgaXMgdG8gYmUgYWRvcHRlZCwgaXQgc2hvdWxkIHN0YXJ0IGJ5IHNheWlu
ZyBjbGVhcmx5IHdoeSBFSCDigJxpbnNlcnRpb27igJ0gYnkgZW5jYXBzdWxhdGlvbiBhcyBwZXIg
UkZDMjQ2MC1iaXMgaXNu4oCZdCBzdWZmaWNpZW50IGluIHNwZWNpZmljIHNjZW5hcmlvcy4NCj4g
DQo+IEFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoaXMgZG9jIGlzIGVzc2VudGlhbGx5IG1ha2lu
ZyBhbiBhcmd1bWVudA0KPiBhZ2FpbnN0IHRoZSBkZWNpc2lvbiB0YWtlbiBmb3IgcmZjMjQ2MGJp
cy4NCj4gDQo+IFNpbmNlIHRoYXQgc2hpcCBoYXMgYWxyZWFkeSBzYWlsZWQsIEknbSBub3Qgc3Vy
ZSB3aGV0aGVyIGl0IGNvdWxkIGJlDQo+IGFkb3B0ZWQgImFzIGlzIi4NCj4gDQo+IFJhdGhlciwg
aXQgc2hvdWxkIHByb2JhYmx5IG1ha2UgYSBjYXNlIGZvciB1cGRhdGluZyBSRkNYWFhYICh3aGF0
ZXZlcg0KPiBudW1iZXIgcmZjMjQ2MGJpcyByZWNlaXZlcykuDQoNClRoYXQgd2FzIG15IHVuZGVy
c3RhbmRpbmcgb2Ygd2hhdCBoYXMgYmVlbiBwcmV2aW91c2x5IHNhaWQuDQoNClRoZSBkcmFmdCB3
b3VsZCBuZWVkIChhcyBNYXJrIGFsc28gc2FpZCBpbiBhbm90aGVyIHRocmVhZCkgZXhwbGFpbiB3
aHkgZW5jYXBzdWxhdGVkIGlzbuKAmXQgc3VmZmljaWVudCwgYW5kIHRoZW4gc3VjY2Vzc2Z1bGx5
IGRlc2NyaWJlIGhvdyBkaXJlY3QgRUggaW5zZXJ0aW9uIGNhbiBiZSBkb25lIHNhZmVseSBpbiBz
cGVjaWZpYyBjb25kaXRpb25zLg0KDQpUaW0=


From nobody Wed Mar 29 14:17:20 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2FA129488 for ; Wed, 29 Mar 2017 14:17:19 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vLeBRzRp52Y2 for ; Wed, 29 Mar 2017 14:17:16 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93783129440 for ; Wed, 29 Mar 2017 14:17:16 -0700 (PDT)
Received: from [192.168.178.240] (52D961A6.cm-11-1b.dynamic.ziggo.nl [82.217.97.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2145480101; Wed, 29 Mar 2017 23:17:11 +0200 (CEST)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
To: "Stefano Previdi (sprevidi)" , Brian E Carpenter 
References: <149072338991.1228.10342495694037829468@ietfa.amsl.com> <0667344d-ad0c-2e7c-2e67-be913d5293ca@gmail.com> 
Cc: 6man 
From: Fernando Gont 
Message-ID: <421c7422-c03e-a2ed-aa3c-b557da814871@si6networks.com>
Date: Wed, 29 Mar 2017 23:02:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 21:17:19 -0000

On 03/29/2017 10:55 PM, Stefano Previdi (sprevidi) wrote:
> 
>> On Mar 28, 2017, at 8:28 PM, Brian E Carpenter  wrote:
>>
>>> Hence, a context-less ban of
>>> IPv6 extension header insertion does not make sense.
>>
>> RFC2460bis isn't contextless. The context is the Internet and therefore
>> the requirements for interoperable communication between any two nodes on
>> the Internet. I don't see any conflict between that and a additional
>> specification for local use of a feature that does not meet those requirements.
> 
> 
> since we are in the process of updating rfc2460, your statement above could easily be inserted into rfc2460bis.

My understanding is that that ship has already sailed (IETF LC ended a
while ago).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Mar 29 14:54:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978851250B8 for ; Wed, 29 Mar 2017 14:54:42 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 M2ObxF7Z1M7P for ; Wed, 29 Mar 2017 14:54:40 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAC312948E for ; Wed, 29 Mar 2017 14:54:39 -0700 (PDT)
Received: from [192.168.178.240] (52D961A6.cm-11-1b.dynamic.ziggo.nl [82.217.97.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9F10980212; Wed, 29 Mar 2017 23:54:37 +0200 (CEST)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
To: Tim Chown 
References:  <59B02E00-136D-4DDB-8707-F2DA61D4D3EA@jisc.ac.uk>  <4F96EC34-4F80-4D4E-8070-44A14CE19493@jisc.ac.uk>
Cc: "C. M. Heard" , 6man WG 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Wed, 29 Mar 2017 23:22:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <4F96EC34-4F80-4D4E-8070-44A14CE19493@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Mar 2017 21:54:43 -0000

On 03/29/2017 11:02 PM, Tim Chown wrote:
>>> 
>>> Well, I think if this document is to be adopted, it should start
>>> by saying clearly why EH “insertion†by encapsulation as per
>>> RFC2460-bis isn’t sufficient in specific scenarios.
>> 
>> As far as I understand, this doc is essentially making an argument 
>> against the decision taken for rfc2460bis.
>> 
>> Since that ship has already sailed, I'm not sure whether it could
>> be adopted "as is".
>> 
>> Rather, it should probably make a case for updating RFCXXXX
>> (whatever number rfc2460bis receives).
> 
> That was my understanding of what has been previously said.
> 
> The draft would need (as Mark also said in another thread) explain
> why encapsulated isn’t sufficient, and then successfully describe how
> direct EH insertion can be done safely in specific conditions.

Agreed. And the text be phrased as an update to RFCXXXX (rfc2460bis),
rather than about the decision that has already been taken for
rfc2460bis. -- Otherwise, the I-D looks like tryig to reopen discussion,
when the ship has already sailed.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Mar 29 18:39:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F49127444 for ; Wed, 29 Mar 2017 18:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level: 
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 epw83Umhz_NO for ; Wed, 29 Mar 2017 18:39:45 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3479126E3A for ; Wed, 29 Mar 2017 18:39:44 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2U1dgle124103 for ; Thu, 30 Mar 2017 03:39:42 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9E0DF20100A for ; Thu, 30 Mar 2017 03:39:42 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 94E90200CFF for ; Thu, 30 Mar 2017 03:39:42 +0200 (CEST)
Received: from [132.166.84.22] ([132.166.84.22]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2U1dfUe003431 for ; Thu, 30 Mar 2017 03:39:42 +0200
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: ipv6@ietf.org
References: <20170223134026.GI5069@gir.theapt.org>  <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>           <1b6154d2-14a7-0d85-7a81-18a5367c03 30@gmail.com> <33465746-86AA-4F1E-974F-63208A6928AA@thehobsons.co.uk>
From: Alexandre Petrescu 
Message-ID: 
Date: Wed, 29 Mar 2017 20:39:27 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <33465746-86AA-4F1E-974F-63208A6928AA@thehobsons.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 01:39:47 -0000

Le 28/03/2017 à 08:19, Simon Hobson a écrit :
> Alexandre Petrescu  wrote:
[...]
>>> But to be frank, I still can't see what the proposal is about -
>>> just what use case does it solve ?
>>
>> Well, the discussion is issued from the following observations: -
>> rfc4291bis calls it fe80::/10 with a 64bit IID, whereas rfc2464bis
>>  calls it fe80::/64 - which is right?
>
> Right, so this is really nothing about using masks, prefix notation,
> etc - it's purely that somewhere along the line there's been an
> inconsistency in definition. One definition says one thing, another
> says something else. By one definition, fe81:: is a
> link local address, while by another definition it isn't.

I tend to agree, but I think others think otherwise.

I think some people think that fe80::/64 is right whereas others think 
that fe80::/10 is right.

> I would suggest that the way to deal with that is to discuss which is
> correct and have one or both RFCs updated so they say the same thing.

I agree.

> Unless there's something in the context that makes them both right.

What is that?

> Given that there are implementations "in the wild" relying on
> fe80::/64, it might be hard to settle on the wider
> ranging definition and accept that the rest of fe80::/10 is
> effectively lost to other uses - having been lost in the gap between
> the definitions.

The BSD code that was shown earlier checks the src of a received ND 
packet against fe80::/10 (not against fe80::/64).

And other code in same OS BSD adds fe80::/64 (not fe80::/10) in the rt 
table.

Because of this there can be problems.

Alex

>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


From nobody Wed Mar 29 19:29:59 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4A12949A for ; Wed, 29 Mar 2017 19:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.402
X-Spam-Level: 
X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4li3CB1jhMdA for ; Wed, 29 Mar 2017 19:29:56 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2274612871F for ; Wed, 29 Mar 2017 19:29:56 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id r142so29173664qke.2 for ; Wed, 29 Mar 2017 19:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:from:date:message-id:subject:to:cc; bh=CnnQUOYhxSnjihor24GOeM8jvU8sHECS3MWHo0dXQeg=; b=OMptTqbEgJsGkq6sT3exk0amzJf+OcIq9jAFMC/DFpI+sC9gwVgtJYKqKAbYi/x3+D 956O+O76//JoDD253oUi4pxn1tUf/pSyJnD2bH2rkHauMeU2JVmslbvRo3FWKLgVRtdb +cu25DV4FLO+tIM8NRdI/MbJSCwV+6nr5gQea0eSO0xLfFix8JRfwR0oaO0DRbeSI9ue DpLHioos2voDgCRvBSkXAT2dxiq3MxgwhzmingKOs15BC4cOSJNUrldhWJgCbo7Zinuo cKKWEdD0Bl2ZUXAsPJRCh1sUXFgJ3NAmTgpiJO6M9oIk5xoT27pp6XyiGCq8TOjddj9d y09Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=CnnQUOYhxSnjihor24GOeM8jvU8sHECS3MWHo0dXQeg=; b=VAzxgUhPO1wLNeQbxTPcT0XA1I9Q8WaUbAOxBfvRnTZcmRf5QUIdu6ogw2LXAEeRZr OHOi7a9yKTVsUTuaGO/OE8CBjHKRCphP745oWW6Ko8IR5HDZXD7ZUBLHWSLa8zUB/T0e wq9GWBSJFKyAfOXjj2sMVvMIH+HiKPB3yLl7uEQHQip4UOzURq4WJj5rAclMq0a3zT/i NKge0IkmlBV2MEwTipATHeW0KS553u9Kk+0jVgvWyJnASDaoZUQN55M0GZ8+3yZVgCP2 5Kj9Bup/R8fLBdLrdNo3zdG4CbMQeVCwmZXHAR4UQuijQi3vuzf8vpXJu81kd7NZ9JpU wozA==
X-Gm-Message-State: AFeK/H1g8tNzG07MFgo/NjOLjCVeVtLNTaVKWaDotikdXnFZN8yKmxdRPOWhaN7jNFHLonyok3zIMxp1hsIwYg==
X-Received: by 10.55.150.1 with SMTP id y1mr3457060qkd.311.1490840995200; Wed, 29 Mar 2017 19:29:55 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Wed, 29 Mar 2017 19:29:54 -0700 (PDT)
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Wed, 29 Mar 2017 19:29:54 -0700
X-Google-Sender-Auth: 7WNcwFY6uYb6gCOSR6nB-vsvUlY
Message-ID: 
Subject: draft needed - fe80::/10 vs fe80::/64 (Re: Objection to draft-ietf-6man-rfc4291bis-07.txt)
To: Alexandre Petrescu 
Cc: IPv6 IPv6 List 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 02:29:58 -0000

At Wed, 29 Mar 2017 20:39:27 -0500,
Alexandre Petrescu  wrote:

> The BSD code that was shown earlier checks the src of a received ND
> packet against fe80::/10 (not against fe80::/64).
>
> And other code in same OS BSD adds fe80::/64 (not fe80::/10) in the rt
> table.

I see there's some loose area between fe80::/10 and fe80::/64, but
that does not immediately mean a "problem".  If you want to raise a
concern to be shared with the wg, we'd need to see a specific
operational scenario such as one where one implementation cannot
communicate with others using a link-local address (whether the
definition is fe80::/10 or fe80::/64).  So far no one perhaps except
yourself sees such a scenario.  I'd suggest you summarize that
scenario in a draft and submit it, and then discuss it here, rather
than make this thread any longer.  I believe a draft is better than
more messages in this thread - email exchanges tend to lack critical
details, and at this point its overhead outweighs the vibrancy of
real-time(-ish) discussions.  I also guess that was a suggestion by
Ole as a wg chair.

--
JINMEI, Tatuya


From nobody Wed Mar 29 19:59:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BAF12949A; Wed, 29 Mar 2017 19:59:11 -0700 (PDT)
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 autolearn_force=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 42BRkpntnVIw; Wed, 29 Mar 2017 19:59:09 -0700 (PDT)
Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCCE12947F; Wed, 29 Mar 2017 19:59:07 -0700 (PDT)
X-AuditID: 60721c4c-b47ff7000000bcc0-e6-58dc7476d420
Received: from VAADCEX43.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 2C.52.48320.6747CD85; Wed, 29 Mar 2017 22:59:04 -0400 (EDT)
Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX43.cable.comcast.com (147.191.103.220) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Mar 2017 22:59:01 -0400
Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Wed, 29 Mar 2017 22:59:01 -0400
From: "Leddy, John" 
To: "suresh.krishnan@ericsson.com" 
CC: "ietf@ietf.org" , "ipv6@ietf.org" , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSqOd8Ap6Hay13uEWcjbPxwh2xd6GssVmA
Date: Thu, 30 Mar 2017 02:59:01 +0000
Message-ID: <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com>
In-Reply-To: <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [96.114.156.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsWSUOxpoVtRcifC4OVyPotXb6+xWTzbOJ/F 4uXZ90wWM+b8ZHdg8fj19Sqbx5IlP5kCmKK4bFJSczLLUov07RK4MrZ0drAUdKhUzLl9j72B cYJyFyMnh4SAicTsnn/sXYxcHEIC25kkGrovMYEkhAQOMUp8WKwIYZ9klFjVlQRiswnoSMyY do0VxBYRcJS4/7KJBaSZWWAuo0Tzuu0sIAlhAQ+JSZuusUAUeUqs23gYyOYAso0kdp+RAwmz CKhKLDj5AmwOr4CLxJymvYwQu4okFsyfyQxicwrYSvSvPQkWZxQQk/h+ag3YbcwC4hK3nsxn gnhAQGLJnvPMELaoxMvH/8BmigroSczc+ZcRIq4jcfb6EyjbQGLr0n0sELaCxPb928BOYxbQ lFi/Sx9ivIPE//2bWCFsRYkp3Q/ZIc4UlDg58wlUq6TEwRU3WCYwSs9CctEshEmzkEyahWTS LCSTFjCyrmKUK0tMTEnOzcgvLTEw0ktOTMpJ1UvOz01OLC4B0ZsYQRFfJOOzg/HTNI9DjAIc jEo8vCH+dyKEWBPLiitzgfHEwawkwqv16XaEEG9KYmVValF+fFFpTmrxIUZpDhYlcV6vm7ci hATSE0tSs1NTC1KLYLJMHJxSDYzWNf7fZ2jvnRl255jak+cHbOu/62tICjEplbPbHO78+fyw SrToie9xe3OeSj/MNeWRyxZWa+1e+f5E/Kc78jUSbpF914J0X3yR4f7HUPRwzaKguv7NPPl+ unb74h+cvvX816RPdlfqLPlOGiunsT5arRo0fU/ykvzvQg8khQ8JMd+eHMPD91iJpTgj0VCL uag4EQAIKSfr9AIAAA==
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 02:59:11 -0000

PiBPbiBNYXIgMTQsIDIwMTcsIGF0IDk6NDcgUE0sIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmty
aXNobmFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IE5FVzoNCiAgICA+IA0K
ICAgID4gV2l0aCBvbmUgZXhjZXB0aW9uLCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1p
bmVkLCBwcm9jZXNzZWQsDQogICAgPiBpbnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBh
bG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGgsDQogICAgPiB1bnRpbCB0aGUgcGFja2V0IHJl
YWNoZXMgdGhlIG5vZGUgKG9yIGVhY2ggb2YgdGhlIHNldCBvZiBub2RlcywgaW4NCiAgICA+IHRo
ZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVz
cyBmaWVsZCBvZg0KICAgID4gdGhlIElQdjYgaGVhZGVyLi4uDQogICAgPiANCiAgICA+IFBsZWFz
ZSBmZWVsIGZyZWUgdG8gY29tbWVudCBlaXRoZXIgcHJpdmF0ZWx5IG9yIG9uIGxpc3QgaWYgeW91
IGhhdmUgYW55IGNvbmNlcm5zIHdpdGggdGhpcyByZXNvbHV0aW9uIGdvaW5nIGZvcndhcmQuDQoN
Cg0KU3VyZXNoLA0KDQpJIHN0aWxsIGhhdmUgY29uY2VybnMgdGhhdCB3ZSBhcmUgZWxpbWluYXRp
bmcgYSB0b29sIHRoYXQgbWF5IHByb3ZlIHZlcnkgaGVscGZ1bCBpbiBtaWdyYXRpb25zIHdpdGhv
dXQgdW5kZXJzdGFuZGluZyBpdHMgdmFsdWUuDQoNClRoZSBJbnRlcm5ldCB0cmFuc2l0aW9uIG9m
IElQVjQgLT4gRHVhbCBTdGFjayBWNC9WNiAtPiBJUFY2IE9ubHk7IGhhcyBiZWVuIGxvbmcsIG9w
ZXJhdGlvbmFsbHkgY29tcGxleCBhbmQgZnVsbCBvZiB1bmV4cGVjdGVkIGNoYWxsZW5nZXMuDQpX
ZSBhcmUgb25seSBub3cgc3RhcnRpbmcgdG8gbWFrZSB0aGUgdHJhbnNpdGlvbiBmcm9tIER1YWwg
U3RhY2sgdG8gSVBWNiBPbmx5LCB0aGVyZSBhcmUgc3RpbGwgbWFueSB1bmtub3ducyBvbiBob3cg
dG8gY29tcGxldGUgdGhpcyBtaWdyYXRpb24uDQoNCkFzIHdlIGNvbnRlbXBsYXRlIGZpbmlzaGlu
ZyB0aGlzIG1ham9yIE5ldHdvcmsgc2hpZnQg4oCTIFdlIGZpbmQgb3Vyc2VsdmVzIGluIHRoZSBl
YXJseSBzdGFnZXMgb2YgYW5vdGhlci4NCg0KVGhlIHRyYW5zaXRpb24gZnJvbSBQaHlzaWNhbCB0
byBWaXJ0dWFsIEluZnJhc3RydWN0dXJlLiAgQWdhaW4sIHRoZSBtaWdyYXRpb24gd2lsbCBiZSBs
b25nLCBvcGVyYXRpb25hbGx5IGNvbXBsZXggYW5kIGZ1bGwgb2YgdW5leHBlY3RlZCBjaGFsbGVu
Z2VzLg0KDQpJbiB0aGUgb2xkIHdvcmxkIHdpdGggU2VydmVycyBydW5uaW5nIEFwcGxpY2F0aW9u
cyBpbiBQaHlzaWNhbCBsb2NhdGlvbnMgZGVzaWduZWQgZm9yIHZlcnkgcHJlZGljdGFibGUgbG9h
ZHM7IHVzaW5nIGFuIGVuY2FwL2RlY2FwIHR1bm5lbCB0byBlbXVsYXRlIGEgcGh5c2ljYWwgY2ly
Y3VpdCBiZXR3ZWVuIGxvY2F0aW9ucyBoYXMgbWFueSBhdHRyYWN0aXZlIHByb3BlcnRpZXMg4oCT
IGJ1dCB0aGF0IGlzIGNvbXBhcmVkIHRvIGFjdHVhbGx5IG9yZGVyaW5nIGFuZCBwcm92aXNpb25p
bmcgcmVhbCBjaXJjdWl0cyBiZXR3ZWVuIGxvY2F0aW9ucy4NCg0KSW4gdGhlIG5ldyB3b3JsZCBv
ZiBkeW5hbWljIHJlc291cmNlcyBzcHVuIHVwIG9uIGRlbWFuZCBpbiBkaXN0cmlidXRlZCBlbnZp
cm9ubWVudHMgYWNyb3NzIG11bHRpcGxlIHByb3ZpZGVycywgQXBwbGljYXRpb25zIGhhdmluZyB0
aGUgSW50ZWxsaWdlbmNlIGFuZCBTdGF0ZSB0byBicmluZyB1cCB0aGVpciBvd24gcmVxdWlyZWQg
Y29ubmVjdGl2aXR5IGlzIHZlcnkgbmF0dXJhbC4gIFRoaXMgaXMgd2hlcmUgd2UgYXJlIHB1dHRp
bmcgdGhlIG1ham9yaXR5IG9mIG91ciBlZmZvcnRzLiAgU1J2NiBlbmFibGVzIHZlcnkgYXR0cmFj
dGl2ZSBzb2x1dGlvbnMgYnkgQXBwbGljYXRpb25zIGJ1aWxkaW5nIHRoZWlyIG93biBoZWFkZXJz
Lg0KDQpUaGUgY2hhbGxlbmdlcyBjb21lIGFzIHdlIHRyeSB0byBtaWdyYXRlIGFuZCByZXF1aXJl
IHRoZXNlIHR3byBpbmZyYXN0cnVjdHVyZXMgdG8gSW50ZXJvcGVyYXRlIGZvciBhIGxvbmcgdGlt
ZS4NCkJ1cmRlbmluZyB0aGUgbmV3IFZpcnR1YWwgd29ybGQgd2l0aCBPbGQsIFN0YXRpYyBjaXJj
dWl0IHBhcmFkaWdtcyBpcyBub3Qgb3B0aW1hbC4NClN1cHBsZW1lbnRpbmcgdGhlIGxlZ2FjeSBp
bmZyYXN0cnVjdHVyZSB3aXRoIGFuIGFzc2lzdCBmdW5jdGlvbiBzZWVtcyBhIHJlYXNvbmFibGUg
c29sdXRpb24uICAoRXh0IEhkciBpbnNlcnRpb24vZGVsZXRpb24gb3IgZW5jYXAvZGVjYXAgdHVu
bmVscykNCg0KVGhlIHByZWZlcnJlZCBhc3Npc3QgbWVjaGFuaXNtIHNlZW1zIHRvIGJlIHRoZSBv
bmUgdGhhdCBhbGxvd3MgdGhlIE5ldyBXb3JsZCB0byBvcGVyYXRlIGluIGl0cyBmaW5hbCBwcmVm
ZXJyZWQgc3RhdGUsIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBwYWNrZXRzIHdpdGggdGhlaXIgb3du
IGhlYWRlcnMuIChTUnY2KQ0KQnV0IHdoYXQgZG9lcyBhbiBBcHBsaWNhdGlvbiBpbiB0aGUgbmV3
IHdvcmxkIGR1ZSB3aGVuIGl0IGlzIGF0dGVtcHRpbmcgdG8gY29tbXVuaWNhdGUgd2l0aCBhbiBB
cHBsaWNhdGlvbiBpbiB0aGUgT2xkIFdvcmxkPw0KU2hvdWxkbuKAmXQgaXQgYnVpbGQgYW4gU1J2
NiBoZWFkZXI/ICBUaGF0IHdvdWxkIG1lYW4gdGhhdCB0aGUgYXNzaXN0IGZ1bmN0aW9uIHdvdWxk
IG5lZWQgdG8gYmUgdGhlIGxhc3QgU0lEIGluIHRoZSBTZWdtZW50IExpc3QgYW5kIGJlIGNhcGFi
bGUgb2YgcmVtb3ZpbmcgdGhlIFNSSC4NCldvdWxkbuKAmXQgaXQgbWFrZSBzZW5zZSBmb3IgdGhl
IGFzc2lzdCBmdW5jdGlvbiB0byBkbyB0aGUgc2FtZSB0aGluZyBpbiB0aGUgcmV2ZXJzZSBkaXJl
Y3Rpb247IGFuIE9sZCBXb3JsZCBTZXJ2ZXIgdGFsa2luZyB0byBhIE5ldyBWaXJ0dWFsIFdvcmxk
IEFwcGxpY2F0aW9uPyAgSW5zZXJ0IGFuIFNSSC4NCg0KSWYgdGhpcyBpbnNlcnQvZGVsZXRlIG9m
IGFuIFNSSCBpcyBwcmVtYXR1cmVseSBwcm9oaWJpdGVkOyAgV2hhdCBpcyBhIHJlY29tbWVuZGVk
IHNvbHV0aW9uIHRvIHRoZSBSZWFsIFdvcmxkIHByb2JsZW0gYWJvdmUuICBOb3QgdXNlIGNhc2Us
IHdlIGFyZSBpbXBsZW1lbnRpbmcuDQoNCkFnYWluOyBJ4oCZbSB3b3JyaWVkIHdlIGFyZSBlbGlt
aW5hdGluZyBhIHRvb2wgdGhhdCBtYXkgcHJvdmUgdmVyeSBoZWxwZnVsLCBwcmVjbHVkZSBpdHMg
dXNlIGluIGZ1dHVyZSBJRVRGIHdvcmsgYW5kIHNodXRkb3duIGEgcGF0aCBmb3IgSW5ub3ZhdGlv
biBpbiBOZXR3b3JraW5nLA0KDQpUaGFuayB5b3UgZm9yIGFza2luZyBhbmQgbGlzdGVuaW5nIHRv
IG15IGNvbmNlcm5zLA0KDQpKb2huIExlZGR5DQpDb21jYXN0DQoNCiAgICANCiAgICANCiAgICAN
CiAgICANCg0K


From nobody Wed Mar 29 22:10:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E2612948D; Wed, 29 Mar 2017 22:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk
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 HE6cHp0XWT_U; Wed, 29 Mar 2017 22:09:59 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80B51292F5; Wed, 29 Mar 2017 22:09:57 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id v2U59nwo023964; Thu, 30 Mar 2017 06:09:50 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk v2U59nwo023964
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1490850590; bh=qQ+wkM8a2jK8gfpMQAXbEtr66rw=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=MjGgNcC42x5gMcsziZJ5m9T2bwHRJD2POensI5FrdX6wiLXEiOg3GoLj10l/BY/oK OI8Dt2Avyr/hFVkZGeM0Oe8o/0ud7dOfw7Q7zty4sHSOsSFRdPoXp8qzYeW7dzqRc7 f3btmxrVo3ADlTKtL8Yp9BCy9WN817d2cqoSUJu0=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP (valid=N/A) id y2Y69n1151000425fR ret-id none; Thu, 30 Mar 2017 06:09:50 +0100
Received: from dhcp-953e.meeting.ietf.org (dhcp-953e.meeting.ietf.org [31.133.149.62]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id v2U59cLd020815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Mar 2017 06:09:39 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
From: Tim Chown 
In-Reply-To: <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>
Date: Thu, 30 Mar 2017 06:09:37 +0100
Cc: "suresh.krishnan@ericsson.com" , "draft-ietf-6man-rfc2460bis.all@ietf.org" ,  "ipv6@ietf.org" , "ietf@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> 
To: "Leddy, John" 
X-Mailer: Apple Mail (2.3259)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=y2Y69n115100042500; tid=y2Y69n1151000425fR; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: v2U59nwo023964
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 05:10:02 -0000

Hi,

> On 30 Mar 2017, at 03:59, Leddy, John  wrote:
>=20
>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan =
 wrote:
>>=20
>> NEW:
>>=20
>> With one exception, extension headers are not examined, processed,
>> inserted, or deleted by any node along a packet's delivery path,
>> until the packet reaches the node (or each of the set of nodes, in
>> the case of multicast) identified in the Destination Address field of
>> the IPv6 header...
>>=20
>> Please feel free to comment either privately or on list if you have =
any concerns with this resolution going forward.
>=20
>=20
> Suresh,
>=20
> I still have concerns that we are eliminating a tool that may prove =
very helpful in migrations without understanding its value.
>=20
> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has =
been long, operationally complex and full of unexpected challenges.
> We are only now starting to make the transition from Dual Stack to =
IPV6 Only, there are still many unknowns on how to complete this =
migration.
>=20
> As we contemplate finishing this major Network shift =E2=80=93 We find =
ourselves in the early stages of another.
>=20
> The transition from Physical to Virtual Infrastructure.  Again, the =
migration will be long, operationally complex and full of unexpected =
challenges.
>=20
> In the old world with Servers running Applications in Physical =
locations designed for very predictable loads; using an encap/decap =
tunnel to emulate a physical circuit between locations has many =
attractive properties =E2=80=93 but that is compared to actually =
ordering and provisioning real circuits between locations.
>=20
> In the new world of dynamic resources spun up on demand in distributed =
environments across multiple providers, Applications having the =
Intelligence and State to bring up their own required connectivity is =
very natural.  This is where we are putting the majority of our efforts. =
 SRv6 enables very attractive solutions by Applications building their =
own headers.
>=20
> The challenges come as we try to migrate and require these two =
infrastructures to Interoperate for a long time.
> Burdening the new Virtual world with Old, Static circuit paradigms is =
not optimal.
> Supplementing the legacy infrastructure with an assist function seems =
a reasonable solution.  (Ext Hdr insertion/deletion or encap/decap =
tunnels)
>=20
> The preferred assist mechanism seems to be the one that allows the New =
World to operate in its final preferred state, sending and receiving =
packets with their own headers. (SRv6)
> But what does an Application in the new world due when it is =
attempting to communicate with an Application in the Old World?
> Shouldn=E2=80=99t it build an SRv6 header?  That would mean that the =
assist function would need to be the last SID in the Segment List and be =
capable of removing the SRH.
> Wouldn=E2=80=99t it make sense for the assist function to do the same =
thing in the reverse direction; an Old World Server talking to a New =
Virtual World Application?  Insert an SRH.
>=20
> If this insert/delete of an SRH is prematurely prohibited;  What is a =
recommended solution to the Real World problem above.  Not use case, we =
are implementing.
>=20
> Again; I=E2=80=99m worried we are eliminating a tool that may prove =
very helpful, preclude its use in future IETF work and shutdown a path =
for Innovation in Networking,
>=20
> Thank you for asking and listening to my concerns,

Understood, but why do you require direct insertion rather than using =
encap as per 2460bis?

Tim

>=20
> John Leddy
> Comcast
>=20
>=20
>=20
>=20
>=20
>=20


From nobody Thu Mar 30 02:30:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4434412922E for ; Thu, 30 Mar 2017 02:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=townsley-net.20150623.gappssmtp.com
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 6yjOOJ8Glbn0 for ; Thu, 30 Mar 2017 02:30:53 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF31126C89 for ; Thu, 30 Mar 2017 02:30:53 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id z13so15356683iof.2 for ; Thu, 30 Mar 2017 02:30:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=townsley-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y6q0pnLA8HspTv5iDBhyIDQ6gMaxLzqIUvQvqlhjkY4=; b=eVsQpV8h/9CQSfb/rEhUv5OJNeq44kmU0n0K15MciNol7TPhjqGR3CNovWaQvs/cG+ YvO8YF1iv3VC8KMTznF9r3FAEJZU5q3M0ZKj5CfoS6p3QMTF7oxgC7qT5oxTUGJ310dL HVaiQVpsmN0Egs3e5IE+iSPaYGU5VfYEWqp/KTRCqgmgbKO44WqZPX2BOyq+1QjL6Fk7 zmq7he71i2JNgeJspk2w9z5RJVe/nQdp7WVYrw0vM8c3oJnd6MnJtZZ1R5zK68YO/Xre ZPbGEtOid61ppzlBaNEn9Ojn3Y80a5QlUo9iC0hk034OA+EfLMXByzLpsYQleC3T3DMG JZVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y6q0pnLA8HspTv5iDBhyIDQ6gMaxLzqIUvQvqlhjkY4=; b=IpfBCHd6fHBur9q+Ismj+qhpesek7fOY5dlYppn0+vn4cFJ04RXmALPutZE1xRIBYm YqDgqUzfZH+FTwSpfVlMJhH60wmadnbsEK7xf7374wDrlCf02cNa23N5TeAYIFEtBLW3 OAISq+4FNDJkTumbmr2pPDcqA8uU/tZrmxYIC/81m+gM8suD1W/Nt+XZfAhfKpc3vPWV WRNpsnKtBYBlmSoAZS1qVmznoFJH8+59c/F7NZKpYIy7RhDk7ydujRV6bv3OFA/ldy86 sI3YSkPOry1DDVggHtCUCVFX7l10MxtiXHKwQl1OZXHgp1HA0cHNaMlMR0cnscI9Vu6Q vwLQ==
X-Gm-Message-State: AFeK/H0mAkqrzES7vQTR2k8Jk6wJDnytfJcpdJ+Wqb9IaSi2YvaNor2WWRI8TmZY0X020w==
X-Received: by 10.107.35.129 with SMTP id j123mr5887389ioj.195.1490866252738;  Thu, 30 Mar 2017 02:30:52 -0700 (PDT)
Received: from [10.71.6.171] (chsptrs33.c.subnet.rcn.com. [207.229.161.32]) by smtp.gmail.com with ESMTPSA id w133sm4768960itf.2.2017.03.30.02.30.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 02:30:51 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
From: Mark Townsley 
X-Mailer: iPad Mail (14D27)
In-Reply-To: <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>
Date: Thu, 30 Mar 2017 04:30:51 -0500
Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" ,  "ipv6@ietf.org" , "ietf@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>
To: "Leddy, John" , "suresh.krishnan@ericsson.com" 
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 09:30:56 -0000

I think this is hitting on a very important point about protocol transition h=
ere, something that I think all of us should step back and consider from a v=
ery humble vantage point.

The transition from IPv4 to IPv6 has been hard, certainly much harder than I=
 think the contributors to RFC2460 originally expected. We've had to go back=
 after the fact to define and perfect things like NAT64 to sit at the bounda=
ry of IPv6-only networks, allowing communication between IPv6-only and IPv4-=
only endpoints by inserting and deleting IPv6 and IPv4 headers.=20

The whole idea of an extension header is to extend the capabilities of IPv6.=
 Extended functions naturally come with transition, and transition happens p=
rogressively. Inserting and deleting an extension header is analogous to a N=
AT64 function - not something we necessarily want, but something we have rea=
lized we need, to handle transition within the reality that wide spread flag=
 days are impossible.

If I take IPv6 SR as an example of an extended IPv6 function, some endpoints=
 will support IPv6 SR sooner than others. Some network domains will operate w=
ith IPv6 SR everywhere sooner than others. The ability to classify traffic a=
nd insert an SR header upon entry into an SR domain is important to transiti=
on, and is completely analogous to what, say, T-Mobile does with NAT64 and 4=
64xlat. =20

Suresh, I think this may be a tussle point (to refer to Dave Clark's present=
ation earlier this evening). 2460bis should not try to over-specify here. In=
stead, allow for a bit of flex while we truly get our heads around how to de=
ploy and operate systems which use IPv6 extension headers.

- Mark




On Mar 29, 2017, at 9:59 PM, Leddy, John  wrote:

>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan  wrote:
>>=20
>> NEW:
>>=20
>> With one exception, extension headers are not examined, processed,
>> inserted, or deleted by any node along a packet's delivery path,
>> until the packet reaches the node (or each of the set of nodes, in
>> the case of multicast) identified in the Destination Address field of
>> the IPv6 header...
>>=20
>> Please feel free to comment either privately or on list if you have any c=
oncerns with this resolution going forward.
>=20
>=20
> Suresh,
>=20
> I still have concerns that we are eliminating a tool that may prove very h=
elpful in migrations without understanding its value.
>=20
> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has been=
 long, operationally complex and full of unexpected challenges.
> We are only now starting to make the transition from Dual Stack to IPV6 On=
ly, there are still many unknowns on how to complete this migration.
>=20
> As we contemplate finishing this major Network shift =E2=80=93 We find our=
selves in the early stages of another.
>=20
> The transition from Physical to Virtual Infrastructure.  Again, the migrat=
ion will be long, operationally complex and full of unexpected challenges.
>=20
> In the old world with Servers running Applications in Physical locations d=
esigned for very predictable loads; using an encap/decap tunnel to emulate a=
 physical circuit between locations has many attractive properties =E2=80=93=
 but that is compared to actually ordering and provisioning real circuits be=
tween locations.
>=20
> In the new world of dynamic resources spun up on demand in distributed env=
ironments across multiple providers, Applications having the Intelligence an=
d State to bring up their own required connectivity is very natural.  This i=
s where we are putting the majority of our efforts.  SRv6 enables very attra=
ctive solutions by Applications building their own headers.
>=20
> The challenges come as we try to migrate and require these two infrastruct=
ures to Interoperate for a long time.
> Burdening the new Virtual world with Old, Static circuit paradigms is not o=
ptimal.
> Supplementing the legacy infrastructure with an assist function seems a re=
asonable solution.  (Ext Hdr insertion/deletion or encap/decap tunnels)
>=20
> The preferred assist mechanism seems to be the one that allows the New Wor=
ld to operate in its final preferred state, sending and receiving packets wi=
th their own headers. (SRv6)
> But what does an Application in the new world due when it is attempting to=
 communicate with an Application in the Old World?
> Shouldn=E2=80=99t it build an SRv6 header?  That would mean that the assis=
t function would need to be the last SID in the Segment List and be capable o=
f removing the SRH.
> Wouldn=E2=80=99t it make sense for the assist function to do the same thin=
g in the reverse direction; an Old World Server talking to a New Virtual Wor=
ld Application?  Insert an SRH.
>=20
> If this insert/delete of an SRH is prematurely prohibited;  What is a reco=
mmended solution to the Real World problem above.  Not use case, we are impl=
ementing.
>=20
> Again; I=E2=80=99m worried we are eliminating a tool that may prove very h=
elpful, preclude its use in future IETF work and shutdown a path for Innovat=
ion in Networking,
>=20
> Thank you for asking and listening to my concerns,
>=20
> John Leddy
> Comcast
>=20
>=20
>=20
>=20
>=20
>=20


From nobody Thu Mar 30 02:38:26 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E532F1294C9 for ; Thu, 30 Mar 2017 02:38:24 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=townsley-net.20150623.gappssmtp.com
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 8G0XbmAmzInK for ; Thu, 30 Mar 2017 02:38:23 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F4F129471 for ; Thu, 30 Mar 2017 02:38:23 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id y18so73066252itc.1 for ; Thu, 30 Mar 2017 02:38:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=townsley-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HWf2QcWbZBuKsyIZCdueo1BZBZrhnTZNlN9iVvH5tcE=; b=VSbwJfSPObPV13wyBnSbHv8f9hExdks3xjgxH3x8NGaoHZXazWLE9AB0mTuOcbrccW gARn8WJughBnSMY+O5Udpf8bzt/NTLLji8ffVM4Ssoca5xh7BOZGyzGlFL1v1dMWjv4a Dm56TsenTc9OmkFnIyzpF/KahpT5WF0kYismnUNsZ/C7mU2PBKfC0D9GnNH/b8726z14 TkqBzECTySTKDyyq3rloPd8xv59mM2/g4ATBvTgxJVMuYrUmeJPkKpATd0eSmgCvy2AF WTd8mPO+IBDKjeP9pL3s6p00UOaQlkXDHoY+VcNgtMIGBPzVhlJ3RGpwF8rsHPfBXQ/f VYjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HWf2QcWbZBuKsyIZCdueo1BZBZrhnTZNlN9iVvH5tcE=; b=XGg3lrzF+J+46o4LBp3TUNuv968ksMxN289QNF5Sklqd//moeRtVvwXZEh8VrwNOfn xpHSBE4rZsmsCRpGUnagZnFk4c0GiNxwxzpjSqL/7n19OOnUhol2fLBLm2hTaYTDmD63 ybKY3k+bIFrSn/iluDPQKQKYQdIEsAhBZ0M5h4ln6V4w+wyN5A03c69kwZUvLJQM4H7Z 6Jp7YEVN+wChVsH41Fo+XORWBJuiidtyS5cO0KA8DsF332ZY/nz8Fg9nxr8eWgQxr9dV RptqeBshSiSVK9jn9M3YD8sAXiJ0xhaStZpJJfYLTM/CSHMzC3lmTZ8tveoE9E5BH392 E/2g==
X-Gm-Message-State: AFeK/H1guqh2jjwDJ6weyRYNvfoGBBr+LYJqKbZ5MZ1J5f1mVwhtqAakOaoExGQZtZd9UA==
X-Received: by 10.36.65.147 with SMTP id b19mr3335183itd.111.1490866702882; Thu, 30 Mar 2017 02:38:22 -0700 (PDT)
Received: from [10.71.6.171] (chsptrs33.c.subnet.rcn.com. [207.229.161.32]) by smtp.gmail.com with ESMTPSA id k68sm1100321iod.13.2017.03.30.02.38.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 02:38:21 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
From: Mark Townsley 
X-Mailer: iPad Mail (14D27)
In-Reply-To: 
Date: Thu, 30 Mar 2017 04:38:20 -0500
Cc: "Leddy, John" , "draft-ietf-6man-rfc2460bis.all@ietf.org" ,  "ipv6@ietf.org" , "ietf@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>  
To: Tim Chown 
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 09:38:25 -0000

> On Mar 30, 2017, at 12:09 AM, Tim Chown  wrote:
>=20
> Understood, but why do you require direct insertion rather than using enca=
p as per 2460bis?

The same reason we have MAP-T and 464xlat.=20

- Mark

>=20
> Tim
>=20
>>=20
>> John Leddy
>> Comcast
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>=20


From nobody Thu Mar 30 04:07:07 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2840F129471; Thu, 30 Mar 2017 04:07:00 -0700 (PDT)
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 autolearn_force=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 Hzis7LmUkRBH; Thu, 30 Mar 2017 04:06:57 -0700 (PDT)
Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B961127A97; Thu, 30 Mar 2017 04:06:57 -0700 (PDT)
X-AuditID: 60721c4c-b2dff7000000bcc0-91-58dce6ce975d
Received: from VAADCEX43.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 10.E3.48320.EC6ECD85; Thu, 30 Mar 2017 07:06:56 -0400 (EDT)
Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX43.cable.comcast.com (147.191.103.220) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 30 Mar 2017 07:06:53 -0400
Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Thu, 30 Mar 2017 07:06:53 -0400
From: "Leddy, John" 
To: Mark Townsley 
CC: Tim Chown , "draft-ietf-6man-rfc2460bis.all@ietf.org" , "ipv6@ietf.org" , "ietf@ietf.org" 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSqOd8Ap6Hay13uEWcjbPxwh2xd6GssVmAgABnjYCAAEsUAP//1bD/
Date: Thu, 30 Mar 2017 11:06:53 +0000
Message-ID: <619B8C8A-066E-4C5B-A462-DF109E39DA71@cable.comcast.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsWSUOxpoXvh2Z0Ig+VTVCxevb3GZvFs43wW i5dn3zNZTDvwgMni0J7nbA6sHn/XuXosWfKTyeP+tIlMAcxRXDYpqTmZZalF+nYJXBkXPsxg K3jBVrH1bGED4yLWLkZODgkBE4nrf+azdDFycQgJbGeSuNFxjRXCOcQo0fbvLhuEc5JRYt/T D8wgLWwCOhIzpl0DaxcRUJVYe+UhM0gRs8A+Rol3H0+CJYQFPCQmbbrGAlHkKbFu42EgmwPI dpPo/hEOYrIA9e66aQJi8gq4SBzaUQKxaiqzxIKGOYwgnZwCDhLzGnaA2YwCYhLfT61hArGZ BcQlbj2ZzwTxgYDEkj3nmSFsUYmXj/9BfWYgsXXpPhaIeh2JBbs/sUHY2hLLFr4Gq+cVEJQ4 OfMJC0S9pMTBFTdYJjCKz0KyYhaS9llI2mchaV/AyLKKUa4sMTElOTcjv7TEwEgvOTEpJ1Uv OT83ObG4BERvYgTFY5GMzw7GT9M8DjEKcDAq8fBu3XsnQog1say4MhcY3BzMSiK83E+AQrwp iZVVqUX58UWlOanFhxilOViUxHm9bt6KEBJITyxJzU5NLUgtgskycXBKNTBOFp9le+rutAUO /6/ulkw7M6PdS7Ou1krwXrjJicV/psScWrT/XCljsGwA49ZulV3ea3cxyZ4O/3AyyWpf6POp 0f5t57Y9qeZPyNrDwLRcRsFUuelm5akNih7PTWL6fJY0q3Fw5b189eTT0SlZQgyLRC/2L1Hp meYuOf07O2tRiNPODyEpD08osRRnJBpqMRcVJwIAPuhLg8MCAAA=
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 11:07:00 -0000

The issue is the encap/decap pair - like an old circuit model.

Do we add the encap/decap function into a Domain doing native SRv6 and the =
complexity of choosing which to use - into all the vm's?  Or do we extend t=
he new SRv6 domain to the legacy infrastructure.   If we do this, there is =
no tunnel.  There is no encap/decap pair - you need to proxy for the legacy=
 gear/services.

John

> On Mar 30, 2017, at 4:38 AM, Mark Townsley  wrote:
>=20
>=20
>=20
>> On Mar 30, 2017, at 12:09 AM, Tim Chown  wrote:
>>=20
>> Understood, but why do you require direct insertion rather than using en=
cap as per 2460bis?
>=20
> The same reason we have MAP-T and 464xlat.=20
>=20
> - Mark
>=20
>>=20
>> Tim
>>=20
>>>=20
>>> John Leddy
>>> Comcast
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>=20


From nobody Thu Mar 30 05:44:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF91129698; Thu, 30 Mar 2017 05:44:26 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 uHoSKLBbuYdl; Thu, 30 Mar 2017 05:44:25 -0700 (PDT)
Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04FD129677; Thu, 30 Mar 2017 05:44:24 -0700 (PDT)
Received: by mail-it0-x242.google.com with SMTP id 190so12866333itm.3; Thu, 30 Mar 2017 05:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MTlfsjXmfKNHquRWOk/cej1jwTINVowrSssjAKLOtLM=; b=K96Cagm7TlTGUG6U85N/4fj1p8ZgOIfW1WGLULiExVD9y1qUXTckCJectO9Z7VI38G qlouwL81kfweOpBpAKlSvjkdvooYV5ZV3vIleEbIx3A5Tmnhe6ci5FOyYZdIKCK5AoNm u1IxrAUSbSQT+YhiMu2woxcxNpeHak/7x6W267F+02G7Wt60YSXgYXwPb8MQmh0hBzBV fe2Q441t2mOJRs9sbvXhYR3YntG/k+3TFJW72eYLJudUJQT6Y5fQLxWwSCCz3fhgV6xw DJxwKEzPeZbWCzTCFPqvRYAYztJK3NXSBXwQdhwGRgih2iSnRtYk2irYCZu+GEFQKGmE 2s6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=MTlfsjXmfKNHquRWOk/cej1jwTINVowrSssjAKLOtLM=; b=teXV8AGUNeWBK91gtYHWWoPbD6L6hyqM0PlSFvz+q+AaW8a+awRvhESb7mbHwNLat3 gHOD8gq1pQAThGfZ8nYF6VE9Mv7oNck0Zy5xCkRlBzoKsxFwwTyZbSe8wltiXwzolgu1 B35LRjh2aGkpRhwGCPz4C2g9JPH2sdRYhu1zEY6q68+A6c61uzapXBEYI27Rd35xgZTr MP1/io2b3F49Molz+njIMj/jcOb26QZfT+pxc3eCHs7j7pU8QbIgjSVcMqKTuCkabUDu KU5TldradGvt+6ZN8uSP/xVrNEQKS1YpFtWDxIdSM5NoUa6r2rCaUZdR7zjaciveGOgZ yPvg==
X-Gm-Message-State: AFeK/H2x+QIL2wyrM+LP0MH27jExMwuRAF2ZYEgZjihz4bZTCWQ3F7oxR9wbNCFEND2mrQ==
X-Received: by 10.36.0.198 with SMTP id 189mr3892889ita.82.1490877864156; Thu, 30 Mar 2017 05:44:24 -0700 (PDT)
Received: from [31.133.147.88] (dhcp-9358.meeting.ietf.org. [31.133.147.88]) by smtp.gmail.com with ESMTPSA id m77sm1292122ita.16.2017.03.30.05.44.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 05:44:23 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: "Leddy, John" , "suresh.krishnan@ericsson.com" 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>
Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man , IETF discussion list 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com>
Date: Fri, 31 Mar 2017 01:44:30 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 12:44:26 -0000

On 30/03/2017 15:59, Leddy, John wrote:

=2E..
> If this insert/delete of an SRH is prematurely prohibited;  What is a r=
ecommended solution to the Real World problem above.  Not use case, we ar=
e implementing.
>=20
> Again; I=E2=80=99m worried we are eliminating a tool that may prove ver=
y helpful, preclude its use in future IETF work and shutdown a path for I=
nnovation in Networking,

I've tried to say this before but I'm not sure people are getting it:=20

RFC2460bis, if approved as is, draws a line in the sand *for interoperabi=
lity across the whole Internet*. There are reasons for this - PMTUD in an=
y form, any future replacement for the unsuccessful IPsec/AH, and all the=
 problems of deploying extension headers that are understood by some node=
s and not by others.=20

There is no reason why a subsequent standards-track document cannot allow=
 header insertion (and removal) within finite domains where the above iss=
ues do not apply. In fact, an improved version of draft-voyer-6man-extens=
ion-header-insertion-00 could become exactly that.

There doesn't need to be a tussle here.=20

   Brian Carpenter


From nobody Thu Mar 30 06:12:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F071294C4; Thu, 30 Mar 2017 06:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 h9oxSGcyYfnZ; Thu, 30 Mar 2017 06:12:01 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1B41294E5; Thu, 30 Mar 2017 06:12:00 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id y18so1843938itc.1; Thu, 30 Mar 2017 06:12:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=9WQ7aB6vOJr1y7R0P5/9V9w9T05gr0aI9C9EMyRo9eg=; b=i8Rg94o9+SiFlNew/sVHkegPsLfsVdLovEHVgK9YMhdYFOUupl/si3AnFGu39jBZKw ds4Ysv50MqCC+UmdwxKFlrKcOKPk8S2P2SUyKRcgyOKEAwXuH7qosbqeBIMUswpsG+F2 lohw59sD+cPCTz8IO6W86VtygilJAYZXsn1kWUO9FvdRj5qVpesgWzPFv6wc9mpyopcn 376t04XJBbI3919TznT4A/iOaOCAX4bnbACEXnaIMP6P4zYj/llYjT8edRxKxYXKecMX 2yw7ke1ST552YUjvLKd60PPmKpqi1/P9iFFYHh0SU0LvoHxDK5VbPEnkvZvMkFf7U/gQ /tsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=9WQ7aB6vOJr1y7R0P5/9V9w9T05gr0aI9C9EMyRo9eg=; b=Obzl268B24W21d6hQ2jKmH7V4Gu+yjSdS1Xo59lf1sBhiApwbboTtlMWXjpb06qaM4 wZXD/bGdarsunG/gWoeN4SyI1PT3gCwN+p+P/F9TgrdBjRkin3a5iIxaHhzTYLRN75Gn mkZtSUiqsSh3PttrKYJ3Wu/OdmsiS08PVv9HWbx+ZgrTcbHfWQvaDCJ3AEqrOvRlVzR8 1ErCluQQkftv5Te+qvbphLZiIi7/eOXhoEtkOrq4Eyg4mvpLTEFbo8XkLVgJuariKgM4 3WgJUY1VrqJYIx/l9lbG9rvqrcREdNwJxIz0zOJgO2xLoQxXkt16V/ZbCDCVbD2eUKM2 k9wg==
X-Gm-Message-State: AFeK/H2eHo2nQlEfYYWrq7jVtMSyq+8kU13Owei/voOsUrGOVTAZyopyjHh5ZzJAQvS8LA==
X-Received: by 10.36.43.78 with SMTP id h75mr311776ita.25.1490879519903; Thu, 30 Mar 2017 06:11:59 -0700 (PDT)
Received: from [31.133.143.171] (t2001067c037001284d2da5a9acf593c2.v6.meeting.ietf.org. [2001:67c:370:128:4d2d:a5a9:acf5:93c2]) by smtp.gmail.com with ESMTPSA id v185sm1328437itf.11.2017.03.30.06.11.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 06:11:58 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Thu, 30 Mar 2017 08:11:57 -0500
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
From: Jeff Tantsura 
To: Brian E Carpenter , "Leddy, John" , "suresh.krishnan@ericsson.com" 
CC: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man , IETF discussion list 
Message-ID: <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com>
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com>
In-Reply-To: <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 13:12:08 -0000

Brian,

if I understand you correctly:=20

If properly worded (improved) draft-voyer explicitly states =E2=80=93 the intenti=
on is to change the 2460(bis) behavior and to allow header insertion within =
a controlled domain, and given there=E2=80=99s a valid justification of why encap =
wouldn=E2=80=99t=E2=80=99 meet the need, you wouldn=E2=80=99t oppose?=20

Thanks!=20

Cheers,
Jeff

On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter"  wrote:

    On 30/03/2017 15:59, Leddy, John wrote:
   =20
    ...
    > If this insert/delete of an SRH is prematurely prohibited;  What is a=
 recommended solution to the Real World problem above.  Not use case, we are=
 implementing.
    >=20
    > Again; I=E2=80=99m worried we are eliminating a tool that may prove very he=
lpful, preclude its use in future IETF work and shutdown a path for Innovati=
on in Networking,
   =20
    I've tried to say this before but I'm not sure people are getting it:=20
   =20
    RFC2460bis, if approved as is, draws a line in the sand *for interopera=
bility across the whole Internet*. There are reasons for this - PMTUD in any=
 form, any future replacement for the unsuccessful IPsec/AH, and all the pro=
blems of deploying extension headers that are understood by some nodes and n=
ot by others.=20
   =20
    There is no reason why a subsequent standards-track document cannot all=
ow header insertion (and removal) within finite domains where the above issu=
es do not apply. In fact, an improved version of draft-voyer-6man-extension-=
header-insertion-00 could become exactly that.
   =20
    There doesn't need to be a tussle here.=20
   =20
       Brian Carpenter
   =20
   =20



From nobody Thu Mar 30 06:17:11 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FECC1294EE; Thu, 30 Mar 2017 06:17:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ipv6@ietf.org
Subject: I-D Action: draft-ietf-6man-rfc2460bis-09.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.49.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149087982144.15440.1212360545344951994@ietfa.amsl.com>
Date: Thu, 30 Mar 2017 06:17:01 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 13:17:02 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.

        Title           : Internet Protocol, Version 6 (IPv6) Specification
        Authors         : Stephen E. Deering <>
                          Robert M. Hinden
	Filename        : draft-ietf-6man-rfc2460bis-09.txt
	Pages           : 41
	Date            : 2017-03-30

Abstract:
   This document specifies version 6 of the Internet Protocol (IPv6).
   It obsoletes RFC2460


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-09
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09


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 nobody Thu Mar 30 06:30:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447FA1296B1; Thu, 30 Mar 2017 06:30:25 -0700 (PDT)
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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GhYUEPyE4r1d; Thu, 30 Mar 2017 06:30:23 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC62129698; Thu, 30 Mar 2017 06:30:23 -0700 (PDT)
X-AuditID: c618062d-d73ff700000009d8-9b-58dd1a1258ab
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by  (Symantec Mail Security) with SMTP id DA.DC.02520.21A1DD85; Thu, 30 Mar 2017 16:45:41 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Thu, 30 Mar 2017 09:30:18 -0400
From: Suresh Krishnan 
To: "Leddy, John" 
CC: "ietf@ietf.org" , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv86cghjjmGk6P6rsvHH5Q4qGssVmAgAEK0QA=
Date: Thu, 30 Mar 2017 13:30:17 +0000
Message-ID: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>
In-Reply-To: <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: multipart/signed; boundary="Apple-Mail=_65BB2E3A-3775-4603-8BAC-3263668990BE"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyuXRPiK6o1N0Ig7Xf9Cxevb3GZvFs43wW i5dn3zNZLF2wnMmBxeN6Zwuzx5IlP5kCmKK4bFJSczLLUov07RK4Mm5Of8lWMMev4uHZucwN jLvduhg5OSQETCS2dDxk72Lk4hAS2MAoMXfqWyYIZzmjxLbG2+wgVWxAVRt2fmYCsUUEtCT2 nN0M1sEsMJVR4vLSe8wgCWEBD4lJm66xQBR5SqzbeBjKtpLoXbCPFcRmEVCVuPl2AxuIzStg L7H13TRmiG1rGSXa3twFa+AUcJV4dPsaWAOjgJjE91NrwDYzC4hL3HoynwnibhGJhxdPs0HY ohIvH/9jhbCVJD7+ng913RRGiWtbd7BCbBOUODnzCcsERpFZSGbNQlY3C0kdRJG2xLKFr5kh bE2J/d3LoeKmEq+PfmSEsK0lZvw6yAZhK0pM6X7IvoCRYxUjR2lxQU5uupHBJkZgzB2TYNPd wXh/uuchRgEORiUe3gd7b0cIsSaWFVfmHmJUAWp9tGH1BUYplrz8vFQlEd61bHcjhHhTEiur Uovy44tKc1KLDzFKc7AoifNOOH8hQkggPbEkNTs1tSC1CCbLxMEp1cC4XWTm5bLp6l0ygndY GKa06kU+vrPL8KWJOEfkpGWzGNzsN59WWXrUJ7NIeY7aptBcl5DdF5n+1vc9WeK+1I3V8G3B 6rVN60Qv7Dr89xy/8THhzHl7tnxLvHZJ8G2kas7Wb28T2TmKr/jNN0zc77K3Xzjkym07q24v LYdbQjLKNyP65K//ba9TYinOSDTUYi4qTgQAAk/ap8ECAAA=
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 13:30:25 -0000

--Apple-Mail=_65BB2E3A-3775-4603-8BAC-3263668990BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi John,
  Thanks for chiming in. I recognize that you might have use cases that =
might be better off with header insertion but I think they should be =
handled as and when they come up for consideration (e.g. in the SRv6 =
discussions). Holding up this document is not going to help in any way =
in reinterpreting what RFC2460 intended. My suggestion for proponents of =
safe header insertion to write up how it is expected to work and have =
the discussion then.

Thanks
Suresh

> On Mar 29, 2017, at 9:59 PM, Leddy, John  =
wrote:
>=20
>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan =
 wrote:
>>=20
>> NEW:
>>=20
>> With one exception, extension headers are not examined, processed,
>> inserted, or deleted by any node along a packet's delivery path,
>> until the packet reaches the node (or each of the set of nodes, in
>> the case of multicast) identified in the Destination Address field of
>> the IPv6 header...
>>=20
>> Please feel free to comment either privately or on list if you have =
any concerns with this resolution going forward.
>=20
>=20
> Suresh,
>=20
> I still have concerns that we are eliminating a tool that may prove =
very helpful in migrations without understanding its value.
>=20
> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has =
been long, operationally complex and full of unexpected challenges.
> We are only now starting to make the transition from Dual Stack to =
IPV6 Only, there are still many unknowns on how to complete this =
migration.
>=20
> As we contemplate finishing this major Network shift =E2=80=93 We find =
ourselves in the early stages of another.
>=20
> The transition from Physical to Virtual Infrastructure.  Again, the =
migration will be long, operationally complex and full of unexpected =
challenges.
>=20
> In the old world with Servers running Applications in Physical =
locations designed for very predictable loads; using an encap/decap =
tunnel to emulate a physical circuit between locations has many =
attractive properties =E2=80=93 but that is compared to actually =
ordering and provisioning real circuits between locations.
>=20
> In the new world of dynamic resources spun up on demand in distributed =
environments across multiple providers, Applications having the =
Intelligence and State to bring up their own required connectivity is =
very natural.  This is where we are putting the majority of our efforts. =
 SRv6 enables very attractive solutions by Applications building their =
own headers.
>=20
> The challenges come as we try to migrate and require these two =
infrastructures to Interoperate for a long time.
> Burdening the new Virtual world with Old, Static circuit paradigms is =
not optimal.
> Supplementing the legacy infrastructure with an assist function seems =
a reasonable solution.  (Ext Hdr insertion/deletion or encap/decap =
tunnels)
>=20
> The preferred assist mechanism seems to be the one that allows the New =
World to operate in its final preferred state, sending and receiving =
packets with their own headers. (SRv6)
> But what does an Application in the new world due when it is =
attempting to communicate with an Application in the Old World?
> Shouldn=E2=80=99t it build an SRv6 header?  That would mean that the =
assist function would need to be the last SID in the Segment List and be =
capable of removing the SRH.
> Wouldn=E2=80=99t it make sense for the assist function to do the same =
thing in the reverse direction; an Old World Server talking to a New =
Virtual World Application?  Insert an SRH.
>=20
> If this insert/delete of an SRH is prematurely prohibited;  What is a =
recommended solution to the Real World problem above.  Not use case, we =
are implementing.
>=20
> Again; I=E2=80=99m worried we are eliminating a tool that may prove =
very helpful, preclude its use in future IETF work and shutdown a path =
for Innovation in Networking,
>=20
> Thank you for asking and listening to my concerns,
>=20
> John Leddy
> Comcast
>=20
>=20
>=20
>=20
>=20
>=20


--Apple-Mail=_65BB2E3A-3775-4603-8BAC-3263668990BE
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw
ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy
aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5
MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz
aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ
MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C
oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg
ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+
SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI
MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O
nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6
Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG
AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp
ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD
VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5
LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G
yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL
B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU
Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc
4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG
H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn
78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r
WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz
Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO
NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb
Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR
AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3
MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp
ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1
3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE
9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp
usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq
qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um
0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI
4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N
V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta
IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj
NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB
igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy
YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv
bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww
SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50
ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50
ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/
SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H
IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp
Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG
x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj
9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55
JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj
SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk
9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7
RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA
Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC
mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzMwMTMzMDE3WjAjBgkqhkiG9w0B
CQQxFgQU/6WTQS7gR+AeGjbiM4QXlieHqhswXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF
cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa
99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG
9w0BAQEFAASCAQAZTCsgY/E5rQHjHIFsM61QmBBMEem+rpdAhd19YgNpUGVwzIzMFSpPnghMuXz/
PNSWSrxzwEvXTaLoqSgHRYmZBhXqhcveEa2+dtq3h/TOkYWwpMPvaQzeGM2iwxU73cqf/KRp57R1
BEKilYhhJ75uixq6tXyWIxo09jFaS75Z06/y9q5azqLWZZppvyrNVvS3codDyNKAcXcVjjDnyRhg
13PBw73zJulkgyoiIo+PBkEhqOJofzVvizhx+w+rSOZ8tYCXsQpeConquTpuWZDroo7tBsf4v8Jx
QE7wumpw6HbpQS0tReQpYu19JhuzlqxEmhepC3tmbm1+ETtyW0BsAAAAAAAA

--Apple-Mail=_65BB2E3A-3775-4603-8BAC-3263668990BE--


From nobody Thu Mar 30 06:36:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749A7129463 for ; Thu, 30 Mar 2017 06:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Nf965OoV_VL9 for ; Thu, 30 Mar 2017 06:35:56 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6BF1296B6 for ; Thu, 30 Mar 2017 06:35:56 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id b140so19071189iof.1 for ; Thu, 30 Mar 2017 06:35:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:cc:to; bh=AoC2wNEeXr2ELFMpWLaD8Fl82jL6cZhnvWqDfrnrJqg=; b=YUZZosL5eGkGRW/0CnuQK8vTsQUhYctY7wTkP2LNamF6wbjudfObleN88505K1ufyM Z9om1L6CpBKaSYQQtQQYKGPYvwhhOtWGH0JmbKl2Kkh8rVq6Y9p70dG0a9gRZF1/DAFB LgNxKLwqBeXTAqaZdFx/UPa9qUD1NtMiq8obupSofPXiBT5Td6OTg3ShGlQaPLnWmkf4 VKobY9KEj2y4F7qQYmD1th6zcmuZvBNB8Tm/B+EqSJZitfMgu8ifaoWmER+BUh0KqKdf F+2T8mNkfuW5vg5e1gnvrhZEWVFnVyEjDausnCk9zKJTZb3FKloHCtrIsE5c50QEx9uz Vhfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=AoC2wNEeXr2ELFMpWLaD8Fl82jL6cZhnvWqDfrnrJqg=; b=GJtvkUS77EBUTV6tGADYszoag5KF6oxRgouYGUp6zCSxasCnWdUiQMheGKX1aFewc5 l2bOq1xTf5BiCcLeWTLHwwCJsMKr8lNFPhyVDN8y5y/WrMQigHmzKUK02ABFCkvETUvE NFlu7wd8gO28adW8DfVwJ9B4RaRkWiYt1doyPbOS/rRIezgH4Aqfp0OgiMm3Ng+hCUK1 AE/nPsqdXwiyNmzOPvmWE1/ICp3BeTgzzu3KcwaE4C7ye0xu2ZVT0UPMkJl50f1jS3tc PXd7JhRjO+UZQapSgGcPsjeGKGye/NJu7z6WKY+BH4okTIcBl4K5gZfQ0i259fkwBZex 4jLw==
X-Gm-Message-State: AFeK/H3n9dL1w2bUCVf/FPfwF2Zjj29pUsNZvmD9kptTjL66u7YT7HTGq8YAj0TT7JQyqw==
X-Received: by 10.107.39.70 with SMTP id n67mr477615ion.114.1490880955579; Thu, 30 Mar 2017 06:35:55 -0700 (PDT)
Received: from [172.20.6.68] (swissotel07.s.subnet.rcn.com. [216.80.61.6]) by smtp.gmail.com with ESMTPSA id l198sm1360992ita.10.2017.03.30.06.35.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 06:35:54 -0700 (PDT)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_1E4620C6-9CC5-43A4-BE33-045456C53ECD"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: 
Message-Id: 
Date: Thu, 30 Mar 2017 08:35:53 -0500
Cc: Bob Hinden 
To: IPv6 List 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 13:36:05 -0000

--Apple-Mail=_1E4620C6-9CC5-43A4-BE33-045456C53ECD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

I published the -09 version of 6man working group draft of rfc2460bis.  =
Links below.

The changes in this draft are:

      Based on results of IETF last call, changed text in Section 4
      to add clarification that extension headers are not examined,
      processed, inserted, or deleted by any node along a packet's
      delivery path.

      Changed reference from draft-ietf-6man-rfc4291bis to RFC4291
      because the bis draft won't be advanced as the same time.

      Revised "Changes since RFC2460" Section to have a summary of
      changes since RFC2460 and a separate subsection with a change
      history of each Internet Draft.  This subsection will be
      removed when the RFC is published.

      Editorial changes.

A diff from the -08 version can be found at:

   https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-09

Please review the changes.

This is part of the project to move the core IPv6 specifications to =
Internet Standard.

Thanks,
Bob

> A new version of I-D, draft-ietf-6man-rfc2460bis-09.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-6man-rfc2460bis
> Revision:	09
> Title:		Internet Protocol, Version 6 (IPv6) =
Specification
> Document date:	2017-03-30
> Group:		6man
> Pages:		41
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-09.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-09
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-09
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-09
>=20
> Abstract:
>   This document specifies version 6 of the Internet Protocol (IPv6).
>   It obsoletes RFC2460
>=20



--Apple-Mail=_1E4620C6-9CC5-43A4-BE33-045456C53ECD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJY3Qm6AAoJEK7rdBF357uo8BwH/2fS8SBg/ueTdDvXhmPmP0nu
okagY6MSLdyYgBGPiUH6NBqbqn4X1gRU6gCb67pSqQGi7d9kFfmGUnLSd/Fzpz6a
dR3+7rO2qlTWIr0lHEK4eaTYGDemvY7rmTpgSiD606Ol2rsHZmjyYLi8j0FcsFbb
OUgfIutaCWsnrYHMJjDO73sEit4zj37UXzb+uay+DZqi79+MdcvCQixCamfwnQ36
v8rGPte4KML69G7pzErsz6oHLVCbrdR5NiLXrXX3MU1wFvjYQM6AUVqQDHLKkG3z
hT9zXw9MK8srAZqngTI8u0Uny3mbPS+qpyIBvsicEOxCNh+dq3v5QHqQjX16kyI=
=DswH
-----END PGP SIGNATURE-----

--Apple-Mail=_1E4620C6-9CC5-43A4-BE33-045456C53ECD--


From nobody Thu Mar 30 06:49:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7015A12950B for ; Thu, 30 Mar 2017 06:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 H7Z5KTkgPqf8 for ; Thu, 30 Mar 2017 06:48:55 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA341293DA for ; Thu, 30 Mar 2017 06:48:55 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id f84so19238290ioj.0 for ; Thu, 30 Mar 2017 06:48:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1b82LUnwJI/l0pHyaFsaI63nxaH62tV0bosBj7zlWLY=; b=pqAvvbeXsOMiZNbUNOjqZZa7TTkEkaMUTi61ZLe+rZ+if65/zYcQ7Fvd18aXPIQqa3 JWFgeVS6fbML5la6LHXbtgatNzkMBYmsLDARRA7m1+s1r3OYMAb2JJj5Dk97eDG1NBUP WUoN66F+tJkjsY/7bvtqDFmukzwoq/+MzntOQBsE4SO1fGQPNtWrqjJKUJ46BrLMo0Dg aouMV6sgWfUbluxLHJzvJSa2KwjmljHrCqhOKX+CDKvQyuufHIbM532jpQyduih/RpWD fqJPeFfqoAG6q8hEvuL5XTckiPO0fVSIsWdE9jB4Y0U/cW9ocPRYeJmfIWqBlV195J41 0NAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=1b82LUnwJI/l0pHyaFsaI63nxaH62tV0bosBj7zlWLY=; b=UEpkPiPWXS6hI6PEPUOz1p0EbTGEX7xoWUpX0R0GT8F9boPJfw+hyOiD3nY60kBqdh lIg9zSD3vKZBDJY2xH/rf8PCCBlbBesb8jjGkdlefuEDXIxQ16+jVvw2SnObyRcNvDUf BjNYDxSH+AMzlJYV9IpSWT0uVJXlwbLOlcOFIYLpKPThRJd/VthkK7rhPGzys5rh5x9n sA78LGLUU8GtjJKQZtUMRVyGQstG84YScdcfqGE89S9XtYNi7Iy8UbxO2WP/Y/8/vM0B 68YQ3OwuPQDVAMEEPltL57AwjUcYwzflh/kr7hfxEuvl8bE5SKmmYjKmROoKsAQODG6R BoQA==
X-Gm-Message-State: AFeK/H0MF9TNBYR9x1UQopn3oftuFGSjubYCti8JRoIlT1cjHrRe+5T9f/0Zy2y+DA0+vQ==
X-Received: by 10.107.141.23 with SMTP id p23mr502343iod.97.1490881734704; Thu, 30 Mar 2017 06:48:54 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w133sm5049925itf.2.2017.03.30.06.48.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 06:48:54 -0700 (PDT)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
To: "Stefano Previdi (sprevidi)" 
References: <149072338991.1228.10342495694037829468@ietfa.amsl.com> <0667344d-ad0c-2e7c-2e67-be913d5293ca@gmail.com> 
Cc: 6man 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <4a8524b4-ad65-395b-5907-0171bba4128a@gmail.com>
Date: Fri, 31 Mar 2017 02:49:01 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 13:48:59 -0000

On 30/03/2017 09:55, Stefano Previdi (sprevidi) wrote:
> 
>> On Mar 28, 2017, at 8:28 PM, Brian E Carpenter  wrote:
>>
>>> Hence, a context-less ban of
>>> IPv6 extension header insertion does not make sense.
>>
>> RFC2460bis isn't contextless. The context is the Internet and therefore
>> the requirements for interoperable communication between any two nodes on
>> the Internet. I don't see any conflict between that and a additional
>> specification for local use of a feature that does not meet those requirements.
> 
> 
> since we are in the process of updating rfc2460, your statement above could easily be inserted into rfc2460bis.
> 
> s.

As others have said, we a bit far along in the process, but I would actually
agree with that.

    Brian

>  
>>
>> I think this draft would be much easier to consider without that sort
>> of phrasing.
>>
>>    Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> 


From nobody Thu Mar 30 06:51:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E529E126C26 for ; Thu, 30 Mar 2017 06:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 y6ORuRiqHx2k for ; Thu, 30 Mar 2017 06:51:27 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB18B12422F for ; Thu, 30 Mar 2017 06:51:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6133; q=dns/txt; s=iport; t=1490881886; x=1492091486; h=from:to:cc:subject:date:message-id:mime-version; bh=2s1FwqbLlp4KGdCkoJFD/q1FEhDF+coHcoFmTXMObWQ=; b=VCTFG0Iwq1WxbgiQOFcMOquCDHBsUSDxAacxj95iP6tRYDAsbjZBSrDU 2xE5fj+4UJwBl5cYWPnOUfqufkypLk48bhGOydC+QPeMcmS7w+l87ugR2 PgNBIUYTB9Xx50fSgCnSmNWf1pdQ9gYSdQdqOHcaE/LL65st24RJoZ62r Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAgBuDN1Y/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5oYYELg2KKEZFRiBmIBoUxgg4fAQqFeAIagxg/GAECAQEBAQE?= =?us-ascii?q?BAWsdC4UVAQEBAQMBASEKQQsMBgEIBBECASoCBB8GCx0KBA4FCIlrAxUOrXyCJ?= =?us-ascii?q?ocoDYMfAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGToRvglGCGoJvgl8FiSKTDTs?= =?us-ascii?q?BjheEL5FAinKIegEfOIEFWxVBhFkdgWN1AYkTAQEB?=
X-IronPort-AV: E=Sophos;i="5.36,246,1486425600";  d="scan'208,217";a="224863493"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Mar 2017 13:51:26 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2UDpPO1009201 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2017 13:51:25 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 09:51:25 -0400
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 30 Mar 2017 09:51:25 -0400
From: "Stefano Previdi (sprevidi)" 
To: "brian.e.carpenter@gmail.com" 
CC: "ipv6@ietf.org" 
Subject: RE: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Topic: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt
Thread-Index: AQHSqVy4Hx79W8UQkU2Uf5rN/kkGbA==
Date: Thu, 30 Mar 2017 13:51:24 +0000
Message-ID: <8a15fbfc29074328825b0cf92a249057@XCH-RTP-010.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_8a15fbfc29074328825b0cf92a249057XCHRTP010ciscocom_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 13:51:29 -0000

--_000_8a15fbfc29074328825b0cf92a249057XCHRTP010ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXMgSSBjYW4gc2VlLCB0aGlzIHNtYWxsIGNoYW5nZSBjYW4gc3RpbGwgYmUgbWFkZSBpZiB0aGUg
d2cgYWdyZWVzLg0KDQpzLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBC
cmlhbiBFIENhcnBlbnRlciBbYnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KUmVjZWl2ZWQ6
IFRodXJzZGF5LCAzMCBNYXIgMjAxNywgODo0OEFNDQpUbzogU3RlZmFubyBQcmV2aWRpIChzcHJl
dmlkaSkgW3NwcmV2aWRpQGNpc2NvLmNvbV0NCkNDOiA2bWFuIFtpcHY2QGlldGYub3JnXQ0KU3Vi
amVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LXZveWVyLTZtYW4tZXh0ZW5zaW9uLWhlYWRlci1p
bnNlcnRpb24tMDAudHh0DQoNCg0KT24gMzAvMDMvMjAxNyAwOTo1NSwgU3RlZmFubyBQcmV2aWRp
IChzcHJldmlkaSkgd3JvdGU6DQo+DQo+PiBPbiBNYXIgMjgsIDIwMTcsIGF0IDg6MjggUE0sIEJy
aWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPj4N
Cj4+PiBIZW5jZSwgYSBjb250ZXh0LWxlc3MgYmFuIG9mDQo+Pj4gSVB2NiBleHRlbnNpb24gaGVh
ZGVyIGluc2VydGlvbiBkb2VzIG5vdCBtYWtlIHNlbnNlLg0KPj4NCj4+IFJGQzI0NjBiaXMgaXNu
J3QgY29udGV4dGxlc3MuIFRoZSBjb250ZXh0IGlzIHRoZSBJbnRlcm5ldCBhbmQgdGhlcmVmb3Jl
DQo+PiB0aGUgcmVxdWlyZW1lbnRzIGZvciBpbnRlcm9wZXJhYmxlIGNvbW11bmljYXRpb24gYmV0
d2VlbiBhbnkgdHdvIG5vZGVzIG9uDQo+PiB0aGUgSW50ZXJuZXQuIEkgZG9uJ3Qgc2VlIGFueSBj
b25mbGljdCBiZXR3ZWVuIHRoYXQgYW5kIGEgYWRkaXRpb25hbA0KPj4gc3BlY2lmaWNhdGlvbiBm
b3IgbG9jYWwgdXNlIG9mIGEgZmVhdHVyZSB0aGF0IGRvZXMgbm90IG1lZXQgdGhvc2UgcmVxdWly
ZW1lbnRzLg0KPg0KPg0KPiBzaW5jZSB3ZSBhcmUgaW4gdGhlIHByb2Nlc3Mgb2YgdXBkYXRpbmcg
cmZjMjQ2MCwgeW91ciBzdGF0ZW1lbnQgYWJvdmUgY291bGQgZWFzaWx5IGJlIGluc2VydGVkIGlu
dG8gcmZjMjQ2MGJpcy4NCj4NCj4gcy4NCg0KQXMgb3RoZXJzIGhhdmUgc2FpZCwgd2UgYSBiaXQg
ZmFyIGFsb25nIGluIHRoZSBwcm9jZXNzLCBidXQgSSB3b3VsZCBhY3R1YWxseQ0KYWdyZWUgd2l0
aCB0aGF0Lg0KDQogICAgQnJpYW4NCg0KPg0KPj4NCj4+IEkgdGhpbmsgdGhpcyBkcmFmdCB3b3Vs
ZCBiZSBtdWNoIGVhc2llciB0byBjb25zaWRlciB3aXRob3V0IHRoYXQgc29ydA0KPj4gb2YgcGhy
YXNpbmcuDQo+Pg0KPj4gICAgQnJpYW4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gSUVURiBJUHY2
IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+PiBpcHY2QGlldGYub3JnDQo+PiBBZG1pbmlz
dHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p
cHY2DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPg0K

--_000_8a15fbfc29074328825b0cf92a249057XCHRTP010ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <4005FEBE270060498CEFE4A237B9B2D3@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu
dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg
LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl
ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8
L2hlYWQ+DQo8Ym9keT4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLCBBcmlhbCwg
SGVsdmV0aWNhLCBzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0O2NvbG9yOmJsYWNrIj5BcyBJIGNh
biBzZWUsIHRoaXMgc21hbGwgY2hhbmdlIGNhbiBzdGlsbCBiZSBtYWRlIGlmIHRoZSB3ZyBhZ3Jl
ZXMuPGJyPg0KPGJyPg0Kcy48YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxicj4NCjxiPkZyb206PC9iPiBCcmlhbiBF
IENhcnBlbnRlciBbYnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXTxicj4NCjxiPlJlY2VpdmVk
OjwvYj4gVGh1cnNkYXksIDMwIE1hciAyMDE3LCA4OjQ4QU08YnI+DQo8Yj5Ubzo8L2I+IFN0ZWZh
bm8gUHJldmlkaSAoc3ByZXZpZGkpIFtzcHJldmlkaUBjaXNjby5jb21dPGJyPg0KPGI+Q0M6PC9i
PiA2bWFuIFtpcHY2QGlldGYub3JnXTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSS1EIEFjdGlv
bjogZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24taGVhZGVyLWluc2VydGlvbi0wMC50eHQ8YnI+
DQo8YnI+DQo8L3NwYW4+PC9zcGFuPjxicj4NCjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTBwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5PbiAzMC8wMy8yMDE3IDA5
OjU1LCBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZn
dDsmZ3Q7IE9uIE1hciAyOCwgMjAxNywgYXQgODoyOCBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgJmx0
O2JyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0OyZndDsgSGVuY2UsIGEgY29udGV4dC1sZXNzIGJhbiBvZjxicj4NCiZndDsmZ3Q7
Jmd0OyBJUHY2IGV4dGVuc2lvbiBoZWFkZXIgaW5zZXJ0aW9uIGRvZXMgbm90IG1ha2Ugc2Vuc2Uu
PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBSRkMyNDYwYmlzIGlzbid0IGNvbnRleHRsZXNz
LiBUaGUgY29udGV4dCBpcyB0aGUgSW50ZXJuZXQgYW5kIHRoZXJlZm9yZTxicj4NCiZndDsmZ3Q7
IHRoZSByZXF1aXJlbWVudHMgZm9yIGludGVyb3BlcmFibGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVu
IGFueSB0d28gbm9kZXMgb248YnI+DQomZ3Q7Jmd0OyB0aGUgSW50ZXJuZXQuIEkgZG9uJ3Qgc2Vl
IGFueSBjb25mbGljdCBiZXR3ZWVuIHRoYXQgYW5kIGEgYWRkaXRpb25hbDxicj4NCiZndDsmZ3Q7
IHNwZWNpZmljYXRpb24gZm9yIGxvY2FsIHVzZSBvZiBhIGZlYXR1cmUgdGhhdCBkb2VzIG5vdCBt
ZWV0IHRob3NlIHJlcXVpcmVtZW50cy48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBz
aW5jZSB3ZSBhcmUgaW4gdGhlIHByb2Nlc3Mgb2YgdXBkYXRpbmcgcmZjMjQ2MCwgeW91ciBzdGF0
ZW1lbnQgYWJvdmUgY291bGQgZWFzaWx5IGJlIGluc2VydGVkIGludG8gcmZjMjQ2MGJpcy48YnI+
DQomZ3Q7IDxicj4NCiZndDsgcy48YnI+DQo8YnI+DQpBcyBvdGhlcnMgaGF2ZSBzYWlkLCB3ZSBh
IGJpdCBmYXIgYWxvbmcgaW4gdGhlIHByb2Nlc3MsIGJ1dCBJIHdvdWxkIGFjdHVhbGx5PGJyPg0K
YWdyZWUgd2l0aCB0aGF0Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBCcmlhbjxicj4N
Cjxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5rIHRo
aXMgZHJhZnQgd291bGQgYmUgbXVjaCBlYXNpZXIgdG8gY29uc2lkZXIgd2l0aG91dCB0aGF0IHNv
cnQ8YnI+DQomZ3Q7Jmd0OyBvZiBwaHJhc2luZy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJyaWFuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLTxicj4NCiZndDsmZ3Q7IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz
dDxicj4NCiZndDsmZ3Q7IGlwdjZAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyBBZG1pbmlzdHJhdGl2
ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9pcHY2IiB0YXJnZXQ9Il9CTEFOSyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2lwdjY8L2E+PGJyPg0KJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IDxicj4N
CiZndDsgPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_8a15fbfc29074328825b0cf92a249057XCHRTP010ciscocom_--


From nobody Thu Mar 30 07:13:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282E51294D8 for ; Thu, 30 Mar 2017 07:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WaAaZDtJC0lP for ; Thu, 30 Mar 2017 07:13:47 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD1C1293DA for ; Thu, 30 Mar 2017 07:13:47 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id l7so19836127ioe.3 for ; Thu, 30 Mar 2017 07:13:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=aAfiNpGZPUIsWmvPtO/Y9oj2U+ThYymOodEFFbDnMok=; b=i+lpVuVRF88BPuglX5M+whNUP966mGVL0utbGesVjZ/pAK5PacSZYUQuxM6qRmOueG 9OdHQojiQ2HW5n+8pmS5ltj9+RKyjnIpMsC/tH+hSwARqM3dHnA8kyIhEjrOpBvWQOTI fnyFAVpoQdfI7STzp1dmtZEUG2k/L2F7TEGq7com0HQtQ1RACK1K3qe2O7G/7wlDIKE1 SXg24x8NfvkCKgLgFt29Q5KveLA4tWE0Jl236lJ6/qgz2CqZB3G6Tv5FuM8SbcPrAk2X NjLKPnjwZe28TC5C66PiSu6OdtIrCEDNHz30kAf3JkvkLw3Nl+eSFGRy5LJQRleYByOO 7YTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=aAfiNpGZPUIsWmvPtO/Y9oj2U+ThYymOodEFFbDnMok=; b=LlTt9uEPNiwufKc1t4X2XlBFfseXDx0/vWK+kbqAYwzfIg5KvfG1Jeb8GiG5fbQepf IXqNyY6Va32uCArga7yzxMPC4PzOyr5dKjE9htWg9+soNZRhSn+Pqsi+vEOGj9V618nG IQWgbFCoVuAUzbkHwuGiuxoPJhVJCI4wswMsMyd6vDayc9CMwFVH6Q228Kx155ql2K/u ojFTVx8FHgjA/Zt+b165p3mMqZxHiZe+O/PUtAuoJ1/cjGNoJUTxH6M5BLS3ocRCbY2L 8mJwzUMb2if4s4PnH2YOavFNYTPiC7mr2ptw6LVd5F7A+gqrD4ZK0K86FiK6Uv2uJJHz 2GjQ==
X-Gm-Message-State: AFeK/H1IAKDZx7+XriASpYxQqTkPThhIQkQSnqa7fHLoV+ohppGtEvetvexu8nuUrxlIJQ==
X-Received: by 10.107.28.73 with SMTP id c70mr687949ioc.198.1490883226457; Thu, 30 Mar 2017 07:13:46 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 86sm1385776iom.58.2017.03.30.07.13.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 07:13:45 -0700 (PDT)
Subject: Re: 
To: Bob Hinden , IPv6 List 
References: 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <03bf42e7-504c-2dd9-3824-2aec6e83e329@gmail.com>
Date: Fri, 31 Mar 2017 03:13:53 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 14:13:49 -0000

Proposed text change near the end of the Introduction:

OLD:
   This document specifies the basic IPv6 header and the initially-
   defined IPv6 extension headers and options.

NEW:
   This document specifies the basic IPv6 header and the initially-
   defined IPv6 extension headers and options required for interoperable
   communication between any two nodes on the Internet.

Regards
   Brian

On 31/03/2017 02:35, Bob Hinden wrote:
> Hi,
> 
> I published the -09 version of 6man working group draft of rfc2460bis.  Links below.
> 
> The changes in this draft are:
> 
>       Based on results of IETF last call, changed text in Section 4
>       to add clarification that extension headers are not examined,
>       processed, inserted, or deleted by any node along a packet's
>       delivery path.
> 
>       Changed reference from draft-ietf-6man-rfc4291bis to RFC4291
>       because the bis draft won't be advanced as the same time.
> 
>       Revised "Changes since RFC2460" Section to have a summary of
>       changes since RFC2460 and a separate subsection with a change
>       history of each Internet Draft.  This subsection will be
>       removed when the RFC is published.
> 
>       Editorial changes.
> 
> A diff from the -08 version can be found at:
> 
>    https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09
> 
> Please review the changes.
> 
> This is part of the project to move the core IPv6 specifications to Internet Standard.
> 
> Thanks,
> Bob
> 
>> A new version of I-D, draft-ietf-6man-rfc2460bis-09.txt
>> has been successfully submitted by Robert M. Hinden and posted to the
>> IETF repository.
>>
>> Name:		draft-ietf-6man-rfc2460bis
>> Revision:	09
>> Title:		Internet Protocol, Version 6 (IPv6) Specification
>> Document date:	2017-03-30
>> Group:		6man
>> Pages:		41
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-09.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-09
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-09
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09
>>
>> Abstract:
>>   This document specifies version 6 of the Internet Protocol (IPv6).
>>   It obsoletes RFC2460
>>
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Thu Mar 30 07:34:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6F31294E8 for ; Thu, 30 Mar 2017 07:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.696
X-Spam-Level: 
X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=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 UdvpO_uJbpZP for ; Thu, 30 Mar 2017 07:34:26 -0700 (PDT)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3349A128990 for ; Thu, 30 Mar 2017 07:34:26 -0700 (PDT)
Received: from [10.0.0.11] (pD9F10B87.dip0.t-ipconnect.de [217.241.11.135]) by mx.zohomail.com with SMTPS id 1490884462806263.3134445880929; Thu, 30 Mar 2017 07:34:22 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain
From: Dirk Steinberg 
In-Reply-To: 
Date: Thu, 30 Mar 2017 16:34:19 +0200
Cc: 6man WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: Mark Smith 
X-Mailer: Apple Mail (2.3259)
X-ZohoMailClient: External
X-ZohoMail: Z_218543755 SPT_1 Z_218543754 SPT_1 SLF_D
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 14:34:29 -0000

> Am 29.03.2017 um 22:08 schrieb Mark Smith :
>=20
> On 30 March 2017 at 06:58, Mark Smith  wrote:
>> So having further about this, I have fundamental question that it
>> isn't answering.
>>=20
>> Why can't IPv6-in-IPv6 encapsulation be used for this? What is =
missing
>> from IPv6 that "requires" that EH insertion is used instead of much
>> simpler, off-the-shelf encapsulation/decapsulation?
>>=20
>>=20
>>=20
>> For example, using IPv6-in-IPv6 encapsulation, I don't think an SRH =
is
>> needed at all in the "2. Source Domain and Packet Journey" example.
>>=20
>> When node 2 realises that the link between itself and 3 has failed, =
it
>> encapsulates the original SA=3D1, DA=3D9 packet in a new IPv6 header
>> ("tunnelling" it). The new IPv6 header has an SA=3D2, DA=3D5, and is =
sent
>> towards node 4.
>>=20
>> Node 4 forwards the packet onto node 5 using conventional destination
>> address based IPv6 forwarding.
>>=20
>> Node 5 receives the packet, and as it is DA=3D5, decapsulates the =
inner
>> SA=3D1, DA=3D9 packet. Node 5 then submits that packet to the =
standard
>> IPv6 forwarding table, resulting in it being forwarded to Node 3,
>> which then forwards it to Node 9. All of this is happening using
>> conventional IPv6 destination based forwarding.
>>=20
>> Encapsulation is solving this problem by effectively creating a
>> on-demand virtual link or tunnel between Node 2 and Node 5, getting
>> the original packet past the failure point to a point along the
>> original packet's forwarding path. Once there, it pops out of the
>> virtual link and is sent along its way. I don't think the insertion =
of
>> the EH and DA swapping method could be described the same way or =
could
>> be described as simply.
>>=20
>> I think this IP-in-IPv6 encapsulation solution to the above example =
is
>> better because:
>>=20
>> - there is no need for an additional header of any type - the path
>> information is inherent in the DA of the outer IPv6 header when sent
>> to node 5, and in the DA of the inner IPv6 packet (now "the packet")
>> when being sent by node 5 to node 9.
>=20
> To clarify, what I mean by "no need for an additional header of any
> type" is no additional header beyond the IPv6 encapsulation header
> i.e. no SRH EH or similar between the outer and inner IPv6 packets. It
> is the original IPv6 packet inside a vanilla IPv6 packet with the
> outer IPv6 packet=E2=80=99s next header field set to 41.

Following this logic of not using =E2=80=9Ean additional header of any =
type=E2=80=9C leads to
the conclusion that for every entry in an SR policy represented by the=20=

SID list of an SRH, you would instead use one more nested IPv6=20
encapsulation header.=20

In the simple example of section 2 the TI-LFA policy only needs to =
specify=20
one additional node, namely 5 (9 being the original destination), but=20
conceivably the backup policy could be more complex including 3, 4, 5,
or more SIDs. Would you really want to propose that the PLR should
impose, say 4 nested IPv6 encapsulation headers at the same time
while still claiming this to be simpler and/or more efficient?

Let=E2=80=99s face the reality: the cost of adding an IPv6 encapsulation =
header=20
is fairly high and while doing this once may be acceptable in certain =
situations
doing this N times nested is prohibitive both in terms of the burden on =
the
forwarding hardware and in terms of MTU growth. One more entry in
the SID list is just so much more efficient.

This is why in general the recurring argument to just use IPv6 encaps
whenever all you really need is one more entry in the SRH SID list
is completely missing the point.

/Dirk

>> - Encapsulation/Decapsulation performed by nodes 2 and nodes 5 is
>> conventional IPv6-in-IPv6 encapsulation, specified in RFC2473, now
>> nearly 20 years old.
>>=20
>> - In this example, nodes 4, 5 and 3 could be off-the-shelf IPv6
>> devices that support conventional IPv6 forwarding and conventional
>> IPv6-in-IPv6 encapsulation/decapsulation (i.e., "tunnelling").
>>=20
>> - Encapsulation/decapsulation is a simpler, universal and proven
>> operation (literally being done every time an IPv6 packet is being
>> sent and received over any and all layer 2 links)  compared to the DA
>> address swapping that occurs at Nodes 2 and Nodes 5 in the described
>> method.
>>=20
>> More complicated examples would may require more information to be
>> carried about the path between the inner and outer IPv6 headers
>> (although encapsulation inside encapsulation/tunnelling inside
>> tunnelling probably be used at a greater packet overhead host, with
>> simpler per-hop processing), however I don't think this example
>> demonstrates why EH insertion is required.
>>=20
>>=20
>> Regards,
>> Mark.
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



From nobody Thu Mar 30 08:11:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E832B129631; Thu, 30 Mar 2017 08:11:14 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9rsu8kvE3TnC; Thu, 30 Mar 2017 08:11:12 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE06129474; Thu, 30 Mar 2017 08:11:12 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id f84so3166361ioj.0; Thu, 30 Mar 2017 08:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rsRGoBg1Q9hS4Ronww7dPjKGRkcX3T1dDyU0G4abGRs=; b=fqbAqxUX7pHx+nt3W0QV9mc6X+OpXram+Pu/Ht2NcYdbonzTEWSI0DSmPeFWvwwCIO ebIjrHYHw+LYQTCCBwdX7KDgtVRHqLRGjwaWhUlzIdrWKyL1sAOXTZp/QxU+hvJW5Ftd lnkIXNpGtN19qsLDWyLhLG+pCtA4XNDnMx8YgcSS5UGmHHMGjK+9VUwFoaXV+1O5SlAu /C5t2WdkmfSd/1m6yq8iPr7aMBTgfX2VqSyUUH+2IGbV8ZSC8T4SqRVGPuKFps5uRxlB svs4KpThR+paJRD/asNsVvl5dS36yhAuYlCO8Wq4hhZz5oubD6re1Afw8WI20NfFaJGh o4Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=rsRGoBg1Q9hS4Ronww7dPjKGRkcX3T1dDyU0G4abGRs=; b=f8ps8D9b3MyDm2yJIfGVFBym/McPO9/3oYAgjplwMStNsnRp4v/MDO9dorPS2dx32l z9EM8rKzHVSSixpw+vYoL6b7RxKnUgWX6CAymSvxXR6RWdfsF+GOM3Q2is/SKnjBcklF lSremBxoT/YI39KyYHnrxVeFsNcm5f7DB5TFWe3MLfQ49Zn7HlkFaX+bLBjXSPEzCcIf NBPAr6VlsvZqjpHky/VJBFQNYqso07wOPdrNUi9+zDJ5Koxez5ysL3wXi9X48iw88xQ4 ferUoIKeSrApGPfuypWrDeWvfXkVuE5i0cH1X2gyTb8NiwM/GrcYjT5XW8NE+YIgZZqX 5R7g==
X-Gm-Message-State: AFeK/H0nC6Vkm1celwrSRknfW5A0zHejXYh8DjWIJ7WuTdYfiL/o9ZZVf/J2HyC5h7uxNg==
X-Received: by 10.107.22.194 with SMTP id 185mr963301iow.122.1490886672188; Thu, 30 Mar 2017 08:11:12 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 89sm1474063ioj.17.2017.03.30.08.11.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 08:11:11 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Jeff Tantsura , "Leddy, John" , "suresh.krishnan@ericsson.com" 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com>
Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man , IETF discussion list 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>
Date: Fri, 31 Mar 2017 04:11:19 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 15:11:15 -0000

On 31/03/2017 02:11, Jeff Tantsura wrote:
> Brian,
>=20
> if I understand you correctly:=20
>=20
> If properly worded (improved) draft-voyer explicitly states =E2=80=93 t=
he intention is to change the 2460(bis) behavior and to allow header inse=
rtion within a controlled domain, and given there=E2=80=99s a valid justi=
fication of why encap wouldn=E2=80=99t=E2=80=99 meet the need, you wouldn=
=E2=80=99t oppose?=20

No, I wouldn't. I might even help; hence my suggested tweak to 2460bis. N=
ote that the tricky bit (in reality and in the text) is a crisp definitio=
n of what the domain boundary is and what happens when packets with inser=
ted headers accidentally escape. We did hit that difficulty when trying (=
and failing) to define local-use rules for stateful use of the flow label=
=2E But we were trying to do that in a generic document (in effect, an ex=
tension of RFC2460) and failed for essentially the same reasons that led =
Suresh to his decision on 2460bis.

https://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 shows some re=
mnants of that attempt.

    Brian


>=20
> Thanks!=20
>=20
> Cheers,
> Jeff
>=20
> On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter"  wrote:
>=20
>     On 30/03/2017 15:59, Leddy, John wrote:
>    =20
>     ...
>     > If this insert/delete of an SRH is prematurely prohibited;  What =
is a recommended solution to the Real World problem above.  Not use case,=
 we are implementing.
>     >=20
>     > Again; I=E2=80=99m worried we are eliminating a tool that may pro=
ve very helpful, preclude its use in future IETF work and shutdown a path=
 for Innovation in Networking,
>    =20
>     I've tried to say this before but I'm not sure people are getting i=
t:=20
>    =20
>     RFC2460bis, if approved as is, draws a line in the sand *for intero=
perability across the whole Internet*. There are reasons for this - PMTUD=
 in any form, any future replacement for the unsuccessful IPsec/AH, and a=
ll the problems of deploying extension headers that are understood by som=
e nodes and not by others.=20
>    =20
>     There is no reason why a subsequent standards-track document cannot=
 allow header insertion (and removal) within finite domains where the abo=
ve issues do not apply. In fact, an improved version of draft-voyer-6man-=
extension-header-insertion-00 could become exactly that.
>    =20
>     There doesn't need to be a tussle here.=20
>    =20
>        Brian Carpenter
>    =20
>    =20
>=20
>=20
>=20


From nobody Thu Mar 30 08:31:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2687E129512; Thu, 30 Mar 2017 08:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 z-wSdaCu5cGS; Thu, 30 Mar 2017 08:31:06 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD5C129533; Thu, 30 Mar 2017 08:31:04 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id y18so78460637itc.1; Thu, 30 Mar 2017 08:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=b5zLQECnWrxvR4MOa5o3fJnL2vxvJEobnElGydwPSqs=; b=ZwLiwNin+0sYnmDZm0o1bE0x3tRdCCZQgfTRVn0lOVvon+k8Te1gNEMvQP6NY01HLu nuvjZS3Os0Wyc1WkQthgnWWF02uS12DoTFGmh1kedIHTbWqajvn82vuj94t9ToOTnqom tbf/mQO47R34XZiGud+6dShTN9TkJY09KJNhxiYvj7IlIhNAihP7VEMe+OgnQsjZEhgx htKUq3Q68RFxKpVnwhoca0CQvaSd8vuEeR/iIDH3Z661irF94H50/xhM7rI20ieE8Lpl Uw2diNLwziP+Bg+FZ3duV22+UlijtHtGcy3umpHoiwpHJlGLkMO7t3YBm8fxr9gXZWOh FQxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=b5zLQECnWrxvR4MOa5o3fJnL2vxvJEobnElGydwPSqs=; b=BDa1jU9ZXmrHmhufcHAcSpO/VkxlvN5QxvZNhyJP33Ug0KZsPIibG6xHXAP4QgDt7D IRqy3GUpzwRWaDUl6hGKn+zvDy6xs1Bnk0RiR2RHxjZBmAwH5vz8Qiine2BDCplT97AF 1W2y4pexSE+Xy+7TV5mdPhGp9TDxQ1gHMaj8vgsemrPj7u0/H2WzivfnjUHhGQrRQcsk 4Ue2t6651cuY7vKVXb08vbO1rONqLHC5xO9LC2ergmRej52mgDgoKZiYuz7AU9aPTYk2 JZ4rDtTYeZ7klL0xjaZhIxcxgfJN7ML/s1lio9WfPcigIA9evNepXZmirjXAVckqxoDv EtYQ==
X-Gm-Message-State: AFeK/H2p/wFG4/g5jd8Dc37K5XGFdup5+zksyRRLGSCwAU6kiDoBmJBjMThtzvd0rdOx83svTpeNnwd3pd8+fA==
X-Received: by 10.36.65.203 with SMTP id b72mr5036732itd.24.1490887863519; Thu, 30 Mar 2017 08:31:03 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 08:31:02 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 08:31:02 -0700 (PDT)
In-Reply-To: <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>
From: Robert Raszuk 
Date: Thu, 30 Mar 2017 10:31:02 -0500
X-Google-Sender-Auth: W1jS1pmtbL_4D912WoIZdG-CEFw
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Brian E Carpenter 
Cc: "Leddy, John" , IETF Discussion ,  "suresh.krishnan@ericsson.com" , 6man , "draft-ietf-6man-rfc2460bis.all@ietf.org" ,  Jeff Tantsura 
Content-Type: multipart/alternative; boundary=001a1143f4348163aa054bf461e5
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 15:31:09 -0000

--001a1143f4348163aa054bf461e5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Brian,

Could you elaborate a bit on the definition of "accidentally escaping
packets" ?

The fundamental issue with original Suresh suggestion I see is that his
proposed text kills ability to have 2460bis as normative reference in any
other draft describing or defining extension headers. And effectively stops
any work which needs to be based on 2460bis till 2460bis is updated.

Kind regards
R.






On Mar 30, 2017 10:11, "Brian E Carpenter" 
wrote:

On 31/03/2017 02:11, Jeff Tantsura wrote:
> Brian,
>
> if I understand you correctly:
>
> If properly worded (improved) draft-voyer explicitly states =E2=80=93 the
intention is to change the 2460(bis) behavior and to allow header insertion
within a controlled domain, and given there=E2=80=99s a valid justification=
 of why
encap wouldn=E2=80=99t=E2=80=99 meet the need, you wouldn=E2=80=99t oppose?

No, I wouldn't. I might even help; hence my suggested tweak to 2460bis.
Note that the tricky bit (in reality and in the text) is a crisp definition
of what the domain boundary is and what happens when packets with inserted
headers accidentally escape. We did hit that difficulty when trying (and
failing) to define local-use rules for stateful use of the flow label. But
we were trying to do that in a generic document (in effect, an extension of
RFC2460) and failed for essentially the same reasons that led Suresh to his
decision on 2460bis.

https://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 shows some
remnants of that attempt.

    Brian


>
> Thanks!
>
> Cheers,
> Jeff
>
> On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <
ietf-bounces@ietf.org on behalf of brian.e.carpenter@gmail.com> wrote:
>
>     On 30/03/2017 15:59, Leddy, John wrote:
>
>     ...
>     > If this insert/delete of an SRH is prematurely prohibited;  What is
a recommended solution to the Real World problem above.  Not use case, we
are implementing.
>     >
>     > Again; I=E2=80=99m worried we are eliminating a tool that may prove=
 very
helpful, preclude its use in future IETF work and shutdown a path for
Innovation in Networking,
>
>     I've tried to say this before but I'm not sure people are getting it:
>
>     RFC2460bis, if approved as is, draws a line in the sand *for
interoperability across the whole Internet*. There are reasons for this -
PMTUD in any form, any future replacement for the unsuccessful IPsec/AH,
and all the problems of deploying extension headers that are understood by
some nodes and not by others.
>
>     There is no reason why a subsequent standards-track document cannot
allow header insertion (and removal) within finite domains where the above
issues do not apply. In fact, an improved version of
draft-voyer-6man-extension-header-insertion-00 could become exactly that.
>
>     There doesn't need to be a tussle here.
>
>        Brian Carpenter
>
>
>
>
>

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

--001a1143f4348163aa054bf461e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Hi Brian,

    Co=
uld you elaborate a bit on the definition of "accidentally escaping pa=
ckets" ?

    The fundam=
ental issue with original Suresh suggestion I see is that his proposed text=
 kills ability to have 2460bis as normative reference in any other draft de=
scribing or defining extension headers. And effectively stops any work whic=
h needs to be based on 2460bis till 2460bis is updated.

    Kind regards
    R.


    =




    On Mar 30, 2017 10:11, "Brian E =
Carpenter" <brian.e.=
carpenter@gmail.com> wrote:
    On 31/03/2017 02:11, Jeff Tantsura wrot=
e:
    
> Brian,
    
>
    
> if I understand you correctly:
    
>
    
> If properly worded (improved) draft-voyer explicitly states =E2=80=93 =
the intention is to change the 2460(bis) behavior and to allow header inser=
tion within a controlled domain, and given there=E2=80=99s a valid justific=
ation of why encap wouldn=E2=80=99t=E2=80=99 meet the need, you wouldn=E2=
=80=99t oppose?
    

    

    No, I wouldn't. I might even help; hence my suggested tweak to 24=
60bis. Note that the tricky bit (in reality and in the text) is a crisp def=
inition of what the domain boundary is and what happens when packets with i=
nserted headers accidentally escape. We did hit that difficulty when trying=
 (and failing) to define local-use rules for stateful use of the flow label=
. But we were trying to do that in a generic document (in effect, an extens=
ion of RFC2460) and failed for essentially the same reasons that led Suresh=
 to his decision on 2460bis.
    

    
https://tools.ietf.org/html/draft-ie=
tf-6man-flow-3697bis-01 shows some remnants of that attempt.
    

    
=C2=A0 =C2=A0 Brian
    


    

    
>
    
> Thanks!
    
>
    
> Cheers,
    
> Jeff
    
>
    
> On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <=
;ietf-bounces@ietf.org on beha=
lf of brian.e.carpenter@gmai=
l.com> wrote:
    
>
    
>=C2=A0 =C2=A0 =C2=A0On 30/03/2017 15:59, Leddy, John wrote:
    
>
    
>=C2=A0 =C2=A0 =C2=A0...
    
>=C2=A0 =C2=A0 =C2=A0> If this insert/delete of an SRH is prematurely=
 prohibited;=C2=A0 What is a recommended solution to the Real World problem=
 above.=C2=A0 Not use case, we are implementing.
    
>=C2=A0 =C2=A0 =C2=A0>
    
>=C2=A0 =C2=A0 =C2=A0> Again; I=E2=80=99m worried we are eliminating =
a tool that may prove very helpful, preclude its use in future IETF work an=
d shutdown a path for Innovation in Networking,
    
>
    
>=C2=A0 =C2=A0 =C2=A0I've tried to say this before but I'm not s=
ure people are getting it:
    
>
    
>=C2=A0 =C2=A0 =C2=A0RFC2460bis, if approved as is, draws a line in the =
sand *for interoperability across the whole Internet*. There are reasons fo=
r this - PMTUD in any form, any future replacement for the unsuccessful IPs=
ec/AH, and all the problems of deploying extension headers that are underst=
ood by some nodes and not by others.
    
>
    
>=C2=A0 =C2=A0 =C2=A0There is no reason why a subsequent standards-track=
 document cannot allow header insertion (and removal) within finite domains=
 where the above issues do not apply. In fact, an improved version of draft=
-voyer-6man-extension-header-insertion-00 could become exactly that.
>
    
>=C2=A0 =C2=A0 =C2=A0There doesn't need to be a tussle here.
    
>
    
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Brian Carpenter
    
>
    
>
    
>
    
>
    
>
    

    

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


    

--001a1143f4348163aa054bf461e5--


From nobody Thu Mar 30 08:47:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD3F1296CF; Thu, 30 Mar 2017 08:47:38 -0700 (PDT)
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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xjJ1IpA8KSDv; Thu, 30 Mar 2017 08:47:35 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CB512996E; Thu, 30 Mar 2017 08:47:34 -0700 (PDT)
X-AuditID: c618062d-d73ff700000009d8-65-58dd3a3b4622
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by  (Symantec Mail Security) with SMTP id 87.32.02520.B3A3DD85; Thu, 30 Mar 2017 19:02:54 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0339.000; Thu, 30 Mar 2017 11:47:28 -0400
From: Suresh Krishnan 
To: Robert Raszuk 
CC: Brian E Carpenter , "Leddy, John" , IETF Discussion , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" , Jeff Tantsura 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv86cghjjmGk6P6rsvHH5Q4qGssVmAgAD+BwCAAAesgIAAIVmAgAAFgwCAAASPgA==
Date: Thu, 30 Mar 2017 15:47:22 +0000
Message-ID: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: multipart/signed; boundary="Apple-Mail=_0B3335B8-A35C-497C-A6BC-E72F064D784D"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUyuXSPt66d1d0Ig+WHpC3aLu5jsnj19hqb xbON81ksXp59D+R2/GSyWLpgOZNF08ImZgd2j+udLcweO2fdZfdYsuQnk8fujQuYAliiuGxS UnMyy1KL9O0SuDK6r65lLlhhXLH/0gfGBsanBl2MnBwSAiYS9x4tZOpi5OIQEtjAKPHg020W CGc5o8THD23sIFVsQFUbdn5mArFFBFQlOk88YgYpYhaYzSSx+vQDNpCEsICHxKRN11ggijwl 1m08DGWHSZx4+owVxGYBaj637jeQzcHBK2AvseSYKMSyXmaJVQ9Pg83hFAiUWN+3kRHEZhQQ k/h+ag3YYmYBcYlbT+YzQZwtIvHwIkS9hICoxMvH/1ghbCWJj7/ns0PUT2GUaHnrCmLzCghK nJz5hGUCo8gsJKNmISmbhaQMIq4tsWzha+ZZQKcyC+hITF7ICBE2lXh99COUbS0x49dBNghb UWJK90P2BYwcqxg5SosLcnLTjQw2MQKj85gEm+4OxvvTPQ8xCnAwKvHwPth7O0KINbGsuDL3 EKMKUOujDasvMEqx5OXnpSqJ8Fqo3Y0Q4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjvh/IUIIYH0 xJLU7NTUgtQimCwTB6dUA2OwloWH55wlXy+/CnSYYHzzztaMKdZ3Xt2ZHvnqxPqS5YEa7y90 i0suTY7f8mLeZJadUb8XvtyWZ5buMufT9Ic+au+lTt9O+rnpq6uBYHljbdSrOTfersh7XLf7 UK+Kn9B73vlH0n+/qVDIqf3uNT13igZX1cRNItPK3ipFHvpTt7/fcPs3+2ltSizFGYmGWsxF xYkAKHy0DdYCAAA=
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 15:47:39 -0000

--Apple-Mail=_0B3335B8-A35C-497C-A6BC-E72F064D784D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Robert,

> On Mar 30, 2017, at 10:31 AM, Robert Raszuk  wrote:
>=20
> Hi Brian,
>=20
> Could you elaborate a bit on the definition of "accidentally escaping =
packets" ?
>=20
> The fundamental issue with original Suresh suggestion I see is that =
his proposed text kills ability to have 2460bis as normative reference =
in any other draft describing or defining extension headers. And =
effectively stops any work which needs to be based on 2460bis till =
2460bis is updated.

This is not true. The *new draft* will update RFC2460bis. We do not need =
a new (RFC2460bis)bis to do this. I can understand that this would be =
bad, but that is not the intent.

Thanks
Suresh=

--Apple-Mail=_0B3335B8-A35C-497C-A6BC-E72F064D784D
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw
ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy
aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5
MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz
aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ
MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C
oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg
ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+
SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI
MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O
nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6
Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG
AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp
ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD
VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5
LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G
yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL
B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU
Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc
4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG
H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn
78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r
WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz
Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO
NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb
Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR
AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3
MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp
ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1
3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE
9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp
usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq
qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um
0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI
4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N
V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta
IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj
NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB
igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy
YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv
bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww
SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50
ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50
ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/
SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H
IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp
Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG
x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj
9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55
JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj
SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk
9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7
RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA
Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC
mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzMwMTU0NzIyWjAjBgkqhkiG9w0B
CQQxFgQUcN3EfN3JyKPngQtde2ontD6hFRcwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF
cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa
99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG
9w0BAQEFAASCAQBUAaE2yv1TI1LeVe6uKL9ota71E7H36U6X8PMC68rl1GYv2XRwliaxa9DqGIJx
vHG1RcCx+Vbam3W7CPs7PwvCk6X0EBy+ooVGUa87CqL0wobjVhsz6dGOY11Mx5671yahl84yz7wc
22YJXRbODpQEt9Q9FR97OLbiBMf7tx7+SKyoeRG18/U1thA3JKLSEYIDEkQhEU25GumcvAGDncFO
1wKOujDbZxAltgduYeYDBfMVuqgbHcQQxjkSKsv5yT//6d7z3FopFTE/tkE9NfkMCV6b+t8Rw//j
pDy763NIkdwpijR5bhjSLlzIy6lQoSZJ1CdC30ISn93B7JX/z87dAAAAAAAA

--Apple-Mail=_0B3335B8-A35C-497C-A6BC-E72F064D784D--


From nobody Thu Mar 30 08:49:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94B412952C for ; Thu, 30 Mar 2017 08:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.332
X-Spam-Level: 
X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 FJ9P1PgtFRWJ for ; Thu, 30 Mar 2017 08:49:18 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD67A128BE1 for ; Thu, 30 Mar 2017 08:49:17 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2UFnFvl010277 for ; Thu, 30 Mar 2017 17:49:15 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CAE47209041 for ; Thu, 30 Mar 2017 17:49:15 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BF046208EE5 for ; Thu, 30 Mar 2017 17:49:15 +0200 (CEST)
Received: from [132.166.85.9] ([132.166.85.9]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2UFnEeQ013443 for ; Thu, 30 Mar 2017 17:49:15 +0200
Subject: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02
References: 
To: ipv6@ietf.org
From: Alexandre Petrescu 
Message-ID: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com>
Date: Thu, 30 Mar 2017 10:48:59 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E7A6AA9C5831E23213EC3616"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 15:49:21 -0000

This is a multi-part message in MIME format.
--------------E7A6AA9C5831E23213EC3616
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi, authors of PIO-X,

My comment on the microphone:

This is an earlier draft I co-authored that uses RS/RA messages to do 
Prefix Delegation.

draft-kaiser-nd-pd-02

https://tools.ietf.org/html/draft-kaiser-nd-pd-02


I can resurrect it if necessary.

Alex


Le 28/03/2017 à 11:57, Alexandre Petrescu a écrit :
> In addition to asking how is this draft helping with DHCPv6 Prefix 
> Delegation,
>
> I suggest addition of the following references.
>
> Where draft-pioxfolks-6man-pio-exclusive-bit-01 says:
> >    There are several initiatives that propose network side practices
> >    that provide customer isolation, enhanced operational scalability,
> >    power efficiency, security and other benefits in IPv6 network
> >    deployments.  Some of these involve isolating a host (or RA accepting
> >    client node) so that the host is the only node to receive a specific
> >    prefix, including
> >
> >    o  DHCPv6 Prefix Delegation to hosts ( >       draft-templin-v6ops-pdhost>), and
> >
> >    o  advertising a unique prefix per host via unique RAs.
> >       ( >       per-host>).
>
> it makes sense to add:
>
>     o  Prefix Delegation extensions to ND protocol have been introduced
>        in ,         option-00> and , and
>        probably earlier.
>
> Alex
>
> Le 04/03/2017 à 06:31, Alexandre Petrescu a écrit :
> > I do not oppose a slot presenting PIO-X if time allows.
> >
> > However, as I understand it, PIO-X has a single goal - that to
> > accomodate 64share.
> >
> > I wonder whether PIO-X could work with DHCPv6-PD?  Would PIO-X help
> > DHCPv6-PD deployment?
> >
> > This is what I am going to ask at the mic.
> >
> > Alex
> >
> >
> >
> > Le 01/03/2017 à 11:27, Erik Kline a écrit :
> >> Ole,
> >>
> >> It's on me to get a -02 of PIO-X written and uploaded.  Might it be
> >> possible to get 5 minutes on that?
> >>
> >> -ek
> >>
> >> On 27 February 2017 at 06:16,  
> >> >> wrote:
> >>
> >>     The 6MAN chairs are planning the meeting in Chicago at IETF98.
> >>
> >>     If you have a draft you would like to discuss, please send your
> >>     request for agenda time to the 6man chairs. Please include in the
> >>     request, the title of the presentation, file name of the draft, the
> >>     speaker's name (and email), and how much time you would like.
> >>
> >>     We will prioritise drafts that are working group items and drafts
> >>     that have been actively discussed on the list.
> >>
> >>     We expect at least half of each talk’s presentation time to be used
> >>     for open discussion,
> >>     please plan your presentation accordingly.
> >>
> >>     New drafts not discussed on the mailing list prior to the meeting,
> >>     or drafts that do not appear to have support from the working group
> >>     are unlikely to get time at the meeting.
> >>
> >>     Please have agenda items to us by 2017-03-15.
> >>
> >>     Regards,
> >>
> >>     Bob & Ole
> >>
> >> --------------------------------------------------------------------
> >>     IETF IPv6 working group mailing list
> >> ipv6@ietf.org   >
> >>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>     
> >> --------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org 
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org 
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------E7A6AA9C5831E23213EC3616
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    Hi, authors of PIO-X,
    
    
    My comment on the
          microphone:
    
    
    This is an earlier draft
          I co-authored that uses RS/RA messages to do Prefix Delegation.
    
    
    draft-kaiser-nd-pd-02
    
    
    https://tools.ietf.org/html/draft-kaiser-nd-pd-02
    
    

    
          I can resurrect it if necessary.
    
        
    
    
    Alex
    
        
    
    
    
    
    Le 28/03/2017 à 11:57, Alexandre
      Petrescu a écrit :
    
    
    
    
    
      
      
    In addition to
          asking how is this draft helping with DHCPv6 Prefix
          Delegation,
    
          
    
          I suggest addition of the following references.
    
          
    
          Where draft-pioxfolks-6man-pio-exclusive-bit-01 says:
    
          >    There are several initiatives that propose network
          side practices
    
          >    that provide customer isolation, enhanced operational
          scalability,
    
          >    power efficiency, security and other benefits in IPv6
          network
    
          >    deployments.  Some of these involve isolating a host
          (or RA accepting
    
          >    client node) so that the host is the only node to
          receive a specific
    
          >    prefix, including
    
          > 
    
          >    o  DHCPv6 Prefix Delegation to hosts (<https://tools.ietf.org/html/
    
          >       draft-templin-v6ops-pdhost>), and
    
          > 
    
          >    o  advertising a unique prefix per host via unique
          RAs.
    
          >       (<https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-
    
          >       per-host>).
    
          
    
          it makes sense to add:
    
          
    
              o  Prefix Delegation extensions to ND protocol have been
          introduced 
    
                 in <draft-kaiser-nd-pd-02>,
          <draft-lutchann-ipv6-delegate-
    
                 option-00> and
          <draft-haberman-ipngwg-auto-prefix-02>, and 
    
                 probably earlier.
    
          
    
          Alex
    
          
    
          Le 04/03/2017 à 06:31, Alexandre Petrescu a écrit :
    
          > I do not oppose a slot presenting PIO-X if time allows.
    
          > 
    
          > However, as I understand it, PIO-X has a single goal -
          that to
    
          > accomodate 64share.
    
          > 
    
          > I wonder whether PIO-X could work with DHCPv6-PD?  Would
          PIO-X help
    
          > DHCPv6-PD deployment?
    
          > 
    
          > This is what I am going to ask at the mic.
    
          > 
    
          > Alex
    
          > 
    
          > 
    
          > 
    
          > Le 01/03/2017 à 11:27, Erik Kline a écrit :
    
          >> Ole,
    
          >>
    
          >> It's on me to get a -02 of PIO-X written and
          uploaded.  Might it be
    
          >> possible to get 5 minutes on that?
    
          >>
    
          >> -ek
    
          >>
    
          >> On 27 February 2017 at 06:16, <otroan@employees.org
    
          >> <mailto:otroan@employees.org>>
          wrote:
    
          >>
    
          >>     The 6MAN chairs are planning the meeting in
          Chicago at IETF98.
    
          >>
    
          >>     If you have a draft you would like to discuss,
          please send your
    
          >>     request for agenda time to the 6man chairs.  
          Please include in the
    
          >>     request, the title of the presentation, file name
          of the draft, the
    
          >>     speaker's name (and email), and how much time you
          would like.
    
          >>
    
          >>     We will prioritise drafts that are working group
          items and drafts
    
          >>     that have been actively discussed on the list.
    
          >>
    
          >>     We expect at least half of each talk’s
          presentation time to be used
    
          >>     for open discussion,
    
          >>     please plan your presentation accordingly.
    
          >>
    
          >>     New drafts not discussed on the mailing list
          prior to the meeting,
    
          >>     or drafts that do not appear to have support from
          the working group
    
          >>     are unlikely to get time at the meeting.
    
          >>
    
          >>     Please have agenda items to us by 2017-03-15.
    
          >>
    
          >>     Regards,
    
          >>
    
          >>     Bob & Ole
    
          >>
    
          >>    
          --------------------------------------------------------------------
    
          >>     IETF IPv6 working group mailing list
    
          >>     ipv6@ietf.org <mailto:ipv6@ietf.org>
    
          >>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    
          >>     <https://www.ietf.org/mailman/listinfo/ipv6>
    
          >>    
          --------------------------------------------------------------------
    
          >>
    
          >>
    
          >>
    
          >>
    
          >>
          --------------------------------------------------------------------
    
          >> IETF IPv6 working group mailing list
    
          >> ipv6@ietf.org
    
          >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    
          >>
          --------------------------------------------------------------------
    
          >>
    
          > 
    
          >
          --------------------------------------------------------------------
    
          > IETF IPv6 working group mailing list
    
          > ipv6@ietf.org
    
          > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    
          >
          --------------------------------------------------------------------
    
          > 
    
        
    
      
    
      
    
      
    
      
    
      
    --------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

    
    
    
    
    
  


--------------E7A6AA9C5831E23213EC3616--


From nobody Thu Mar 30 08:58:59 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57AF128990; Thu, 30 Mar 2017 08:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RH1uoj45dYgp; Thu, 30 Mar 2017 08:58:49 -0700 (PDT)
Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8540B126C3D; Thu, 30 Mar 2017 08:58:49 -0700 (PDT)
Received: by mail-io0-x241.google.com with SMTP id f84so3303497ioj.0; Thu, 30 Mar 2017 08:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tCZ/F9hXmSCQ2Jyo/Dj81IAlMYc45elag7ntOcbZKc0=; b=hmsh1LhmQBQ1J/3Gmth307ahbqBmgJ7o5mC1zceA0B1zfEn+s27w63iTiYyFXIbzuh YK4rjBKWLnXEdWgCAcyY98zDImxbRN9Hhu80HgXEkwiuMUYjtb+0UH/Z7QMAqiLas7eJ idN/YReYNl84b2ax9VA/QRIH3SjX/h5qoLgYXk2hgNPYMbtvrwtv0qSGFxZg4eyjJ5/G V8+l0J3nmSvw/tsN7b4aEk6fkuEEh0TRrN0oO1TsEU4TheNlv9/9ovmV3kelqH9G5Vn+ IQbT6dzy9oBMXVLyQAorLkpztcUuNJGTtTcSDLk37If4KHIKLbo9JxGTQmuC2S5MSGjE PAUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=tCZ/F9hXmSCQ2Jyo/Dj81IAlMYc45elag7ntOcbZKc0=; b=JFtLb9ZXXs3WusZWspYxpJAfE2kxjIL0kx38t9oFd5JLyCLiMhjxvePZTfV7wePT2u 2Ao6blK7o87LKTYNV5T+5DbXKBb+y078LAQblLL8/YVvd7iMI+5ehPA11BmgkV5FA96F H75DFP6XIHuUsQ+fmMThlSwmoJqzVfdoWCnye8TG+cUjUL2fZoo4djNuHpcb01osABiO K+oNMhwQ4BhWdt+7tEReiwe62we/NB/l8511dAndu37f1c7MuBMGDb50u1XalBWX2n68 NxtoRQxdEGc/5lx/YYHgDUvrVvKXiYmzavm7nXvgAeldLd4TLe2B1FkyHdNpmfPyDovT iYjg==
X-Gm-Message-State: AFeK/H2/6lzfhXJGyq+7t4T7yPeCrNn9lcgjFavKDnm5xnSl37zJ/cjDpMnwDWOICeFibA==
X-Received: by 10.107.132.74 with SMTP id g71mr1208158iod.174.1490889528785; Thu, 30 Mar 2017 08:58:48 -0700 (PDT)
Received: from [31.133.134.152] (dhcp-8698.meeting.ietf.org. [31.133.134.152]) by smtp.gmail.com with ESMTPSA id 78sm1543546ity.7.2017.03.30.08.58.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 08:58:47 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Robert Raszuk 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> 
Cc: "Leddy, John" , IETF Discussion , "suresh.krishnan@ericsson.com" , 6man , "draft-ietf-6man-rfc2460bis.all@ietf.org" , Jeff Tantsura 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <517fb98e-49ab-6a00-fdbb-9c9b7c6edbd5@gmail.com>
Date: Fri, 31 Mar 2017 04:58:52 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 15:58:52 -0000

Hi Robert,

On 31/03/2017 04:31, Robert Raszuk wrote:
> Hi Brian,
>=20
> Could you elaborate a bit on the definition of "accidentally escaping
> packets" ?

There was concern that configuration errors are always possible, so a
a host might send packets with stateful flow labels to an external
destination (first error) and the border router might fail to block
them (second error). I think your case is a bit different.

(I have a meeting this afternoon with some people who want to
define a local use of flow labels compatibly with RFC6437. These
arguments span many years.)
=20
> The fundamental issue with original Suresh suggestion I see is that his=

> proposed text kills ability to have 2460bis as normative reference in a=
ny
> other draft describing or defining extension headers. And effectively s=
tops
> any work which needs to be based on 2460bis till 2460bis is updated.

No, that's a misunderstanding of how RFC spaghetti is constructed. What w=
e'd
do is produce (I'm making this up) draft-ietf-6man-extension-header-inser=
tion
which includes an Updates: 2460bis header. If approved, it becomes a Prop=
osed
Standard that updates an Internet Standard. And it says, quite explicitly=
,
something like:

"Within a network domain defined as in Section N, there is an additional
exception to the following rule in Section 4 of [RFC2460bis]:

    
   With one exception, extension headers are not examined, processed,
   inserted, or deleted by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.

    
The exception is that..."

That's what I meant about 2460bis being a line in the *sand* in
another message. Not carved in stone.

    Brian

>=20
> Kind regards
> R.
>=20
>=20
>=20
>=20
>=20
>=20
> On Mar 30, 2017 10:11, "Brian E Carpenter" 
> wrote:
>=20
> On 31/03/2017 02:11, Jeff Tantsura wrote:
>> Brian,
>>
>> if I understand you correctly:
>>
>> If properly worded (improved) draft-voyer explicitly states =E2=80=93 =
the
> intention is to change the 2460(bis) behavior and to allow header inser=
tion
> within a controlled domain, and given there=E2=80=99s a valid justifica=
tion of why
> encap wouldn=E2=80=99t=E2=80=99 meet the need, you wouldn=E2=80=99t opp=
ose?
>=20
> No, I wouldn't. I might even help; hence my suggested tweak to 2460bis.=

> Note that the tricky bit (in reality and in the text) is a crisp defini=
tion
> of what the domain boundary is and what happens when packets with inser=
ted
> headers accidentally escape. We did hit that difficulty when trying (an=
d
> failing) to define local-use rules for stateful use of the flow label. =
But
> we were trying to do that in a generic document (in effect, an extensio=
n of
> RFC2460) and failed for essentially the same reasons that led Suresh to=
 his
> decision on 2460bis.
>=20
> https://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 shows some
> remnants of that attempt.
>=20
>     Brian
>=20
>=20
>>
>> Thanks!
>>
>> Cheers,
>> Jeff
>>
>> On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <
> ietf-bounces@ietf.org on behalf of brian.e.carpenter@gmail.com> wrote:
>>
>>     On 30/03/2017 15:59, Leddy, John wrote:
>>
>>     ...
>>     > If this insert/delete of an SRH is prematurely prohibited;  What=
 is
> a recommended solution to the Real World problem above.  Not use case, =
we
> are implementing.
>>     >
>>     > Again; I=E2=80=99m worried we are eliminating a tool that may pr=
ove very
> helpful, preclude its use in future IETF work and shutdown a path for
> Innovation in Networking,
>>
>>     I've tried to say this before but I'm not sure people are getting =
it:
>>
>>     RFC2460bis, if approved as is, draws a line in the sand *for
> interoperability across the whole Internet*. There are reasons for this=
 -
> PMTUD in any form, any future replacement for the unsuccessful IPsec/AH=
,
> and all the problems of deploying extension headers that are understood=
 by
> some nodes and not by others.
>>
>>     There is no reason why a subsequent standards-track document canno=
t
> allow header insertion (and removal) within finite domains where the ab=
ove
> issues do not apply. In fact, an improved version of
> draft-voyer-6man-extension-header-insertion-00 could become exactly tha=
t.
>>
>>     There doesn't need to be a tussle here.
>>
>>        Brian Carpenter
>>
>>
>>
>>
>>
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Thu Mar 30 09:52:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D19129865; Thu, 30 Mar 2017 09:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 FxviwNm4HTfj; Thu, 30 Mar 2017 09:52:43 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889F212953C; Thu, 30 Mar 2017 09:52:43 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id z13so23235781iof.2; Thu, 30 Mar 2017 09:52:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SDNfM87Oz/fWUEPB3/KHz/tM0fzfo2VKteaqPdtHQtw=; b=MuKc4X7vnlJ02VSnTOE0cIqD3CjrpWUMP3k6tE3xrAPW3rIYR2+94aSOvnEzmjRIut 10y/OYxVzXVzHQa62mAbYORUAvx7HjIa3KKFy5nwlNC6bTqWErw2FzOOj5zwqoeNoYYb mcfP2uauUDlW8ZZ8XtB1d808wsreGltcgsq/qqcPHb60d+3iz4WJGm/4+WR7CpgusKf1 c0YUdgxd1avVsfkRAFw29G3nSQGUmVuypRb4fBYHsIhof8NYcxioHidTmLVFJS7itlDt I560cNQ2WAVfH6ijmU1DEHnS15VFbrh+sVXDODDnCEEKwL7EJWXdTI7uPbhdgVhQ07u0 R2wA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SDNfM87Oz/fWUEPB3/KHz/tM0fzfo2VKteaqPdtHQtw=; b=GWOOS+O2gZpSeJ45PZeimi7DYE2whrVuj8c/+3MFU0kh0RiUzG3oBsKe551E3odnOo xmLODQzbKY9ucHq2gPOsIPgwp8BBBmd0UBlIK1wlY/2fVXpLjYRC7EiPxDhC9gqMpzcT H5YpXaB5RXUKt8RnoOMHx/jNnbAQqRgsYnScNyj56LANuPdji2YeOHcjQYzmrnDSq94g 3bKCjT2zfbWx5lS++HYyWXN9ss33rzZPCW9VIu4G9Hrcl0FvLN9w/nAkunGN78Tm4IoZ x3m4gWKr1AlvZTvdLrrb441LRCLyWMk5YIMMrZ8YHBQPiz6c30WgD+H1orKpcOQCbuQX tQLw==
X-Gm-Message-State: AFeK/H2Wt4ZRe2yDcgRCzwkzWtmq4YIn2c8W8YHV07OMhl4bUCH7BLwtX4PMbHMCmfn01dG/CkcUapWYMgoKng==
X-Received: by 10.107.7.29 with SMTP id 29mr1561996ioh.57.1490892762916; Thu, 30 Mar 2017 09:52:42 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 09:52:41 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 09:52:41 -0700 (PDT)
In-Reply-To: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>  
From: Robert Raszuk 
Date: Thu, 30 Mar 2017 11:52:41 -0500
X-Google-Sender-Auth: 6kW8W3GoZxQDkE9QPwdfLi0ch9Q
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Suresh Krishnan 
Cc: "Leddy, John" , IETF Discussion , 6man WG , Brian E Carpenter , Jeff Tantsura ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113ea6f0883455054bf5851d
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 16:52:46 -0000

--001a113ea6f0883455054bf5851d
Content-Type: text/plain; charset=UTF-8

Ok so till a new document updates 2460bis any further work on EHs is frozen
as it would reference 2460bis with new text. That was my main point.

And what current EH implementations are supposed to do in the mean time ?
Would IANA allocate codepoints for EH work before 2460bis is formally
updated which in the current IETF speed is easy 2+years ?

Note that without the proposed clarification none of the above obstacles
exist.

Thx
R.

On Mar 30, 2017 10:47, "Suresh Krishnan" 
wrote:

> Hi Robert,
>
> > On Mar 30, 2017, at 10:31 AM, Robert Raszuk  wrote:
> >
> > Hi Brian,
> >
> > Could you elaborate a bit on the definition of "accidentally escaping
> packets" ?
> >
> > The fundamental issue with original Suresh suggestion I see is that his
> proposed text kills ability to have 2460bis as normative reference in any
> other draft describing or defining extension headers. And effectively stops
> any work which needs to be based on 2460bis till 2460bis is updated.
>
> This is not true. The *new draft* will update RFC2460bis. We do not need a
> new (RFC2460bis)bis to do this. I can understand that this would be bad,
> but that is not the intent.
>
> Thanks
> Suresh

--001a113ea6f0883455054bf5851d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Ok so till a new document updates 2460bis any further wor=
k on EHs is frozen as it would reference 2460bis with new text. That was my=
 main point.

    And what current =
EH implementations are supposed to do in the mean time ? Would IANA allocat=
e codepoints for EH work before 2460bis is formally updated which in the cu=
rrent IETF speed is easy 2+years ?

    Note that without the proposed clarification none of the above o=
bstacles exist.

    Thx
    R.

    On Mar 30, 2017 10:47, "Suresh Krishnan" <suresh.krishnan@ericsson.com> wrote:
    Hi Rob=
ert,
    

    
> On Mar 30, 2017, at 10:31 AM, Robert Raszuk <    robert@raszuk.net> wrote:
    
>
    
> Hi Brian,
    
>
    
> Could you elaborate a bit on the definition of "accidentally esca=
ping packets" ?
    
>
    
> The fundamental issue with original Suresh suggestion I see is that hi=
s proposed text kills ability to have 2460bis as normative reference in any=
 other draft describing or defining extension headers. And effectively stop=
s any work which needs to be based on 2460bis till 2460bis is updated.
    

    
This is not true. The *new draft* will update RFC2460bis. We do not need a =
new (RFC2460bis)bis to do this. I can understand that this would be bad, bu=
t that is not the intent.
    

    
Thanks
    
Suresh
    

--001a113ea6f0883455054bf5851d--


From nobody Thu Mar 30 10:00:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E646129810; Thu, 30 Mar 2017 10:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BYGvG9Cki_7n; Thu, 30 Mar 2017 10:00:47 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B88A1294DB; Thu, 30 Mar 2017 10:00:47 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id l7so23309256ioe.3; Thu, 30 Mar 2017 10:00:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+GCyDs4QmlqzkR7cYHmpyHMA9NwFGnNG2muBQrNG408=; b=oOKowJoY8/eeA8uxAhEl6v+BHov1Ja6tuy6f8poxV6q9wQRX2xeHVvUnqpF0H7kkdi dDDlqCjsTxR4jXUU6GJdA+vTA1V3cgqmy1mCEEar93N38UWZJcTZ+KPkyUgmlV2qGt4+ nGavyAseKjL6wLhSBdLo70d0TZWDdj+zDqKvSwNP0WYKIIaRoU4wZaT1PiX9oJE+wZ8p j158PIy1ElE8QXwlugQt4u+z/aUy1cPR4lIGOJyDXrzxLoSM3LZR/7S/vbpps8xV97MX /c7DanSbQ8MIqBy7YRWzUQZ1jc6czITerzpwn87yIPDBICiqnBdwCDBUOVCsFUGj/0Uq 4mQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+GCyDs4QmlqzkR7cYHmpyHMA9NwFGnNG2muBQrNG408=; b=MxVQw16VuZ0SfEZN4M5uG+2uwC9ATLOCX1nwzmt69hhjipcGrUpakvKAj4ZkZpKxF7 A1FNnwTshyd+E9ENNs2vdvD3LNN7yEdpQGnAIsHqh896Q5HZhsfHe7SEdWurKKCwHeiU Dn4FPtT/1muermKY1rrd4HwzuqFkmEhYcaWTjGpc1yMMBvpc1M/3qolBQT+4NJx1D0/8 tZf8OlNoEToZZ53XoThAnvLJUAiMhXvYDIIzQ74FUU81y/o/YujaE2ZoGlStYyFOwDJf JP65SKKXZL7dlzHBixnWL5Go3USk7s2mVi5difRmpxQPo+7dGa1DHrrw998bnSn4ZlWx r+YA==
X-Gm-Message-State: AFeK/H2HlbvuUN2d1d4gax0Z68E54pkJXTQqzD/BnA5GYLqjIVpyKcWNVb/UDHXZFT9q89cYxI4QcJ5UytDk8g==
X-Received: by 10.107.16.217 with SMTP id 86mr1602686ioq.228.1490893246985; Thu, 30 Mar 2017 10:00:46 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 10:00:46 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 10:00:46 -0700 (PDT)
In-Reply-To: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>    
From: Robert Raszuk 
Date: Thu, 30 Mar 2017 12:00:46 -0500
X-Google-Sender-Auth: pcwRvMpavafsM09FSMfmsebhSw4
Message-ID: 
Subject: RE: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: "Ackermann, Michael" 
Cc: IETF Discussion , Suresh Krishnan ,  "Leddy, John" , 6man WG ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113ecee86281cc054bf5a248
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 17:00:50 -0000

--001a113ecee86281cc054bf5a248
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Michael,

Right on the spot.

SRv6 is a first serious consideration why number of enterprise networks
would benefit from and could consider IPv6 rollout.

Otherwise all discussions so far end up with "no need" as all services are
available with zoo of different protocols over v4 and amount of v4
addresses owned by given company are of no concern of depletion any time
soon.

Best,
R.

On Mar 30, 2017 11:54, "Ackermann, Michael"  wrote:

This is something I tried to say at the mic today, but I was too late.
If we put potentially valuable use cases into the bucket of "Exceptions",
this becomes yet another excuse to delay or avoid adoption of IPv6 by the
very large percentage of Enterprises who have yet to do so (and have no
serious plans) today.

I am hopeful that work in the IETF will provide features and hence
motivation for us sadly delinquent Enterprises to begin actually using
IPv6.    I am concerned that perception of solutions being "Exceptions" or
non standard, will cause consternation (warranted or not) and avoidance.


-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Suresh Krishnan
Sent: Thursday, March 30, 2017 9:30 AM
To: Leddy, John 
Cc: draft-ietf-6man-rfc2460bis.all@ietf.org; 6man WG ;
ietf@ietf.org
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Hi John,
  Thanks for chiming in. I recognize that you might have use cases that
might be better off with header insertion but I think they should be
handled as and when they come up for consideration (e.g. in the SRv6
discussions). Holding up this document is not going to help in any way in
reinterpreting what RFC2460 intended. My suggestion for proponents of safe
header insertion to write up how it is expected to work and have the
discussion then.

Thanks
Suresh

> On Mar 29, 2017, at 9:59 PM, Leddy, John  wrote:
>
>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan <
suresh.krishnan@ericsson.com> wrote:
>>
>> NEW:
>>
>> With one exception, extension headers are not examined, processed,
>> inserted, or deleted by any node along a packet's delivery path,
>> until the packet reaches the node (or each of the set of nodes, in
>> the case of multicast) identified in the Destination Address field of
>> the IPv6 header...
>>
>> Please feel free to comment either privately or on list if you have any
concerns with this resolution going forward.
>
>
> Suresh,
>
> I still have concerns that we are eliminating a tool that may prove very
helpful in migrations without understanding its value.
>
> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has
been long, operationally complex and full of unexpected challenges.
> We are only now starting to make the transition from Dual Stack to IPV6
Only, there are still many unknowns on how to complete this migration.
>
> As we contemplate finishing this major Network shift =E2=80=93 We find ou=
rselves
in the early stages of another.
>
> The transition from Physical to Virtual Infrastructure.  Again, the
migration will be long, operationally complex and full of unexpected
challenges.
>
> In the old world with Servers running Applications in Physical locations
designed for very predictable loads; using an encap/decap tunnel to emulate
a physical circuit between locations has many attractive properties =E2=80=
=93 but
that is compared to actually ordering and provisioning real circuits
between locations.
>
> In the new world of dynamic resources spun up on demand in distributed
environments across multiple providers, Applications having the
Intelligence and State to bring up their own required connectivity is very
natural.  This is where we are putting the majority of our efforts.  SRv6
enables very attractive solutions by Applications building their own
headers.
>
> The challenges come as we try to migrate and require these two
infrastructures to Interoperate for a long time.
> Burdening the new Virtual world with Old, Static circuit paradigms is not
optimal.
> Supplementing the legacy infrastructure with an assist function seems
> a reasonable solution.  (Ext Hdr insertion/deletion or encap/decap
> tunnels)
>
> The preferred assist mechanism seems to be the one that allows the New
> World to operate in its final preferred state, sending and receiving
packets with their own headers. (SRv6) But what does an Application in the
new world due when it is attempting to communicate with an Application in
the Old World?
> Shouldn=E2=80=99t it build an SRv6 header?  That would mean that the assi=
st
function would need to be the last SID in the Segment List and be capable
of removing the SRH.
> Wouldn=E2=80=99t it make sense for the assist function to do the same thi=
ng in
the reverse direction; an Old World Server talking to a New Virtual World
Application?  Insert an SRH.
>
> If this insert/delete of an SRH is prematurely prohibited;  What is a
recommended solution to the Real World problem above.  Not use case, we are
implementing.
>
> Again; I=E2=80=99m worried we are eliminating a tool that may prove very
> helpful, preclude its use in future IETF work and shutdown a path for
> Innovation in Networking,
>
> Thank you for asking and listening to my concerns,
>
> John Leddy
> Comcast
>
>
>
>
>
>



The information contained in this communication is highly confidential and
is intended solely for the use of the individual(s) to whom this
communication is directed. If you are not the intended recipient, you are
hereby notified that any viewing, copying, disclosure or distribution of
this information is prohibited. Please notify the sender, by electronic
mail or telephone, of any unintended receipt and delete the original
message without making any copies.

 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
nonprofit corporations and independent licensees of the Blue Cross and Blue
Shield Association.

--001a113ecee86281cc054bf5a248
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Michael,

    Rig=
ht on the spot.

    SRv6 is =
a first serious consideration why number of enterprise networks would benef=
it from and could consider IPv6 rollout.

    <=
div dir=3D"auto">Otherwise all discussions so far end up with "no need=
" as all services are available with zoo of different protocols over v=
4 and amount of v4 addresses owned by given company are of no concern of de=
pletion any time soon.

    B=
est,
    R.

    On Mar 30, 2017 11:54, "Ackermann, Michael&qu=
ot; <MAckermann@bcbsm.com>=
; wrote:
    This is something=
 I tried to say at the mic today, but I was too late.
    
If we put potentially valuable use cases into the bucket of "Exception=
s",=C2=A0 this becomes yet another excuse to delay or avoid adoption o=
f IPv6 by the very large percentage of Enterprises who have yet to do so (a=
nd have no serious plans) today.
    

    
I am hopeful that work in the IETF will provide features and hence motivati=
on for us sadly delinquent Enterprises to begin actually using IPv6.=C2=A0 =
=C2=A0 I am concerned that perception of solutions being "Exceptions&q=
uot; or non standard, will cause consternation (warranted or not) and avoid=
ance.
    


    

    
-----Original Message-----
    
From: ipv6 [mailto:ipv6-bounces@ie=
tf.org] On Behalf Of Suresh Krishnan
    
Sent: Thursday, March 30, 2017 9:30 AM
    
To: Leddy, John <John_Leddy@co=
mcast.com>
    
Cc: draft-ietf-6=
man-rfc2460bis.all@ietf.org; 6man WG <ipv6@ietf.org>; ietf@ietf.o=
rg
    
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

    

    Hi John,
    
=C2=A0 Thanks for chiming in. I recognize that you might have use cases tha=
t might be better off with header insertion but I think they should be hand=
led as and when they come up for consideration (e.g. in the SRv6 discussion=
s). Holding up this document is not going to help in any way in reinterpret=
ing what RFC2460 intended. My suggestion for proponents of safe header inse=
rtion to write up how it is expected to work and have the discussion then.<=
br>

    
Thanks
    
Suresh
    

    
> On Mar 29, 2017, at 9:59 PM, Leddy, John <John_Leddy@comcast.com> wrote:
    
>
    
>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:<=
br>
>>
    
>> NEW:
    
>>
    
>> With one exception, extension headers are not examined, processed,=

    
>> inserted, or deleted by any node along a packet's delivery pat=
h,
    
>> until the packet reaches the node (or each of the set of nodes, in=

    
>> the case of multicast) identified in the Destination Address field=
 of
    
>> the IPv6 header...
    
>>
    
>> Please feel free to comment either privately or on list if you hav=
e any concerns with this resolution going forward.
    
>
    
>
    
> Suresh,
    
>
    
> I still have concerns that we are eliminating a tool that may prove ve=
ry helpful in migrations without understanding its value.
    
>
    
> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only=
; has been long, operationally complex and full of unexpected challenges.
> We are only now starting to make the transition from Dual Stack to IPV=
6 Only, there are still many unknowns on how to complete this migration.
>
    
> As we contemplate finishing this major Network shift =E2=80=93 We find=
 ourselves in the early stages of another.
    
>
    
> The transition from Physical to Virtual Infrastructure.=C2=A0 Again, t=
he migration will be long, operationally complex and full of unexpected cha=
llenges.
    
>
    
> In the old world with Servers running Applications in Physical locatio=
ns designed for very predictable loads; using an encap/decap tunnel to emul=
ate a physical circuit between locations has many attractive properties =E2=
=80=93 but that is compared to actually ordering and provisioning real circ=
uits between locations.
    
>
    
> In the new world of dynamic resources spun up on demand in distributed=
 environments across multiple providers, Applications having the Intelligen=
ce and State to bring up their own required connectivity is very natural.=
=C2=A0 This is where we are putting the majority of our efforts.=C2=A0 SRv6=
 enables very attractive solutions by Applications building their own heade=
rs.
    
>
    
> The challenges come as we try to migrate and require these two infrast=
ructures to Interoperate for a long time.
    
> Burdening the new Virtual world with Old, Static circuit paradigms is =
not optimal.
    
> Supplementing the legacy infrastructure with an assist function seems<=
br>
> a reasonable solution.=C2=A0 (Ext Hdr insertion/deletion or encap/deca=
p
    
> tunnels)
    
>
    
> The preferred assist mechanism seems to be the one that allows the New=

    
> World to operate in its final preferred state, sending and receiving p=
ackets with their own headers. (SRv6) But what does an Application in the n=
ew world due when it is attempting to communicate with an Application in th=
e Old World?
    
> Shouldn=E2=80=99t it build an SRv6 header?=C2=A0 That would mean that =
the assist function would need to be the last SID in the Segment List and b=
e capable of removing the SRH.
    
> Wouldn=E2=80=99t it make sense for the assist function to do the same =
thing in the reverse direction; an Old World Server talking to a New Virtua=
l World Application?=C2=A0 Insert an SRH.
    
>
    
> If this insert/delete of an SRH is prematurely prohibited;=C2=A0 What =
is a recommended solution to the Real World problem above.=C2=A0 Not use ca=
se, we are implementing.
    
>
    
> Again; I=E2=80=99m worried we are eliminating a tool that may prove ve=
ry
    
> helpful, preclude its use in future IETF work and shutdown a path for<=
br>
> Innovation in Networking,
    
>
    
> Thank you for asking and listening to my concerns,
    
>
    
> John Leddy
    
> Comcast
    
>
    
>
    
>
    
>
    
>
    
>
    

    

    

    

    The information contained in this communication is highly confidentia=
l and is intended solely for the use of the individual(s) to whom this comm=
unication is directed. If you are not the intended recipient, you are hereb=
y notified that any viewing, copying, disclosure or distribution of this in=
formation is prohibited. Please notify the sender, by electronic mail or te=
lephone, of any unintended receipt and delete the original message without =
making any copies.
    

    
=C2=A0Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan =
are nonprofit corporations and independent licensees of the Blue Cross and =
Blue Shield Association.
    


    

--001a113ecee86281cc054bf5a248--


From nobody Thu Mar 30 10:12:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544D21286B1 for ; Thu, 30 Mar 2017 10:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.092
X-Spam-Level: 
X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com
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 z5DDUdrBLXpc for ; Thu, 30 Mar 2017 10:12:02 -0700 (PDT)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355C01243F3 for ; Thu, 30 Mar 2017 10:12:01 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id C2F5B1C191B for ; Thu, 30 Mar 2017 11:54:39 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id C362F1C114F; Thu, 30 Mar 2017 11:54:38 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 24CD4FE04E; Thu, 30 Mar 2017 12:54:50 -0400 (EDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C9955FE048; Thu, 30 Mar 2017 12:54:49 -0400 (EDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (unknown [216.32.180.51]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Thu, 30 Mar 2017 12:54:49 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com;  s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wduUvwCRouLEdi2To1rQHd9se6Pe3Pccbt6FA6zfKIs=; b=WDVM2FQ36KGRK9U3BZDLNimg2cnhXx/iOF6gXPWXrsogX17Zzugj4YN32bLMrx/Tv0053MzdRqB4xMr4albtxvPd+9oeC9bctscrN2vLCAvqB8sfdF4flHeXs0nAuJrOK9sgiX9PUWtJxhjl9kG4rmHxJEd3D3YSHmZyn1B0e2g=
Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Thu, 30 Mar 2017 16:54:36 +0000
Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1005.010; Thu, 30 Mar 2017 16:54:36 +0000
From: "Ackermann, Michael" 
To: Suresh Krishnan , "Leddy, John" 
CC: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG , "ietf@ietf.org" 
Subject: RE: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGssVmAgADHxICAADaS8A==
Date: Thu, 30 Mar 2017 16:54:36 +0000
Message-ID: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=bcbsm.com;
x-originating-ip: [31.133.151.189]
x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 7:cYl4U0U39j1L20c4wZjlF9xEd1w9mDO+YkWpz0dSaLYonHS4V2LCWesLtQqkIfl0jzd0S71MOCanc5TcLEzt//rClWMu8vtXFhRKC2jGD+GROd/ahtHk5vl7POOzsk8pm+2U68TS2uiRqkTpJBM3t4gT6AWYaPAFO2PO2wFGBUEpgUspQ11rmaX0MWJ5DHjZ85A4z7+S2v3dCF6OTAk4krsbJhShYk8xkhqzWOo8kyaR9WgnclzRswOW2Nd+a51e2zyxeCBqtfJZTOi+hZ0PuKmh90Wl2WSsoFbyzd+UkzU+P63FyhUdjrprLNVZxMvFctUvzBZ/CDubF0NlPXdQ6Q==; 20:VP2GvtT57gNf6YV+bLxTWZPQISXqhjGhG/r82KBeGS+h8obw9GA4Gw6aaNKlsLmZYeoRNUVWTaqKA3liT4f3l8SsGuSm/JIomRgkKfvNxBh6RBuNBCNWsHmeEGMfs+V5efTQVlv5PjXWSQBmo+ecA7sHgliS17Sg0V4FcO3kRLc=
x-ms-office365-filtering-correlation-id: f385ea2c-1b58-4261-e8dd-08d4778d72d7
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR14MB1368; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(278428928389397)(62221491112393); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:; SRVR:CY4PR14MB1368; 
x-forefront-prvs: 02622CEF0A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39830400002)(39400400002)(39450400003)(39410400002)(24454002)(377454003)(13464003)(85664002)(55016002)(53936002)(99286003)(76176999)(50986999)(54356999)(54906002)(229853002)(38730400002)(9686003)(66066001)(3280700002)(6436002)(77096006)(102836003)(4326008)(6116002)(345774005)(6246003)(2906002)(6506006)(3846002)(7736002)(8676002)(3660700001)(81166006)(7696004)(2900100001)(8936002)(53546009)(86362001)(5660300001)(33656002)(80792005)(93886004)(25786009)(122556002)(2950100002)(189998001)(74316002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 16:54:36.4256 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm01.z120.zixworks.com
X-VPM-GROUP-ID: 19321b46-2b69-48ec-8db7-7383451d49d2
X-VPM-MSG-ID: 2d4ecce6-9325-4675-ab1b-24d89ce3614c
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 17:12:04 -0000

VGhpcyBpcyBzb21ldGhpbmcgSSB0cmllZCB0byBzYXkgYXQgdGhlIG1pYyB0b2RheSwgYnV0
IEkgd2FzIHRvbyBsYXRlLiANCklmIHdlIHB1dCBwb3RlbnRpYWxseSB2YWx1YWJsZSB1c2Ug
Y2FzZXMgaW50byB0aGUgYnVja2V0IG9mICJFeGNlcHRpb25zIiwgIHRoaXMgYmVjb21lcyB5
ZXQgYW5vdGhlciBleGN1c2UgdG8gZGVsYXkgb3IgYXZvaWQgYWRvcHRpb24gb2YgSVB2NiBi
eSB0aGUgdmVyeSBsYXJnZSBwZXJjZW50YWdlIG9mIEVudGVycHJpc2VzIHdobyBoYXZlIHll
dCB0byBkbyBzbyAoYW5kIGhhdmUgbm8gc2VyaW91cyBwbGFucykgdG9kYXkuIA0KDQpJIGFt
IGhvcGVmdWwgdGhhdCB3b3JrIGluIHRoZSBJRVRGIHdpbGwgcHJvdmlkZSBmZWF0dXJlcyBh
bmQgaGVuY2UgbW90aXZhdGlvbiBmb3IgdXMgc2FkbHkgZGVsaW5xdWVudCBFbnRlcnByaXNl
cyB0byBiZWdpbiBhY3R1YWxseSB1c2luZyBJUHY2LiAgICBJIGFtIGNvbmNlcm5lZCB0aGF0
IHBlcmNlcHRpb24gb2Ygc29sdXRpb25zIGJlaW5nICJFeGNlcHRpb25zIiBvciBub24gc3Rh
bmRhcmQsIHdpbGwgY2F1c2UgY29uc3Rlcm5hdGlvbiAod2FycmFudGVkIG9yIG5vdCkgYW5k
IGF2b2lkYW5jZS4gDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlw
djYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXJlc2gg
S3Jpc2huYW4NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAzMCwgMjAxNyA5OjMwIEFNDQpUbzog
TGVkZHksIEpvaG4gPEpvaG5fTGVkZHlAY29tY2FzdC5jb20+DQpDYzogZHJhZnQtaWV0Zi02
bWFuLXJmYzI0NjBiaXMuYWxsQGlldGYub3JnOyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsg
aWV0ZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IElFVEYgTGFzdCBDYWxsIGNvbmNsdXNpb24g
Zm9yIGRyYWZ0LWlldGYtNm1hbi1yZmMyNDYwYmlzLTA4DQoNCkhpIEpvaG4sDQogIFRoYW5r
cyBmb3IgY2hpbWluZyBpbi4gSSByZWNvZ25pemUgdGhhdCB5b3UgbWlnaHQgaGF2ZSB1c2Ug
Y2FzZXMgdGhhdCBtaWdodCBiZSBiZXR0ZXIgb2ZmIHdpdGggaGVhZGVyIGluc2VydGlvbiBi
dXQgSSB0aGluayB0aGV5IHNob3VsZCBiZSBoYW5kbGVkIGFzIGFuZCB3aGVuIHRoZXkgY29t
ZSB1cCBmb3IgY29uc2lkZXJhdGlvbiAoZS5nLiBpbiB0aGUgU1J2NiBkaXNjdXNzaW9ucyku
IEhvbGRpbmcgdXAgdGhpcyBkb2N1bWVudCBpcyBub3QgZ29pbmcgdG8gaGVscCBpbiBhbnkg
d2F5IGluIHJlaW50ZXJwcmV0aW5nIHdoYXQgUkZDMjQ2MCBpbnRlbmRlZC4gTXkgc3VnZ2Vz
dGlvbiBmb3IgcHJvcG9uZW50cyBvZiBzYWZlIGhlYWRlciBpbnNlcnRpb24gdG8gd3JpdGUg
dXAgaG93IGl0IGlzIGV4cGVjdGVkIHRvIHdvcmsgYW5kIGhhdmUgdGhlIGRpc2N1c3Npb24g
dGhlbi4NCg0KVGhhbmtzDQpTdXJlc2gNCg0KPiBPbiBNYXIgMjksIDIwMTcsIGF0IDk6NTkg
UE0sIExlZGR5LCBKb2huIDxKb2huX0xlZGR5QGNvbWNhc3QuY29tPiB3cm90ZToNCj4gDQo+
PiBPbiBNYXIgMTQsIDIwMTcsIGF0IDk6NDcgUE0sIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNo
LmtyaXNobmFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiANCj4+IE5FVzoNCj4+IA0KPj4g
V2l0aCBvbmUgZXhjZXB0aW9uLCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1pbmVk
LCBwcm9jZXNzZWQsIA0KPj4gaW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUgYWxv
bmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLCANCj4+IHVudGlsIHRoZSBwYWNrZXQgcmVh
Y2hlcyB0aGUgbm9kZSAob3IgZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbiANCj4+IHRo
ZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRk
cmVzcyBmaWVsZCBvZiANCj4+IHRoZSBJUHY2IGhlYWRlci4uLg0KPj4gDQo+PiBQbGVhc2Ug
ZmVlbCBmcmVlIHRvIGNvbW1lbnQgZWl0aGVyIHByaXZhdGVseSBvciBvbiBsaXN0IGlmIHlv
dSBoYXZlIGFueSBjb25jZXJucyB3aXRoIHRoaXMgcmVzb2x1dGlvbiBnb2luZyBmb3J3YXJk
Lg0KPiANCj4gDQo+IFN1cmVzaCwNCj4gDQo+IEkgc3RpbGwgaGF2ZSBjb25jZXJucyB0aGF0
IHdlIGFyZSBlbGltaW5hdGluZyBhIHRvb2wgdGhhdCBtYXkgcHJvdmUgdmVyeSBoZWxwZnVs
IGluIG1pZ3JhdGlvbnMgd2l0aG91dCB1bmRlcnN0YW5kaW5nIGl0cyB2YWx1ZS4NCj4gDQo+
IFRoZSBJbnRlcm5ldCB0cmFuc2l0aW9uIG9mIElQVjQgLT4gRHVhbCBTdGFjayBWNC9WNiAt
PiBJUFY2IE9ubHk7IGhhcyBiZWVuIGxvbmcsIG9wZXJhdGlvbmFsbHkgY29tcGxleCBhbmQg
ZnVsbCBvZiB1bmV4cGVjdGVkIGNoYWxsZW5nZXMuDQo+IFdlIGFyZSBvbmx5IG5vdyBzdGFy
dGluZyB0byBtYWtlIHRoZSB0cmFuc2l0aW9uIGZyb20gRHVhbCBTdGFjayB0byBJUFY2IE9u
bHksIHRoZXJlIGFyZSBzdGlsbCBtYW55IHVua25vd25zIG9uIGhvdyB0byBjb21wbGV0ZSB0
aGlzIG1pZ3JhdGlvbi4NCj4gDQo+IEFzIHdlIGNvbnRlbXBsYXRlIGZpbmlzaGluZyB0aGlz
IG1ham9yIE5ldHdvcmsgc2hpZnQg4oCTIFdlIGZpbmQgb3Vyc2VsdmVzIGluIHRoZSBlYXJs
eSBzdGFnZXMgb2YgYW5vdGhlci4NCj4gDQo+IFRoZSB0cmFuc2l0aW9uIGZyb20gUGh5c2lj
YWwgdG8gVmlydHVhbCBJbmZyYXN0cnVjdHVyZS4gIEFnYWluLCB0aGUgbWlncmF0aW9uIHdp
bGwgYmUgbG9uZywgb3BlcmF0aW9uYWxseSBjb21wbGV4IGFuZCBmdWxsIG9mIHVuZXhwZWN0
ZWQgY2hhbGxlbmdlcy4NCj4gDQo+IEluIHRoZSBvbGQgd29ybGQgd2l0aCBTZXJ2ZXJzIHJ1
bm5pbmcgQXBwbGljYXRpb25zIGluIFBoeXNpY2FsIGxvY2F0aW9ucyBkZXNpZ25lZCBmb3Ig
dmVyeSBwcmVkaWN0YWJsZSBsb2FkczsgdXNpbmcgYW4gZW5jYXAvZGVjYXAgdHVubmVsIHRv
IGVtdWxhdGUgYSBwaHlzaWNhbCBjaXJjdWl0IGJldHdlZW4gbG9jYXRpb25zIGhhcyBtYW55
IGF0dHJhY3RpdmUgcHJvcGVydGllcyDigJMgYnV0IHRoYXQgaXMgY29tcGFyZWQgdG8gYWN0
dWFsbHkgb3JkZXJpbmcgYW5kIHByb3Zpc2lvbmluZyByZWFsIGNpcmN1aXRzIGJldHdlZW4g
bG9jYXRpb25zLg0KPiANCj4gSW4gdGhlIG5ldyB3b3JsZCBvZiBkeW5hbWljIHJlc291cmNl
cyBzcHVuIHVwIG9uIGRlbWFuZCBpbiBkaXN0cmlidXRlZCBlbnZpcm9ubWVudHMgYWNyb3Nz
IG11bHRpcGxlIHByb3ZpZGVycywgQXBwbGljYXRpb25zIGhhdmluZyB0aGUgSW50ZWxsaWdl
bmNlIGFuZCBTdGF0ZSB0byBicmluZyB1cCB0aGVpciBvd24gcmVxdWlyZWQgY29ubmVjdGl2
aXR5IGlzIHZlcnkgbmF0dXJhbC4gIFRoaXMgaXMgd2hlcmUgd2UgYXJlIHB1dHRpbmcgdGhl
IG1ham9yaXR5IG9mIG91ciBlZmZvcnRzLiAgU1J2NiBlbmFibGVzIHZlcnkgYXR0cmFjdGl2
ZSBzb2x1dGlvbnMgYnkgQXBwbGljYXRpb25zIGJ1aWxkaW5nIHRoZWlyIG93biBoZWFkZXJz
Lg0KPiANCj4gVGhlIGNoYWxsZW5nZXMgY29tZSBhcyB3ZSB0cnkgdG8gbWlncmF0ZSBhbmQg
cmVxdWlyZSB0aGVzZSB0d28gaW5mcmFzdHJ1Y3R1cmVzIHRvIEludGVyb3BlcmF0ZSBmb3Ig
YSBsb25nIHRpbWUuDQo+IEJ1cmRlbmluZyB0aGUgbmV3IFZpcnR1YWwgd29ybGQgd2l0aCBP
bGQsIFN0YXRpYyBjaXJjdWl0IHBhcmFkaWdtcyBpcyBub3Qgb3B0aW1hbC4NCj4gU3VwcGxl
bWVudGluZyB0aGUgbGVnYWN5IGluZnJhc3RydWN0dXJlIHdpdGggYW4gYXNzaXN0IGZ1bmN0
aW9uIHNlZW1zIA0KPiBhIHJlYXNvbmFibGUgc29sdXRpb24uICAoRXh0IEhkciBpbnNlcnRp
b24vZGVsZXRpb24gb3IgZW5jYXAvZGVjYXAgDQo+IHR1bm5lbHMpDQo+IA0KPiBUaGUgcHJl
ZmVycmVkIGFzc2lzdCBtZWNoYW5pc20gc2VlbXMgdG8gYmUgdGhlIG9uZSB0aGF0IGFsbG93
cyB0aGUgTmV3IA0KPiBXb3JsZCB0byBvcGVyYXRlIGluIGl0cyBmaW5hbCBwcmVmZXJyZWQg
c3RhdGUsIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBwYWNrZXRzIHdpdGggdGhlaXIgb3duIGhl
YWRlcnMuIChTUnY2KSBCdXQgd2hhdCBkb2VzIGFuIEFwcGxpY2F0aW9uIGluIHRoZSBuZXcg
d29ybGQgZHVlIHdoZW4gaXQgaXMgYXR0ZW1wdGluZyB0byBjb21tdW5pY2F0ZSB3aXRoIGFu
IEFwcGxpY2F0aW9uIGluIHRoZSBPbGQgV29ybGQ/DQo+IFNob3VsZG7igJl0IGl0IGJ1aWxk
IGFuIFNSdjYgaGVhZGVyPyAgVGhhdCB3b3VsZCBtZWFuIHRoYXQgdGhlIGFzc2lzdCBmdW5j
dGlvbiB3b3VsZCBuZWVkIHRvIGJlIHRoZSBsYXN0IFNJRCBpbiB0aGUgU2VnbWVudCBMaXN0
IGFuZCBiZSBjYXBhYmxlIG9mIHJlbW92aW5nIHRoZSBTUkguDQo+IFdvdWxkbuKAmXQgaXQg
bWFrZSBzZW5zZSBmb3IgdGhlIGFzc2lzdCBmdW5jdGlvbiB0byBkbyB0aGUgc2FtZSB0aGlu
ZyBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb247IGFuIE9sZCBXb3JsZCBTZXJ2ZXIgdGFsa2lu
ZyB0byBhIE5ldyBWaXJ0dWFsIFdvcmxkIEFwcGxpY2F0aW9uPyAgSW5zZXJ0IGFuIFNSSC4N
Cj4gDQo+IElmIHRoaXMgaW5zZXJ0L2RlbGV0ZSBvZiBhbiBTUkggaXMgcHJlbWF0dXJlbHkg
cHJvaGliaXRlZDsgIFdoYXQgaXMgYSByZWNvbW1lbmRlZCBzb2x1dGlvbiB0byB0aGUgUmVh
bCBXb3JsZCBwcm9ibGVtIGFib3ZlLiAgTm90IHVzZSBjYXNlLCB3ZSBhcmUgaW1wbGVtZW50
aW5nLg0KPiANCj4gQWdhaW47IEnigJltIHdvcnJpZWQgd2UgYXJlIGVsaW1pbmF0aW5nIGEg
dG9vbCB0aGF0IG1heSBwcm92ZSB2ZXJ5IA0KPiBoZWxwZnVsLCBwcmVjbHVkZSBpdHMgdXNl
IGluIGZ1dHVyZSBJRVRGIHdvcmsgYW5kIHNodXRkb3duIGEgcGF0aCBmb3IgDQo+IElubm92
YXRpb24gaW4gTmV0d29ya2luZywNCj4gDQo+IFRoYW5rIHlvdSBmb3IgYXNraW5nIGFuZCBs
aXN0ZW5pbmcgdG8gbXkgY29uY2VybnMsDQo+IA0KPiBKb2huIExlZGR5DQo+IENvbWNhc3QN
Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCg0KCgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk
IGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBp
bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hv
bSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp
bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZp
ZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5m
b3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBl
bGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0
IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNv
cGllcy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBD
YXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5k
IGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGll
bGQgQXNzb2NpYXRpb24uCg==


From nobody Thu Mar 30 11:19:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C50129485; Thu, 30 Mar 2017 11:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level: 
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Njob3pAkQhtJ; Thu, 30 Mar 2017 11:19:30 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2517127B60; Thu, 30 Mar 2017 11:19:30 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id r45so46627871qte.3; Thu, 30 Mar 2017 11:19:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ARl0jkgKyJjitiWQZ0d6FZsABzzpgnt0+RV6zGNLQWQ=; b=WivoRZryw7ueFoFzVjW9HN+Vf1tpVhb+GqC6ypu8EjNjfEmg+RTIgIZej0A28Ou3ga YlwhmgMKfXngGyI0BUfSk2UG67MYcRijLeRGj6ot6X/A8NIZewQ/Es54JlhB7EJXdqqS fP0AEx3w8Fsn+zNNBunl/sJqQsEZQEQmgNFvqf+XIkDF5sgXa+wrW70Uio5DE9faiduG f6eZPjZsGulGTKAvx0VXGzoGGoJlOGixLPZ4zgSW2lSuUjDka/QzedYDqJfuWHiqdGm0 NWxm0MHthoTJQGuWt5j7brOw4MWJu4zNcprWzg4Zhj8sZ9rNFILu/rfRBDBh1OcVRZ21 wq9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ARl0jkgKyJjitiWQZ0d6FZsABzzpgnt0+RV6zGNLQWQ=; b=roNzCE1tFpwtwlRb8xH8A8WEnf1WLdtozmeDaeGCNfZObNRrZHvUDGa+bKZ4ZY8oJn BRyyvj86QEGAdW0c3uJQn99o4SomG9rFU7cpZ7G2e/1ogDn1zvaGb+LEogAmgC6ceGZE bUgjaii8Lz1vTltanxv2lL7b+qhmGp2Jn6teZJAs0CiOwwKIl2ZStyWnEZDymKrC6CYZ ZhtXRix5he6aUWeLMqYTmCvlkDumExvuzqzSzT2ExEnD1gCF9cnNF/2RQY+UoqRn+PPB Q+T9L2G6S0CCMDKm0IVXkOuJOe+BluqMmRwLXCPCDcyS+/yWtNw+cacuYNzQ4TSHh/u4 ZdwQ==
X-Gm-Message-State: AFeK/H0aZv+DDm5v7KPClvHpjeyHR05FmL0SAlNAD/fU66A0nQgPKffSR5L2uQVPOprgAN5hJOGh6RDk9lgkUg==
X-Received: by 10.200.42.151 with SMTP id b23mr1100732qta.163.1490897969544; Thu, 30 Mar 2017 11:19:29 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Thu, 30 Mar 2017 11:19:28 -0700 (PDT)
In-Reply-To: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>   
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Thu, 30 Mar 2017 11:19:28 -0700
X-Google-Sender-Auth: AzNg4_Wz-DcOKgXtJXKLwmgPGwI
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Robert Raszuk 
Cc: Suresh Krishnan , 6man WG ,  IETF Discussion , "Leddy, John" ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 18:19:33 -0000

At Thu, 30 Mar 2017 11:52:41 -0500,
Robert Raszuk  wrote:

> Ok so till a new document updates 2460bis any further work on EHs is frozen
> as it would reference 2460bis with new text. That was my main point.

I don't get the logic...an "update" can start immediately once such a
draft new proposal is available.  The update won't be formally
completed until it gets some formal state like a standard track RFC,
and it will take time, but that wouldn't necessarily mean a further
work is "frozen"; it's not very clear to me what this term means in
this context, but it's quite common development takes place while the
spec is being discussed as a draft, and it's also not uncommon some
commercial operators even start deploying it.  On the other hand, even
if we now agreed that rfc2460bis should explicitly allow such "further
work", the discussion itself would take long and wouldn't be completed
soon.

But IMO it's irresponsible to leave the text ambiguous and let some
other people misunderstand it, possibly even more casually and/or in
the global Internet, for the comfort of some particular future work.
I think we're now trying to help avoid the latest clarification in
rfc2460bis to be interpreted as an "outright ban" of future updates
while still trying to be responsible for the soundness of the global
Internet.  In my understanding Brian's additional text is one such
attempt (I also proposed text in that sense at the time of WGLC,
although it wasn't adopted in the end).  If that text is still not
enough we can discuss how to phrase it.  And, while I suspect people
who wanted to keep the ambiguity will never be satisfied with the
result as long as the added clarification remains, I believe that's a
reasonable compromise to achieve a balance between being responsible
and not (unintentionally) discouraging future updates.

--
JINMEI, Tatuya


From nobody Thu Mar 30 11:52:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4751296BB; Thu, 30 Mar 2017 11:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LdtvjHf9RQIL; Thu, 30 Mar 2017 11:52:38 -0700 (PDT)
Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F75D126B72; Thu, 30 Mar 2017 11:52:38 -0700 (PDT)
Received: by mail-io0-x243.google.com with SMTP id f84so3829721ioj.0; Thu, 30 Mar 2017 11:52:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5qYrU/NaBvdG3XwLePJYfVqmimSjo+UJQcEH/XMgbeY=; b=nJ+V7CGYig4sXJhq5sb/CguI4C5pkzXXaOSPsvgdrJuOfcHXIUoLqB2RDEy4V93ILz v3MfJeyZ2Y+YUT5t2bhF8djdoxThfUeDPQ0t4hu0mVy51+m/dq74PXLXrUhJ7m83qzXY 5H0tRhW/WZFuFlKSQXujRJi6coctTtD0gg+z/p2xtszaaLklfVwrf2GjWAdXM1AHk3gz 4jmVaLVvFi3S6jeUukQKS1isC7dJtLwcw15qOp/77eNrAcf/3bggEyWelKdqwUvWY8Me UzND0H/tB8veB0PLTZNB/x+6T83kkreuMC5OHfXwX3LtDm2GkeCWl7oUF1Hcy7mhMf6M yWpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=5qYrU/NaBvdG3XwLePJYfVqmimSjo+UJQcEH/XMgbeY=; b=sJDDUu2KFNrWzJIPsThwu4napnbPt0j3UEsjZrZQEOHXj9ZYhYXxSlNBjQvzHWEFdX gRZA+11WUIEyb/XNxbijJEWu1V3s8BOCEEWzfMLcJWZ0yWKC/D0nM5GFB1S/V+vNCZai 9S4Hzozn4Pp8mWs1QyR8yKxwncRiCShySfUxCFqoQYk2xJUMkqvAuKHwYigWRYDEC1oI sMsU4LfyaGks+AHTbkBsGIRpNDyVEe+0xhBIKTLrtVQ8CI+ZVOHJGARObcT0tSlMgk3w s03qFO8QjdsjqOvUG27ZP07C//Cs/14Bz2K1Rryne4saE2FWzNK3pw+0bEM+gbnYg9/e X82Q==
X-Gm-Message-State: AFeK/H1zgmMqwjP5Msi5wRGHZcvXuii2qA+oJf2JNWcIBIONYEO+DCYnBdrBjEv74muJlA==
X-Received: by 10.107.27.207 with SMTP id b198mr2307494iob.218.1490899957539;  Thu, 30 Mar 2017 11:52:37 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p6sm1845991iof.12.2017.03.30.11.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 11:52:36 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Robert Raszuk 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    
Cc: "Leddy, John" , 6man WG , Suresh Krishnan , "draft-ietf-6man-rfc2460bis.all@ietf.org" , IETF Discussion 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Fri, 31 Mar 2017 07:52:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 18:52:40 -0000

On 31/03/2017 07:19, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote:
> At Thu, 30 Mar 2017 11:52:41 -0500,
> Robert Raszuk  wrote:
>=20
>> Ok so till a new document updates 2460bis any further work on EHs is f=
rozen
>> as it would reference 2460bis with new text. That was my main point.
>=20
> I don't get the logic...an "update" can start immediately once such a
> draft new proposal is available.  The update won't be formally
> completed until it gets some formal state like a standard track RFC,
> and it will take time, but that wouldn't necessarily mean a further
> work is "frozen";=20

Exactly. At this time the *quickest* way forward is to get 2460bis throug=
h
the IESG, progress the -extension-header-insertion draft ASAP, and in due=

time do an early assignment request for draft-ietf-6man-segment-routing-h=
eader

If you try that early assignment request today, it seems likely to fail.

   Brian

> it's not very clear to me what this term means in
> this context, but it's quite common development takes place while the
> spec is being discussed as a draft, and it's also not uncommon some
> commercial operators even start deploying it.  On the other hand, even
> if we now agreed that rfc2460bis should explicitly allow such "further
> work", the discussion itself would take long and wouldn't be completed
> soon.
>=20
> But IMO it's irresponsible to leave the text ambiguous and let some
> other people misunderstand it, possibly even more casually and/or in
> the global Internet, for the comfort of some particular future work.
> I think we're now trying to help avoid the latest clarification in
> rfc2460bis to be interpreted as an "outright ban" of future updates
> while still trying to be responsible for the soundness of the global
> Internet.  In my understanding Brian's additional text is one such
> attempt (I also proposed text in that sense at the time of WGLC,
> although it wasn't adopted in the end).  If that text is still not
> enough we can discuss how to phrase it.  And, while I suspect people
> who wanted to keep the ambiguity will never be satisfied with the
> result as long as the added clarification remains, I believe that's a
> reasonable compromise to achieve a balance between being responsible
> and not (unintentionally) discouraging future updates.
>=20
> --
> JINMEI, Tatuya
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Thu Mar 30 12:26:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01581292FC; Thu, 30 Mar 2017 12:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk
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 7ZjZYj5cFtNV; Thu, 30 Mar 2017 12:26:07 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F58126B72; Thu, 30 Mar 2017 12:26:06 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id v2UJQ2u0026523; Thu, 30 Mar 2017 20:26:02 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk v2UJQ2u0026523
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1490901963; bh=eSbJ1LvwGAIkTkXpXudA0NKu9jA=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=puIoOd4K0mut1FooXADzlJkND9swmmnEk9Kn9+jkKlm/YkenrMJsGL0EPY00SPNJX A7M3q6tIdbAr1MxRHuN8R0doVpjIghJSaf8CKEB/x18XavZspjEugYgDZShdf0ZCFF teezY5s9e1AIlltEsq8ZXBQYyhA0SrdBLtfvYaRU=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP (valid=N/A) id y2YKQ21151011028gw ret-id none; Thu, 30 Mar 2017 20:26:02 +0100
Received: from t2001067c0370012814f6e8a6bc91a44d.v6.meeting.ietf.org (t2001067c0370012814f6e8a6bc91a44d.v6.meeting.ietf.org [IPv6:2001:67c:370:128:14f6:e8a6:bc91:a44d]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id v2UJPuSC028259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Mar 2017 20:25:57 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
From: Tim Chown 
In-Reply-To: 
Date: Thu, 30 Mar 2017 20:25:56 +0100
Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG 
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>     
To: IETF Discussion 
X-Mailer: Apple Mail (2.3259)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-ECS-MailScanner-SpamScore: ssss
X-smtpf-Report: sid=y2YKQ2115101102800; tid=y2YKQ21151011028gw; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: v2UJQ2u0026523
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 19:26:10 -0000

Hi,

> On 30 Mar 2017, at 19:19, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 =
 wrote:
>=20
> At Thu, 30 Mar 2017 11:52:41 -0500,
> Robert Raszuk  wrote:
>=20
>> Ok so till a new document updates 2460bis any further work on EHs is =
frozen
>> as it would reference 2460bis with new text. That was my main point.
>=20
> I don't get the logic...an "update" can start immediately once such a
> draft new proposal is available.  The update won't be formally
> completed until it gets some formal state like a standard track RFC,
> and it will take time, but that wouldn't necessarily mean a further
> work is "frozen"; it's not very clear to me what this term means in
> this context, but it's quite common development takes place while the
> spec is being discussed as a draft, and it's also not uncommon some
> commercial operators even start deploying it.  On the other hand, even
> if we now agreed that rfc2460bis should explicitly allow such "further
> work", the discussion itself would take long and wouldn't be completed
> soon.
>=20
> But IMO it's irresponsible to leave the text ambiguous and let some
> other people misunderstand it, possibly even more casually and/or in
> the global Internet, for the comfort of some particular future work.
> I think we're now trying to help avoid the latest clarification in
> rfc2460bis to be interpreted as an "outright ban" of future updates
> while still trying to be responsible for the soundness of the global
> Internet.  In my understanding Brian's additional text is one such
> attempt (I also proposed text in that sense at the time of WGLC,
> although it wasn't adopted in the end).  If that text is still not
> enough we can discuss how to phrase it.  And, while I suspect people
> who wanted to keep the ambiguity will never be satisfied with the
> result as long as the added clarification remains, I believe that's a
> reasonable compromise to achieve a balance between being responsible
> and not (unintentionally) discouraging future updates.

Repeating what I said at the mic, my views echo those of Jinmei, =
Michael, Lorenzo and Brian. I agree with the decision to progress =
RFC2460-bis to IS including Suresh=E2=80=99s text. I=E2=80=99d also like =
to see Brian=E2=80=99s short amendment included, which makes explicit =
Internet scope as the default target.

Advancing 2460bis doesn=E2=80=99t freeze work on SR; that work can =
continue today. I don=E2=80=99t see the new SR header insertion draft =
completing in =E2=80=9Ca couple of weeks=E2=80=9D; it=E2=80=99s much =
more likely to take several months or even a year to progress through WG =
adoption and eventual publication, to ensure good and robust input. For =
adoption, I=E2=80=99d expect many people to want the draft to include =
text on a) why vanilla encapsulation is not sufficient and b) how the =
insertion can guaranteed to be done safely for specific scenario(s). But =
that=E2=80=99s all very possible.

And please do note that publishing 2460-bis as an Internet Standard does =
not set it in stone. Your SR work can update it, as could other future =
RFC(s) on other new mechanism(s) or innovation(s) that have yet to be =
proposed. I=E2=80=99d argue that it=E2=80=99s pretty likely we=E2=80=99ll =
see other RFCs update 2460-bis; that shouldn=E2=80=99t be a surprise if =
it=E2=80=99s a protocol that we=E2=80=99ll be using for the next 20-30 =
years or more. For each, we=E2=80=99ll just see =E2=80=9CUpdated by:=E2=80=
=9D tags in the RFC header. The current RFC2460 has accumulated nine =
such tags in 19 years, so about one every two years.

On enterprise deployment I=E2=80=99d argue that, if anything, moving to =
IS should help strengthen the case for deployment, because it confirms =
proven widescale deployment.  The four criteria for moving to IS are =
described in Section 2.2 of RFC6410, but are summarised as "a high =
degree of technical maturity and by a generally held belief that the =
specified protocol or service provides significant benefit to the =
Internet community=E2=80=9D. I=E2=80=99d hope we have very strong =
consensus on that statement.

Tim=


From nobody Thu Mar 30 12:27:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D2C126B72 for ; Thu, 30 Mar 2017 12:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 71Ueh3J1Ppct for ; Thu, 30 Mar 2017 12:27:24 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7541129A2B for ; Thu, 30 Mar 2017 12:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490902039; bh=8ZPUbbCw/MCX2WhtUc5kZEeE3Bp5V33DtvdS70ObevM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=M+SRF1ftWpCkjKHxP7tsZpc7+ZJlX4PGCV7IrAuq4/F/HJ2M7He57+4wqro3rYnq/Qvx3sfwiJg3HEAuNf3m0zCrJMxxG1LaK6je6XSUkxlh6YP2z4v4TUutUkDb9CsAv6/EGyUdMdM6FLunAjmC2bk4KeS4PCamrJOykK1+uec=
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0245.outbound.protection.outlook.com [213.199.154.245]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-69-NboFHBkTN96UIBp4JcYO3Q-1; Thu, 30 Mar 2017 20:27:17 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Thu, 30 Mar 2017 19:27:15 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.009; Thu, 30 Mar 2017 19:27:15 +0000
From: Tim Chown 
To: 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
CC: IETF Discussion 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGssVmAgAC6+QCAAAergIAAIVqAgAAFggCAAASRAIAAEj+AgAAYQACAABLvAA==
Date: Thu, 30 Mar 2017 19:27:15 +0000
Message-ID: <5E233A42-42C7-4D16-A755-7E0314BFB2D4@jisc.ac.uk>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:67c:370:128:14f6:e8a6:bc91:a44d]
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:YFVkAzssIxyEys6p4Sb9HSCfwZeCqtzAN+VvUYEcCYetLWymBW4KHCpSZ3KMklOH2vNfPdWFsbB0KjWKu1kbdqELH76ef3iaNMkKi6xbB/N69cUi4eeirsXFA/hZ32MDfNnJsvBrmkPCXIWSlN58339fSKBejZ1upjE9xi47pjLr/Hw0agm2Bya4uHLsIrjF5EkWoobLVmWQauAhnTctG4WbQYicLhkxKm6QxPamH7vNrbhzjl01i/PYmuXoqyrP4yAcSmCEnwimfBaCRQ5spJoDHwcxTWGVSIw+WmmhQlhSHVl2H7GgO/+eFAfjP5umMn9IJ4nVBL5WZKWgErGmrA==; 20:i7NIVx7NO5tgFAfOvsSbeILR0bSw9wd4ZEbOuzjuyOyY1i+GQ4xvd35wh+uO59M8Vk3+uQmdDChbgwrRbWAAL5uLAQ1HGa2cCWDl+AVtGfBshUQ3vLv1W3sV4zalk32Ie/Vve5++NjM1LFa+WJgCOuUxsD+ePdH3P7emDgFqPzg=
x-ms-office365-filtering-correlation-id: 48cdb482-a1b2-41d5-2f79-08d477a2c611
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1138; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006070)(93001070)(10201501046)(3002001)(6041248)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; 
x-forefront-prvs: 02622CEF0A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39840400002)(39400400002)(24454002)(57306001)(7736002)(81166006)(83716003)(42882006)(99286003)(189998001)(2950100002)(8936002)(305945005)(38730400002)(3660700001)(450100002)(4326008)(2906002)(36756003)(25786009)(6436002)(53546009)(2900100001)(82746002)(74482002)(3280700002)(229853002)(33656002)(2501003)(561944003)(6116002)(50226002)(6512007)(5660300001)(102836003)(6486002)(8676002)(6246003)(53936002)(230783001)(5250100002)(86362001)(76176999)(6506006)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <044F46D857C5BE41910636F411274E49@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 19:27:15.6723 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138
X-MC-Unique: NboFHBkTN96UIBp4JcYO3Q-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 19:27:26 -0000

SGksDQoNCj4gT24gMzAgTWFyIDIwMTcsIGF0IDE5OjE5LCDnpZ7mmI7pgZTlk4kgPGppbm1laUB3
aWRlLmFkLmpwPiB3cm90ZToNCj4gDQo+IEF0IFRodSwgMzAgTWFyIDIwMTcgMTE6NTI6NDEgLTA1
MDAsDQo+IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PiB3cm90ZToNCj4gDQo+PiBP
ayBzbyB0aWxsIGEgbmV3IGRvY3VtZW50IHVwZGF0ZXMgMjQ2MGJpcyBhbnkgZnVydGhlciB3b3Jr
IG9uIEVIcyBpcyBmcm96ZW4NCj4+IGFzIGl0IHdvdWxkIHJlZmVyZW5jZSAyNDYwYmlzIHdpdGgg
bmV3IHRleHQuIFRoYXQgd2FzIG15IG1haW4gcG9pbnQuDQo+IA0KPiBJIGRvbid0IGdldCB0aGUg
bG9naWMuLi5hbiAidXBkYXRlIiBjYW4gc3RhcnQgaW1tZWRpYXRlbHkgb25jZSBzdWNoIGENCj4g
ZHJhZnQgbmV3IHByb3Bvc2FsIGlzIGF2YWlsYWJsZS4gIFRoZSB1cGRhdGUgd29uJ3QgYmUgZm9y
bWFsbHkNCj4gY29tcGxldGVkIHVudGlsIGl0IGdldHMgc29tZSBmb3JtYWwgc3RhdGUgbGlrZSBh
IHN0YW5kYXJkIHRyYWNrIFJGQywNCj4gYW5kIGl0IHdpbGwgdGFrZSB0aW1lLCBidXQgdGhhdCB3
b3VsZG4ndCBuZWNlc3NhcmlseSBtZWFuIGEgZnVydGhlcg0KPiB3b3JrIGlzICJmcm96ZW4iOyBp
dCdzIG5vdCB2ZXJ5IGNsZWFyIHRvIG1lIHdoYXQgdGhpcyB0ZXJtIG1lYW5zIGluDQo+IHRoaXMg
Y29udGV4dCwgYnV0IGl0J3MgcXVpdGUgY29tbW9uIGRldmVsb3BtZW50IHRha2VzIHBsYWNlIHdo
aWxlIHRoZQ0KPiBzcGVjIGlzIGJlaW5nIGRpc2N1c3NlZCBhcyBhIGRyYWZ0LCBhbmQgaXQncyBh
bHNvIG5vdCB1bmNvbW1vbiBzb21lDQo+IGNvbW1lcmNpYWwgb3BlcmF0b3JzIGV2ZW4gc3RhcnQg
ZGVwbG95aW5nIGl0LiAgT24gdGhlIG90aGVyIGhhbmQsIGV2ZW4NCj4gaWYgd2Ugbm93IGFncmVl
ZCB0aGF0IHJmYzI0NjBiaXMgc2hvdWxkIGV4cGxpY2l0bHkgYWxsb3cgc3VjaCAiZnVydGhlcg0K
PiB3b3JrIiwgdGhlIGRpc2N1c3Npb24gaXRzZWxmIHdvdWxkIHRha2UgbG9uZyBhbmQgd291bGRu
J3QgYmUgY29tcGxldGVkDQo+IHNvb24uDQo+IA0KPiBCdXQgSU1PIGl0J3MgaXJyZXNwb25zaWJs
ZSB0byBsZWF2ZSB0aGUgdGV4dCBhbWJpZ3VvdXMgYW5kIGxldCBzb21lDQo+IG90aGVyIHBlb3Bs
ZSBtaXN1bmRlcnN0YW5kIGl0LCBwb3NzaWJseSBldmVuIG1vcmUgY2FzdWFsbHkgYW5kL29yIGlu
DQo+IHRoZSBnbG9iYWwgSW50ZXJuZXQsIGZvciB0aGUgY29tZm9ydCBvZiBzb21lIHBhcnRpY3Vs
YXIgZnV0dXJlIHdvcmsuDQo+IEkgdGhpbmsgd2UncmUgbm93IHRyeWluZyB0byBoZWxwIGF2b2lk
IHRoZSBsYXRlc3QgY2xhcmlmaWNhdGlvbiBpbg0KPiByZmMyNDYwYmlzIHRvIGJlIGludGVycHJl
dGVkIGFzIGFuICJvdXRyaWdodCBiYW4iIG9mIGZ1dHVyZSB1cGRhdGVzDQo+IHdoaWxlIHN0aWxs
IHRyeWluZyB0byBiZSByZXNwb25zaWJsZSBmb3IgdGhlIHNvdW5kbmVzcyBvZiB0aGUgZ2xvYmFs
DQo+IEludGVybmV0LiAgSW4gbXkgdW5kZXJzdGFuZGluZyBCcmlhbidzIGFkZGl0aW9uYWwgdGV4
dCBpcyBvbmUgc3VjaA0KPiBhdHRlbXB0IChJIGFsc28gcHJvcG9zZWQgdGV4dCBpbiB0aGF0IHNl
bnNlIGF0IHRoZSB0aW1lIG9mIFdHTEMsDQo+IGFsdGhvdWdoIGl0IHdhc24ndCBhZG9wdGVkIGlu
IHRoZSBlbmQpLiAgSWYgdGhhdCB0ZXh0IGlzIHN0aWxsIG5vdA0KPiBlbm91Z2ggd2UgY2FuIGRp
c2N1c3MgaG93IHRvIHBocmFzZSBpdC4gIEFuZCwgd2hpbGUgSSBzdXNwZWN0IHBlb3BsZQ0KPiB3
aG8gd2FudGVkIHRvIGtlZXAgdGhlIGFtYmlndWl0eSB3aWxsIG5ldmVyIGJlIHNhdGlzZmllZCB3
aXRoIHRoZQ0KPiByZXN1bHQgYXMgbG9uZyBhcyB0aGUgYWRkZWQgY2xhcmlmaWNhdGlvbiByZW1h
aW5zLCBJIGJlbGlldmUgdGhhdCdzIGENCj4gcmVhc29uYWJsZSBjb21wcm9taXNlIHRvIGFjaGll
dmUgYSBiYWxhbmNlIGJldHdlZW4gYmVpbmcgcmVzcG9uc2libGUNCj4gYW5kIG5vdCAodW5pbnRl
bnRpb25hbGx5KSBkaXNjb3VyYWdpbmcgZnV0dXJlIHVwZGF0ZXMuDQoNClJlcGVhdGluZyB3aGF0
IEkgc2FpZCBhdCB0aGUgbWljLCBteSB2aWV3cyBlY2hvIHRob3NlIG9mIEppbm1laSwgTWljaGFl
bCwgTG9yZW56byBhbmQgQnJpYW4uIEkgYWdyZWUgd2l0aCB0aGUgZGVjaXNpb24gdG8gcHJvZ3Jl
c3MgUkZDMjQ2MC1iaXMgdG8gSVMgaW5jbHVkaW5nIFN1cmVzaOKAmXMgdGV4dC4gSeKAmWQgYWxz
byBsaWtlIHRvIHNlZSBCcmlhbuKAmXMgc2hvcnQgYW1lbmRtZW50IGluY2x1ZGVkLCB3aGljaCBt
YWtlcyBleHBsaWNpdCBJbnRlcm5ldCBzY29wZSBhcyB0aGUgZGVmYXVsdCB0YXJnZXQuDQoNCkFk
dmFuY2luZyAyNDYwYmlzIGRvZXNu4oCZdCBmcmVlemUgd29yayBvbiBTUjsgdGhhdCB3b3JrIGNh
biBjb250aW51ZSB0b2RheS4gSSBkb27igJl0IHNlZSB0aGUgbmV3IFNSIGhlYWRlciBpbnNlcnRp
b24gZHJhZnQgY29tcGxldGluZyBpbiDigJxhIGNvdXBsZSBvZiB3ZWVrc+KAnTsgaXTigJlzIG11
Y2ggbW9yZSBsaWtlbHkgdG8gdGFrZSBzZXZlcmFsIG1vbnRocyBvciBldmVuIGEgeWVhciB0byBw
cm9ncmVzcyB0aHJvdWdoIFdHIGFkb3B0aW9uIGFuZCBldmVudHVhbCBwdWJsaWNhdGlvbiwgdG8g
ZW5zdXJlIGdvb2QgYW5kIHJvYnVzdCBpbnB1dC4gRm9yIGFkb3B0aW9uLCBJ4oCZZCBleHBlY3Qg
bWFueSBwZW9wbGUgdG8gd2FudCB0aGUgZHJhZnQgdG8gaW5jbHVkZSB0ZXh0IG9uIGEpIHdoeSB2
YW5pbGxhIGVuY2Fwc3VsYXRpb24gaXMgbm90IHN1ZmZpY2llbnQgYW5kIGIpIGhvdyB0aGUgaW5z
ZXJ0aW9uIGNhbiBndWFyYW50ZWVkIHRvIGJlIGRvbmUgc2FmZWx5IGZvciBzcGVjaWZpYyBzY2Vu
YXJpbyhzKS4gQnV0IHRoYXTigJlzIGFsbCB2ZXJ5IHBvc3NpYmxlLg0KDQpBbmQgcGxlYXNlIGRv
IG5vdGUgdGhhdCBwdWJsaXNoaW5nIDI0NjAtYmlzIGFzIGFuIEludGVybmV0IFN0YW5kYXJkIGRv
ZXMgbm90IHNldCBpdCBpbiBzdG9uZS4gWW91ciBTUiB3b3JrIGNhbiB1cGRhdGUgaXQsIGFzIGNv
dWxkIG90aGVyIGZ1dHVyZSBSRkMocykgb24gb3RoZXIgbmV3IG1lY2hhbmlzbShzKSBvciBpbm5v
dmF0aW9uKHMpIHRoYXQgaGF2ZSB5ZXQgdG8gYmUgcHJvcG9zZWQuIEnigJlkIGFyZ3VlIHRoYXQg
aXTigJlzIHByZXR0eSBsaWtlbHkgd2XigJlsbCBzZWUgb3RoZXIgUkZDcyB1cGRhdGUgMjQ2MC1i
aXM7IHRoYXQgc2hvdWxkbuKAmXQgYmUgYSBzdXJwcmlzZSBpZiBpdOKAmXMgYSBwcm90b2NvbCB0
aGF0IHdl4oCZbGwgYmUgdXNpbmcgZm9yIHRoZSBuZXh0IDIwLTMwIHllYXJzIG9yIG1vcmUuIEZv
ciBlYWNoLCB3ZeKAmWxsIGp1c3Qgc2VlIOKAnFVwZGF0ZWQgYnk64oCdIHRhZ3MgaW4gdGhlIFJG
QyBoZWFkZXIuIFRoZSBjdXJyZW50IFJGQzI0NjAgaGFzIGFjY3VtdWxhdGVkIG5pbmUgc3VjaCB0
YWdzIGluIDE5IHllYXJzLCBzbyBhYm91dCBvbmUgZXZlcnkgdHdvIHllYXJzLg0KDQpPbiBlbnRl
cnByaXNlIGRlcGxveW1lbnQgSeKAmWQgYXJndWUgdGhhdCwgaWYgYW55dGhpbmcsIG1vdmluZyB0
byBJUyBzaG91bGQgaGVscCBzdHJlbmd0aGVuIHRoZSBjYXNlIGZvciBkZXBsb3ltZW50LCBiZWNh
dXNlIGl0IGNvbmZpcm1zIHByb3ZlbiB3aWRlc2NhbGUgZGVwbG95bWVudC4gIFRoZSBmb3VyIGNy
aXRlcmlhIGZvciBtb3ZpbmcgdG8gSVMgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMiBvZiBS
RkM2NDEwLCBidXQgYXJlIHN1bW1hcmlzZWQgYXMgImEgaGlnaCBkZWdyZWUgb2YgdGVjaG5pY2Fs
IG1hdHVyaXR5IGFuZCBieSBhIGdlbmVyYWxseSBoZWxkIGJlbGllZiB0aGF0IHRoZSBzcGVjaWZp
ZWQgcHJvdG9jb2wgb3Igc2VydmljZSBwcm92aWRlcyBzaWduaWZpY2FudCBiZW5lZml0IHRvIHRo
ZSBJbnRlcm5ldCBjb21tdW5pdHnigJ0uIEnigJlkIGhvcGUgd2UgaGF2ZSB2ZXJ5IHN0cm9uZyBj
b25zZW5zdXMgb24gdGhhdCBzdGF0ZW1lbnQuDQoNClRpbQ==


From nobody Thu Mar 30 13:06:59 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF5612941C for ; Thu, 30 Mar 2017 13:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tP75DO2PZsCp for ; Thu, 30 Mar 2017 13:06:55 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9187C1292CE for ; Thu, 30 Mar 2017 13:06:55 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id s68so68246318vke.3 for ; Thu, 30 Mar 2017 13:06:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FCDXW9zhb+ksF6gsZJpohXVM4SUI9+CcAzWKWN9BIy8=; b=afurG1MRjZPoX2/DoPkDsw7hW33EPUbcfXdy49KdzwOOQrFJiyRZhc9FGMAo9ek1XK WOGPnZGFdWZFkCQ7JaNnCYrU45rrXxPvNI9x7i4KeZdZKzc5Y7e0YwP2qeKGc31mYZCo QVNn5LL/rqPn4r4YvLp4mf4a6ODXX/MGzYl260hf1Tg1BPps4wfABnm/PQWo75/5QKc/ RV45vxqnfY3AHfLWF44zK5QW5YSOoOvBrLi5IKGbSGVP/kQmD2+9av3VoHK/+gCOhrvC sc2VkCUtjqJ2NftQm6SZH1WY+GA8Y5VIELMkRnVJMMSKo3EhqJylSOKmzxRQajPBQkbI yDWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FCDXW9zhb+ksF6gsZJpohXVM4SUI9+CcAzWKWN9BIy8=; b=fbL2yEELBTPfSSAF2friU++9o72WLqALqUDgQZzPqK0LB7ZQOyOS1MiPDlia/SbvLn XMxwUEa9GBK0AjmTIKxEwg6iGsNuHCUrF3hvD1a9b2uyXjT+p8opR6M3jOcxv/ysmyyN IkXlwvVcqYfIl/xU+kSAUPRPTGbtYb7N7gzyEZmbA4hLT0jpOQkT+99K+g5xUn6dANvW nYTSOFEzeOyGdjudBkArpTuqjkpWECw65GADdMSrvZZ2UKMVotwmOwtS07JeBO2uZHAy LGFQQxvTbeISvgT5yf51A32n6WUlal3rmJe7W7klXyHBywmijBYUVJ/VS3lyleAXrG38 kDcg==
X-Gm-Message-State: AFeK/H19wTPB0LI7Jvef2lWOkx7tl+sryaaMLJ6AYs1OG1gRStLzEN5r/qREq46TsXAG9aKJo9E0Q1W1sviUsA==
X-Received: by 10.176.83.124 with SMTP id y57mr779555uay.141.1490904414394; Thu, 30 Mar 2017 13:06:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.181 with HTTP; Thu, 30 Mar 2017 13:06:24 -0700 (PDT)
In-Reply-To: 
References:  
From: Mark Smith 
Date: Fri, 31 Mar 2017 07:06:24 +1100
Message-ID: 
Subject: Re: draft-voyer-6man-extension-header-insertion
To: "Stefano Previdi (sprevidi)" 
Cc: 6man WG 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 20:06:58 -0000

On 30 March 2017 at 07:55, Stefano Previdi (sprevidi)
 wrote:
>
>> On Mar 28, 2017, at 10:07 PM, Mark Smith  wrote:
>>
>> They're missing the difference between encapsulation and insertion.
>
>
> not really:
>
> . a packet is received at ingress of the controlled domain
> . the packet is encapsulated into a new outer ipv6 header where SA/DA are=
 internal to the domain.
> . from now on:
>     . this packet is a packet sourced and destined within the controlled =
domain.
>     . the original packet is encapsulated and will remain untouched/unmod=
ified (i.e., noting will be inserted into the original packet).

So that is the transit case, and yes, that packet is left as sent by
it's originating host.

The 6PE example is the one that is claiming that "packet" is changing
in size, and that is not correct.


"While transiting in the core, the size of the label stack (hence
      the size of the packet)"

Any time this draft mentions "packet" without context, it is going to
be read as "IPv6 packet" because this draft is an IPv6 draft and this
is an IPv6 working group.

While that might sound like I'm being pedantic, this 6PE example seems
to be being used to show that 6PE already changes the size of the IPv6
packet, and therefore changing IPv6 packet sizes mid-flight is normal
and acceptable.




> . a packet sourced and destined internally in the controlled domain can s=
afely be increased in its size and can be safely have EHs inserted by trans=
it nodes.

I don't agree with that statement. What if the inserted EH isn't
actually removed when it should be?

The domain already supports IPv6-in-IPv6 encapsulation, going the
transit packet example. Why complicate things by also having the same
domain support insertion, when already supported IPv6-in-IPv6
encapsulation can be used to achieve the same outcome?

EH insertion and DA address swapping seem to be to be far more
complicated and therefore expensive and error prone operations than
network-layer to link-layer (where IPv6 is also being used as a
link-layer) type encapsulation/decapsulation.


> . when the packet reaches the egress node of the controlled domain, the o=
uter encapsulation and any inserted EH are removed. IOW, the packet that le=
aves the domain is exactly the same packet that entered the domain.

Your specification will say that, probably as a MUST. The trouble is
that implementations don't always behave as specified. "In theory,
practice and theory are the same. In practice they're not."

If a later router or host receives a packet with an EH that hasn't
been removed when it should have been, what will happen? That
behaviour isn't currently specified.

We know that protocols assume that the received packet's structure and
most of its field values (e.g., excluding Hop Limit, flow label etc.)
were set by the device specified in the source address field. If an
inserted EH is not removed, and you can't guarantee that, then devices
are receiving packets that are corrupt by the current specifications.

I think this is a change that is violating Postel's Robustness principle.

I think one meaning of "Be conservative with what you send," is don't
send something that might break somebody else's devices.You might
argue you aren't, because your specification will say the inserted EH
MUST be removed. However, you can't guarantee that, and that is why
Jon said, paraphrasing, "don't send them in the first place/"



> . the size of the packet increased inside the domain due to encapsulation=
 of course but also due to EH insertion while in transit in the domain. The=
 MTU problem doesn=E2=80=99t exist in reality because the MTU of interfaces=
 in the controlled domain is roughly 4 times what is at the ingress.
> . the point of the draft is to say that if the packet is sourced and dest=
ined within a controlled domain, it is safe to allow insertion of EHs by tr=
ansit nodes.
>
> once again: the EH insertion happens into the outer header, not into the =
original packet.
>

The outer IPv6 packet is also an IPv6 packet - the inner IPv6 is
really just application payload (tunnelling is really just a
host-to-host application). So inserting an EH into the outer IPv6
packet is also violating the IPv6 specifications.



>>
>> The increase and decrease in "packet" size that is occurring in their
>> 6PE example is as the PDU crosses layer boundaries due to
>> encapsulation or decapsulation. This is occurring as the PDU travels
>> vertically between layers. From the IPv6 perspective, the 6PE layer is
>> a link layer below the network layer.
>
>
> the example of 6pe outlines the fact that the packet, while transiting wi=
thin a domain, can  increase in its size due to label stack being pushed.
>
>
>> While the IPv6 packet traverses the 6PE domain, the IPv6's packet size
>> and structure is not changed in any way.
>
>
> the same is in our approach:
>
> . the original packet is encapsulated into an outer header and its size w=
ill not change.
> . the encapsulating packet will get EH inserted.
>
>
>> EH insertion is increasing the PDU size and changing the packet
>> structure while the packet travels horizontally within the IPv6 layer.
>> That will break things if the destination host doesn't expect the
>> packet size or structure to change, and they don't, because it is not
>> a described "within layer" packet processing behaviour in RFC2460. The
>> destination host expects that the packet received has a structure and
>> size that is the same as sent by the device identified in the source
>> address field, which is the host that originated the packet.
>>
>> EH insertion makes the source address field both meaningless and
>> holding an incorrect value while the inserted EH is present.
>
>
> not really:
> . the SA is untouched by the EH insertion. The SA is the address of the i=
ngress node of the controlled domain.
> . the DA is updated with the first segment of the EH (we assume the inser=
ted EH is the SRH).
> . the DA is updated at each segment
>
>
>> A
>> specification for EH insertion would need to state this very clearly.
>> Many of the negative consequences of EH insertion are because it makes
>> the packet's source address field meaningless and holding a incorrect
>> value.
>
>
> again, not really in this case: the SA is untouched and it represents the=
 ingress node of the controlled domain.
>
>
>> The only things that are permitted to change while an IPv6 packet is
>> in flight (within the IPv6 layer) are values of a defined set of
>> fields specified in RFC2460 e.g., hop limit, flow label, traffic
>> class. Only field values change, no fields are added or removed - the
>> packet's structure and size stays the same after these modifications
>> if or when they occur.
>
>
> I understand what rfc2460 specified and the reason of our draft is to exp=
lain that things have changed in the last 20 years and we should take them =
into consideration.
>

That's the thing that is missing. There is an assertion that inserting
EHs is required (a much stronger word than "preferred"), yet no
explanation of why it is required or essential.

The use of the word "required" implies that the inserting EH is
essential for this to work. I don't think it is, encapsulation could
achieve the same outcome, and it is an existing, well known method
that won't interact unexpectedly with existing IPv6 implementations.

Regards,
Mark.

> s.
>
>

Regards,
Mark.

>>
>>
>> Regards,
>> Mark.
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>


From nobody Thu Mar 30 13:25:00 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335F3126B72; Thu, 30 Mar 2017 13:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 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.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 R9zm9G5niDAr; Thu, 30 Mar 2017 13:24:50 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE20812943B; Thu, 30 Mar 2017 13:24:47 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id s68so68800442vke.3; Thu, 30 Mar 2017 13:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9UCmQ5KLq8wk+DPwCIEXLbXkwUyMyI/eyt2KZvPu1Zk=; b=UHQ0Yt57+zbj0RYo3gWnYNGd9zw0cY3hYHYWIoQqrqsMU0AYb+R0IzszdPeLHwYRzD ruHpSIO/vGC2c3+fAXsz3L0+peN8c8MOKRshmSQcvwvRGoHHyt1YulMM7Jt6xVQC7ddl bJjzzFcUsod3v0AxhS/mlXqY6wCv3tdNvrATOnbUtu9qhpwTP2rNiYDei+AjjdsFQwt7 3nhFLHtFWXAfQaB80mXLTPPqJU6ZdmonoNsTnG1vksTAY+q9CcNs81lm3ULbFbX22wsI xSo3kf7t51rT24xFth42PCzIgaD2U50xrbY37MdD8zR9MwxLc5NI9tr3b+Q7Gw9wbw01 lUag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9UCmQ5KLq8wk+DPwCIEXLbXkwUyMyI/eyt2KZvPu1Zk=; b=cHdqXJXGgk+cN6S/UcTz53mMvzJMjVmXWxa8FQjirALUGLMdm8m4Bfue9TsXwfDk3B yjC6Ad+5CTdMo0aV5LfVFBk7r6EwoDbDvpCwJx2g8X+fVTAsoXgSVAuqrnjyViO8x5J/ z0Li6c/L+5LmPOTI9xwFNC04HKikxV8AfaJr+nvFAt7jHiUWSjzRfZodEiZo6+izHJv3 /U2SYnd3wljbNB+CwLYmEMftWO7C7i6Vt4LuZBBi9VzTFbKDrzWOlDs/TlNiI89u0o5/ mNmdyc+viHY1BAKCMzg7t/IIEqvGHuA8MVZLnBBxIVZZCOW5guOomRi4hNmmqtfCyK8L DDHg==
X-Gm-Message-State: AFeK/H1w0DYSp1YCyKqdxrU4SvE/IDhTivNNt9a8ZSQ3X6rBOjfrKQt/WuoUIWjjJCdOcy0eMrsIwj6h9IkJdQ==
X-Received: by 10.176.64.34 with SMTP id h31mr910460uad.89.1490905486642; Thu, 30 Mar 2017 13:24:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.181 with HTTP; Thu, 30 Mar 2017 13:24:16 -0700 (PDT)
In-Reply-To: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>  
From: Mark Smith 
Date: Fri, 31 Mar 2017 07:24:16 +1100
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: "Ackermann, Michael" 
Cc: Suresh Krishnan , "Leddy, John" , "draft-ietf-6man-rfc2460bis.all@ietf.org" , 6man WG ,  "ietf@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 20:24:53 -0000

The thing to keep in mind is that enterprises use technology to solve
business problems. Technology is a means to an end, not the end
itself.

For general Internet or internal networking problems, IPv6 doesn't
solve the problem any better than IPv4 does. That is why Enterprises
haven't adopted it for their Internet or general internal networks.
Adding IPv6 is actually worse - it just increases their capex and opex
for no business benefit.

I've heard SR recently called the next MPLS. So how many Enterprises
have adopted MPLS?

When Enterprises need to access IPv6 Internet services, they'll just
IPv6 enable their boundary Internet access security devices and mail
servers.

IPv6 will be used by Enterprises when it either provides a compelling
advantage over IPv4, or where a vendor's "turn key" solution uses it.
I've seen that recently with AMI smartmeter mesh networks.

Here in Victoria, AU, there are probably in the order of 1M+ IPv6 AMI
smart meters across multiple electricity distributors. They're using
IPv6 for that because that is what the vendor's end-to-end AMI
solution uses. They use IPv4 to access the OSS and servers that are
used to troubleshoot that network, and there is no real benefit for
the organisation to deploy IPv6 on their internal LANs to access those
servers.

Inventing a new IPv6 feature just to try to encourage adoption isn't
going to be that successful. The new feature has to be a compelling
solution to a problem that the enterprise has, that justifies the
additional and typically very large expense of deploying IPv6 to get
it.

Regards,
Mark.



On 31 March 2017 at 03:54, Ackermann, Michael  wrote:
> This is something I tried to say at the mic today, but I was too late.
> If we put potentially valuable use cases into the bucket of "Exceptions",=
  this becomes yet another excuse to delay or avoid adoption of IPv6 by the=
 very large percentage of Enterprises who have yet to do so (and have no se=
rious plans) today.
>
> I am hopeful that work in the IETF will provide features and hence motiva=
tion for us sadly delinquent Enterprises to begin actually using IPv6.    I=
 am concerned that perception of solutions being "Exceptions" or non standa=
rd, will cause consternation (warranted or not) and avoidance.
>
>
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Suresh Krishnan
> Sent: Thursday, March 30, 2017 9:30 AM
> To: Leddy, John 
> Cc: draft-ietf-6man-rfc2460bis.all@ietf.org; 6man WG ; iet=
f@ietf.org
> Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
>
> Hi John,
>   Thanks for chiming in. I recognize that you might have use cases that m=
ight be better off with header insertion but I think they should be handled=
 as and when they come up for consideration (e.g. in the SRv6 discussions).=
 Holding up this document is not going to help in any way in reinterpreting=
 what RFC2460 intended. My suggestion for proponents of safe header inserti=
on to write up how it is expected to work and have the discussion then.
>
> Thanks
> Suresh
>
>> On Mar 29, 2017, at 9:59 PM, Leddy, John  wrote:
>>
>>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan  wrote:
>>>
>>> NEW:
>>>
>>> With one exception, extension headers are not examined, processed,
>>> inserted, or deleted by any node along a packet's delivery path,
>>> until the packet reaches the node (or each of the set of nodes, in
>>> the case of multicast) identified in the Destination Address field of
>>> the IPv6 header...
>>>
>>> Please feel free to comment either privately or on list if you have any=
 concerns with this resolution going forward.
>>
>>
>> Suresh,
>>
>> I still have concerns that we are eliminating a tool that may prove very=
 helpful in migrations without understanding its value.
>>
>> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has be=
en long, operationally complex and full of unexpected challenges.
>> We are only now starting to make the transition from Dual Stack to IPV6 =
Only, there are still many unknowns on how to complete this migration.
>>
>> As we contemplate finishing this major Network shift =E2=80=93 We find o=
urselves in the early stages of another.
>>
>> The transition from Physical to Virtual Infrastructure.  Again, the migr=
ation will be long, operationally complex and full of unexpected challenges=
.
>>
>> In the old world with Servers running Applications in Physical locations=
 designed for very predictable loads; using an encap/decap tunnel to emulat=
e a physical circuit between locations has many attractive properties =E2=
=80=93 but that is compared to actually ordering and provisioning real circ=
uits between locations.
>>
>> In the new world of dynamic resources spun up on demand in distributed e=
nvironments across multiple providers, Applications having the Intelligence=
 and State to bring up their own required connectivity is very natural.  Th=
is is where we are putting the majority of our efforts.  SRv6 enables very =
attractive solutions by Applications building their own headers.
>>
>> The challenges come as we try to migrate and require these two infrastru=
ctures to Interoperate for a long time.
>> Burdening the new Virtual world with Old, Static circuit paradigms is no=
t optimal.
>> Supplementing the legacy infrastructure with an assist function seems
>> a reasonable solution.  (Ext Hdr insertion/deletion or encap/decap
>> tunnels)
>>
>> The preferred assist mechanism seems to be the one that allows the New
>> World to operate in its final preferred state, sending and receiving pac=
kets with their own headers. (SRv6) But what does an Application in the new=
 world due when it is attempting to communicate with an Application in the =
Old World?
>> Shouldn=E2=80=99t it build an SRv6 header?  That would mean that the ass=
ist function would need to be the last SID in the Segment List and be capab=
le of removing the SRH.
>> Wouldn=E2=80=99t it make sense for the assist function to do the same th=
ing in the reverse direction; an Old World Server talking to a New Virtual =
World Application?  Insert an SRH.
>>
>> If this insert/delete of an SRH is prematurely prohibited;  What is a re=
commended solution to the Real World problem above.  Not use case, we are i=
mplementing.
>>
>> Again; I=E2=80=99m worried we are eliminating a tool that may prove very
>> helpful, preclude its use in future IETF work and shutdown a path for
>> Innovation in Networking,
>>
>> Thank you for asking and listening to my concerns,
>>
>> John Leddy
>> Comcast
>>
>>
>>
>>
>>
>>
>
>
>
> The information contained in this communication is highly confidential an=
d is intended solely for the use of the individual(s) to whom this communic=
ation is directed. If you are not the intended recipient, you are hereby no=
tified that any viewing, copying, disclosure or distribution of this inform=
ation is prohibited. Please notify the sender, by electronic mail or teleph=
one, of any unintended receipt and delete the original message without maki=
ng any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are=
 nonprofit corporations and independent licensees of the Blue Cross and Blu=
e Shield Association.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Thu Mar 30 13:38:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CF21294A9 for ; Thu, 30 Mar 2017 13:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.092
X-Spam-Level: 
X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com
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 6B2OOsVRVfiP for ; Thu, 30 Mar 2017 13:38:37 -0700 (PDT)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5681294CC for ; Thu, 30 Mar 2017 13:38:35 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id A75DBC1638 for ; Thu, 30 Mar 2017 15:20:50 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id D5754C159C; Thu, 30 Mar 2017 15:20:49 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3EA0AFE04E; Thu, 30 Mar 2017 16:21:01 -0400 (EDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E7E68FE048; Thu, 30 Mar 2017 16:21:00 -0400 (EDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (unknown [216.32.181.17]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Thu, 30 Mar 2017 16:21:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com;  s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I6jTIIHr3/EjAkGyxJgsVVYE2Jp5WlnW+HRXyutfXWk=; b=xJFlWiBxIWpngerfOJgLdzuHLBFaubahDb1qHpNLP6RqAmwOpUj2vqJh4vT//7E9qUmexumBTceaf8xOvevg2dvrVD1cszy2DWkp13RoxiLV9+csTi34B8ISegO+BwdKbdBEA7qa1GG/ZnEkNWJWxoQ898HJDLOz1WlRrXCk/Q4=
Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Thu, 30 Mar 2017 20:20:46 +0000
Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1005.010; Thu, 30 Mar 2017 20:20:46 +0000
From: "Ackermann, Michael" 
To: Tim Chown , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
CC: IETF Discussion 
Subject: RE: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGssVmAgAC6+QCAAAergIAAIVqAgAAFggCAAASRAIAAEj+AgAAYQACAABLvAIAADMoQ
Date: Thu, 30 Mar 2017 20:20:46 +0000
Message-ID: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>     <5E233A42-42C7-4D16-A755-7E0314BFB2D4@jisc.ac.uk>
In-Reply-To: <5E233A42-42C7-4D16-A755-7E0314BFB2D4@jisc.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: jisc.ac.uk; dkim=none (message not signed) header.d=none;jisc.ac.uk; dmarc=none action=none header.from=bcbsm.com;
x-originating-ip: [2001:67c:370:128:e93e:cd10:473c:bf2a]
x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 7:eAvYwE0UesJpsAP1J8gLmGM59NT1giPSB44m8sHEZ1A6cI9HHdWowwgK3a5IckEsO0OdKeElF1CrmFly5Dqwu3uMBk1JLBU6fLJgxf+9SHgFyWKHnAILMqOLG/rQ5SedxT2t43xiLN90AWos3E0Q/Swhg+kmwL+uLeYWhoZ1KvDOCpko9JEcgCVAdXKSj96g7lE9hvTpLWeztiQO1i2b3H4/1CE1OIu5nGxj8yItN/XSeaF7w6c1gca5tnWzRRC8rqwxZQivTuj5/jFd2BkLkFLVRgoxduvPnusZGoohSFKpQdHMyne4WPPjDf3jKYb1YjhowHJk8P8TXwcmBYs0KA==; 20:HNOX2AS7TqGrsaBHMK3L2piTmqvVCqT0iSUrrJ/nxD35VW2pGZtNVFD5waJB57hQmF4daPJQUJvG2WqfcG3Bo9EmI12CokAnF7Be+Z3XYkbj5qT2wUEov15Fyqbpt6EgFddDAroQf6vDFLYjyLJBJ33eH/VOA3D2ukwrh/+NnzA=
x-ms-office365-filtering-correlation-id: ab0d56ad-78f4-46b5-475d-08d477aa3ffb
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY4PR14MB1368; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:; SRVR:CY4PR14MB1368; 
x-forefront-prvs: 02622CEF0A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39450400003)(39830400002)(377454003)(13464003)(24454002)(53546009)(8676002)(86362001)(81166006)(3660700001)(7736002)(8936002)(7696004)(2900100001)(305945005)(230783001)(74316002)(561944003)(33656002)(80792005)(5660300001)(189998001)(2950100002)(122556002)(25786009)(38730400002)(229853002)(2501003)(9686003)(53936002)(76176999)(55016002)(6306002)(50986999)(54356999)(99286003)(6246003)(2906002)(6506006)(3280700002)(4326008)(6116002)(6436002)(77096006)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 20:20:46.4808 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm02.z120.zixworks.com
X-VPM-GROUP-ID: 9d8f07ce-4bd3-4f04-88ad-b71316e0d211
X-VPM-MSG-ID: 77f73d2d-0879-455b-a30c-5aff5d9c7392
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 20:38:39 -0000

R3JlYXQgdGhvdWdodHMvaW5mbyBhbmQgdGhleSBhbGwgbWFrZSBzZW5zZSBmcm9tIGFuIElF
VEYgcGVyc3BlY3RpdmUuIA0KRnJvbSBhbiBlbnRlcnByaXNlIHBlcnNwZWN0aXZlLCBpdCBp
cyB1bmxpa2VseSB0aGF0IGFueW9uZSBpbiB0aGF0IHdvcmxkIGtub3dzIHdoYXQgbW92aW5n
IHRvIElTIG1lYW5zIG9yIGltcGxpZXMuICAgDQpTbyB0aGUgcHJvYmxlbSB0aGF0IEkgaGF2
ZSBpbiB0cnlpbmcgdG8gZ2V0IG15IGVudGVycHJpc2UsIG9yIHRoZSBtYW55IHdlIGhhdmUg
ZGlyZWN0IChvciBldmVuIGluZGlyZWN0KSBjb25uZWN0aW9ucyB3aXRoLCB0byBldmVuIFRI
SU5LIGFib3V0IElQdjYsIGlzIGNvbWluZyB1cCB3aXRoIHJlYXNvbnMgdG8gZG8gc28uICAg
VGhlcmUgYXJlIGEgY291cGxlIG9mIHJlYXNvbnMvZmVhdHVyZXMgdGhhdCBJIGhhdmUgaG9w
ZSBjb3VsZCBiZSBjb21wZWxsaW5nLiAgQnV0IGlmIHRob3NlIGZlYXR1cmVzIGRlcGVuZCBv
biBFSHMsIG9yIGFueXRoaW5nIHVuc3VwcG9ydGVkLCBmdXR1cmUgb3IgIkV4Y2VwdGlvbmFs
IiwgIHRoZXkgd2lsbCBub3QgYmUgY29tcGVsbGluZyBhdCBhbGwuICANCk15IHdvcmxkIGlz
IGEgdG91Z2ggc2VsbC4gICBJIGp1c3QgZG8gbm90IHdhbnQgaXQgdG8gZ2V0IGFueSB0b3Vn
aGVyLiAgDQpUaGFua3MNCk1pa2UNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IFRpbSBDaG93bg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDMwLCAyMDE3IDM6MjcgUE0NClRv
OiA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsgZHJhZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMu
YWxsQGlldGYub3JnDQpDYzogSUVURiBEaXNjdXNzaW9uIDxpZXRmQGlldGYub3JnPg0KU3Vi
amVjdDogUmU6IElFVEYgTGFzdCBDYWxsIGNvbmNsdXNpb24gZm9yIGRyYWZ0LWlldGYtNm1h
bi1yZmMyNDYwYmlzLTA4DQoNCkhpLA0KDQo+IE9uIDMwIE1hciAyMDE3LCBhdCAxOToxOSwg
56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD4gd3JvdGU6DQo+IA0KPiBBdCBUaHUs
IDMwIE1hciAyMDE3IDExOjUyOjQxIC0wNTAwLA0KPiBSb2JlcnQgUmFzenVrIDxyb2JlcnRA
cmFzenVrLm5ldD4gd3JvdGU6DQo+IA0KPj4gT2sgc28gdGlsbCBhIG5ldyBkb2N1bWVudCB1
cGRhdGVzIDI0NjBiaXMgYW55IGZ1cnRoZXIgd29yayBvbiBFSHMgaXMgDQo+PiBmcm96ZW4g
YXMgaXQgd291bGQgcmVmZXJlbmNlIDI0NjBiaXMgd2l0aCBuZXcgdGV4dC4gVGhhdCB3YXMg
bXkgbWFpbiBwb2ludC4NCj4gDQo+IEkgZG9uJ3QgZ2V0IHRoZSBsb2dpYy4uLmFuICJ1cGRh
dGUiIGNhbiBzdGFydCBpbW1lZGlhdGVseSBvbmNlIHN1Y2ggYSANCj4gZHJhZnQgbmV3IHBy
b3Bvc2FsIGlzIGF2YWlsYWJsZS4gIFRoZSB1cGRhdGUgd29uJ3QgYmUgZm9ybWFsbHkgDQo+
IGNvbXBsZXRlZCB1bnRpbCBpdCBnZXRzIHNvbWUgZm9ybWFsIHN0YXRlIGxpa2UgYSBzdGFu
ZGFyZCB0cmFjayBSRkMsIA0KPiBhbmQgaXQgd2lsbCB0YWtlIHRpbWUsIGJ1dCB0aGF0IHdv
dWxkbid0IG5lY2Vzc2FyaWx5IG1lYW4gYSBmdXJ0aGVyIA0KPiB3b3JrIGlzICJmcm96ZW4i
OyBpdCdzIG5vdCB2ZXJ5IGNsZWFyIHRvIG1lIHdoYXQgdGhpcyB0ZXJtIG1lYW5zIGluIA0K
PiB0aGlzIGNvbnRleHQsIGJ1dCBpdCdzIHF1aXRlIGNvbW1vbiBkZXZlbG9wbWVudCB0YWtl
cyBwbGFjZSB3aGlsZSB0aGUgDQo+IHNwZWMgaXMgYmVpbmcgZGlzY3Vzc2VkIGFzIGEgZHJh
ZnQsIGFuZCBpdCdzIGFsc28gbm90IHVuY29tbW9uIHNvbWUgDQo+IGNvbW1lcmNpYWwgb3Bl
cmF0b3JzIGV2ZW4gc3RhcnQgZGVwbG95aW5nIGl0LiAgT24gdGhlIG90aGVyIGhhbmQsIGV2
ZW4gDQo+IGlmIHdlIG5vdyBhZ3JlZWQgdGhhdCByZmMyNDYwYmlzIHNob3VsZCBleHBsaWNp
dGx5IGFsbG93IHN1Y2ggImZ1cnRoZXIgDQo+IHdvcmsiLCB0aGUgZGlzY3Vzc2lvbiBpdHNl
bGYgd291bGQgdGFrZSBsb25nIGFuZCB3b3VsZG4ndCBiZSBjb21wbGV0ZWQgDQo+IHNvb24u
DQo+IA0KPiBCdXQgSU1PIGl0J3MgaXJyZXNwb25zaWJsZSB0byBsZWF2ZSB0aGUgdGV4dCBh
bWJpZ3VvdXMgYW5kIGxldCBzb21lIA0KPiBvdGhlciBwZW9wbGUgbWlzdW5kZXJzdGFuZCBp
dCwgcG9zc2libHkgZXZlbiBtb3JlIGNhc3VhbGx5IGFuZC9vciBpbiANCj4gdGhlIGdsb2Jh
bCBJbnRlcm5ldCwgZm9yIHRoZSBjb21mb3J0IG9mIHNvbWUgcGFydGljdWxhciBmdXR1cmUg
d29yay4NCj4gSSB0aGluayB3ZSdyZSBub3cgdHJ5aW5nIHRvIGhlbHAgYXZvaWQgdGhlIGxh
dGVzdCBjbGFyaWZpY2F0aW9uIGluIA0KPiByZmMyNDYwYmlzIHRvIGJlIGludGVycHJldGVk
IGFzIGFuICJvdXRyaWdodCBiYW4iIG9mIGZ1dHVyZSB1cGRhdGVzIA0KPiB3aGlsZSBzdGls
bCB0cnlpbmcgdG8gYmUgcmVzcG9uc2libGUgZm9yIHRoZSBzb3VuZG5lc3Mgb2YgdGhlIGds
b2JhbCANCj4gSW50ZXJuZXQuICBJbiBteSB1bmRlcnN0YW5kaW5nIEJyaWFuJ3MgYWRkaXRp
b25hbCB0ZXh0IGlzIG9uZSBzdWNoIA0KPiBhdHRlbXB0IChJIGFsc28gcHJvcG9zZWQgdGV4
dCBpbiB0aGF0IHNlbnNlIGF0IHRoZSB0aW1lIG9mIFdHTEMsIA0KPiBhbHRob3VnaCBpdCB3
YXNuJ3QgYWRvcHRlZCBpbiB0aGUgZW5kKS4gIElmIHRoYXQgdGV4dCBpcyBzdGlsbCBub3Qg
DQo+IGVub3VnaCB3ZSBjYW4gZGlzY3VzcyBob3cgdG8gcGhyYXNlIGl0LiAgQW5kLCB3aGls
ZSBJIHN1c3BlY3QgcGVvcGxlIA0KPiB3aG8gd2FudGVkIHRvIGtlZXAgdGhlIGFtYmlndWl0
eSB3aWxsIG5ldmVyIGJlIHNhdGlzZmllZCB3aXRoIHRoZSANCj4gcmVzdWx0IGFzIGxvbmcg
YXMgdGhlIGFkZGVkIGNsYXJpZmljYXRpb24gcmVtYWlucywgSSBiZWxpZXZlIHRoYXQncyBh
IA0KPiByZWFzb25hYmxlIGNvbXByb21pc2UgdG8gYWNoaWV2ZSBhIGJhbGFuY2UgYmV0d2Vl
biBiZWluZyByZXNwb25zaWJsZSANCj4gYW5kIG5vdCAodW5pbnRlbnRpb25hbGx5KSBkaXNj
b3VyYWdpbmcgZnV0dXJlIHVwZGF0ZXMuDQoNClJlcGVhdGluZyB3aGF0IEkgc2FpZCBhdCB0
aGUgbWljLCBteSB2aWV3cyBlY2hvIHRob3NlIG9mIEppbm1laSwgTWljaGFlbCwgTG9yZW56
byBhbmQgQnJpYW4uIEkgYWdyZWUgd2l0aCB0aGUgZGVjaXNpb24gdG8gcHJvZ3Jlc3MgUkZD
MjQ2MC1iaXMgdG8gSVMgaW5jbHVkaW5nIFN1cmVzaOKAmXMgdGV4dC4gSeKAmWQgYWxzbyBs
aWtlIHRvIHNlZSBCcmlhbuKAmXMgc2hvcnQgYW1lbmRtZW50IGluY2x1ZGVkLCB3aGljaCBt
YWtlcyBleHBsaWNpdCBJbnRlcm5ldCBzY29wZSBhcyB0aGUgZGVmYXVsdCB0YXJnZXQuDQoN
CkFkdmFuY2luZyAyNDYwYmlzIGRvZXNu4oCZdCBmcmVlemUgd29yayBvbiBTUjsgdGhhdCB3
b3JrIGNhbiBjb250aW51ZSB0b2RheS4gSSBkb27igJl0IHNlZSB0aGUgbmV3IFNSIGhlYWRl
ciBpbnNlcnRpb24gZHJhZnQgY29tcGxldGluZyBpbiDigJxhIGNvdXBsZSBvZiB3ZWVrc+KA
nTsgaXTigJlzIG11Y2ggbW9yZSBsaWtlbHkgdG8gdGFrZSBzZXZlcmFsIG1vbnRocyBvciBl
dmVuIGEgeWVhciB0byBwcm9ncmVzcyB0aHJvdWdoIFdHIGFkb3B0aW9uIGFuZCBldmVudHVh
bCBwdWJsaWNhdGlvbiwgdG8gZW5zdXJlIGdvb2QgYW5kIHJvYnVzdCBpbnB1dC4gRm9yIGFk
b3B0aW9uLCBJ4oCZZCBleHBlY3QgbWFueSBwZW9wbGUgdG8gd2FudCB0aGUgZHJhZnQgdG8g
aW5jbHVkZSB0ZXh0IG9uIGEpIHdoeSB2YW5pbGxhIGVuY2Fwc3VsYXRpb24gaXMgbm90IHN1
ZmZpY2llbnQgYW5kIGIpIGhvdyB0aGUgaW5zZXJ0aW9uIGNhbiBndWFyYW50ZWVkIHRvIGJl
IGRvbmUgc2FmZWx5IGZvciBzcGVjaWZpYyBzY2VuYXJpbyhzKS4gQnV0IHRoYXTigJlzIGFs
bCB2ZXJ5IHBvc3NpYmxlLg0KDQpBbmQgcGxlYXNlIGRvIG5vdGUgdGhhdCBwdWJsaXNoaW5n
IDI0NjAtYmlzIGFzIGFuIEludGVybmV0IFN0YW5kYXJkIGRvZXMgbm90IHNldCBpdCBpbiBz
dG9uZS4gWW91ciBTUiB3b3JrIGNhbiB1cGRhdGUgaXQsIGFzIGNvdWxkIG90aGVyIGZ1dHVy
ZSBSRkMocykgb24gb3RoZXIgbmV3IG1lY2hhbmlzbShzKSBvciBpbm5vdmF0aW9uKHMpIHRo
YXQgaGF2ZSB5ZXQgdG8gYmUgcHJvcG9zZWQuIEnigJlkIGFyZ3VlIHRoYXQgaXTigJlzIHBy
ZXR0eSBsaWtlbHkgd2XigJlsbCBzZWUgb3RoZXIgUkZDcyB1cGRhdGUgMjQ2MC1iaXM7IHRo
YXQgc2hvdWxkbuKAmXQgYmUgYSBzdXJwcmlzZSBpZiBpdOKAmXMgYSBwcm90b2NvbCB0aGF0
IHdl4oCZbGwgYmUgdXNpbmcgZm9yIHRoZSBuZXh0IDIwLTMwIHllYXJzIG9yIG1vcmUuIEZv
ciBlYWNoLCB3ZeKAmWxsIGp1c3Qgc2VlIOKAnFVwZGF0ZWQgYnk64oCdIHRhZ3MgaW4gdGhl
IFJGQyBoZWFkZXIuIFRoZSBjdXJyZW50IFJGQzI0NjAgaGFzIGFjY3VtdWxhdGVkIG5pbmUg
c3VjaCB0YWdzIGluIDE5IHllYXJzLCBzbyBhYm91dCBvbmUgZXZlcnkgdHdvIHllYXJzLg0K
DQpPbiBlbnRlcnByaXNlIGRlcGxveW1lbnQgSeKAmWQgYXJndWUgdGhhdCwgaWYgYW55dGhp
bmcsIG1vdmluZyB0byBJUyBzaG91bGQgaGVscCBzdHJlbmd0aGVuIHRoZSBjYXNlIGZvciBk
ZXBsb3ltZW50LCBiZWNhdXNlIGl0IGNvbmZpcm1zIHByb3ZlbiB3aWRlc2NhbGUgZGVwbG95
bWVudC4gIFRoZSBmb3VyIGNyaXRlcmlhIGZvciBtb3ZpbmcgdG8gSVMgYXJlIGRlc2NyaWJl
ZCBpbiBTZWN0aW9uIDIuMiBvZiBSRkM2NDEwLCBidXQgYXJlIHN1bW1hcmlzZWQgYXMgImEg
aGlnaCBkZWdyZWUgb2YgdGVjaG5pY2FsIG1hdHVyaXR5IGFuZCBieSBhIGdlbmVyYWxseSBo
ZWxkIGJlbGllZiB0aGF0IHRoZSBzcGVjaWZpZWQgcHJvdG9jb2wgb3Igc2VydmljZSBwcm92
aWRlcyBzaWduaWZpY2FudCBiZW5lZml0IHRvIHRoZSBJbnRlcm5ldCBjb21tdW5pdHnigJ0u
IEnigJlkIGhvcGUgd2UgaGF2ZSB2ZXJ5IHN0cm9uZyBjb25zZW5zdXMgb24gdGhhdCBzdGF0
ZW1lbnQuDQoNClRpbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3Vw
IG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZw0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRp
b24gaXMgaGlnaGx5IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0
aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIHRvIHdob20gdGhpcyBjb21tdW5pY2F0aW9u
IGlzIGRpcmVjdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5
b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB2aWV3aW5nLCBjb3B5aW5nLCBkaXNj
bG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0
ZWQuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciwgYnkgZWxlY3Ryb25pYyBtYWlsIG9yIHRl
bGVwaG9uZSwgb2YgYW55IHVuaW50ZW5kZWQgcmVjZWlwdCBhbmQgZGVsZXRlIHRoZSBvcmln
aW5hbCBtZXNzYWdlIHdpdGhvdXQgbWFraW5nIGFueSBjb3BpZXMuCiAKIEJsdWUgQ3Jvc3Mg
Qmx1ZSBTaGllbGQgb2YgTWljaGlnYW4gYW5kIEJsdWUgQ2FyZSBOZXR3b3JrIG9mIE1pY2hp
Z2FuIGFyZSBub25wcm9maXQgY29ycG9yYXRpb25zIGFuZCBpbmRlcGVuZGVudCBsaWNlbnNl
ZXMgb2YgdGhlIEJsdWUgQ3Jvc3MgYW5kIEJsdWUgU2hpZWxkIEFzc29jaWF0aW9uLgo=


From nobody Thu Mar 30 13:45:09 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B81129470; Thu, 30 Mar 2017 13:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 mw7lgibD3uFj; Thu, 30 Mar 2017 13:45:01 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20201293D9; Thu, 30 Mar 2017 13:45:01 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id y18so1469693itc.1; Thu, 30 Mar 2017 13:45:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pRGosb/buy6mVCYdGDfkT8YZSNflXKzHXljqtkvG2H8=; b=b5kT1pKZ3pXOFU88nnYOOJi+pSoYs8i34UaSy4TbP4uCOdYnImotJPP+B4bTVGEWXX 4Df4vv19iMCZcBGeV8JQlp9I+oTFAnXUhSYu81a6f0iYTpX6+O9eKuiG1KCuqs4sGOC8 IV5VQjesvKaK7SBydK5Ec9yUE7ZVz1b8JmGxDmiCWV7qYlmy6ImN8XAAbWsZlzpC0YIJ JWEHv1QRGYkUXTxUl9eqbk6INRnM5ZUqA/4MAWVSnI+oN67Ddmy/lizG+gWSImvGUuBm cv4afvZ5UmqlC0r9wkZajHT7+hI7JE7F8HL0Fr+fRQKykRC6DmGL39UY+kS7yd1Rc5vS 2MDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=pRGosb/buy6mVCYdGDfkT8YZSNflXKzHXljqtkvG2H8=; b=sG3KMp0O5+48xt0QWaqfy0vCZe49NBcidgkwkVeuCRT2BJvA5xyzFwymo3XUUhXkul Z9fOLAI4q1QcqE4yBw6UygYtEtMDhRGJiIb5eGVz137PCk/ryJzvNKmdTfohPWn3t4+s sLSM5jAIyTPPZIskGx0tdHL2aipMp0l9kADpLZYKfFJJqQ6fBrePPWwJrz5At383fGSu l80PjkrXp5yItxQtYIDxjuLG8e/hpy4rYf60cXQIlNtw25vIZFCIynhHg8aDLmnUmOed tF+L0GwOvNWWYqWAdCtydbqghRCJdPaT/NJ0uZNR9iHRV1H6EIdixiLCnR1+xkAtjdmS od4w==
X-Gm-Message-State: AFeK/H1vFgvXyqB8ETRUL6TRykiKPRuV3ufDCm0LFMwetnhghEwbCsiuoCIxwNO+zi96ovYo7E75tCu6wd7CZg==
X-Received: by 10.36.85.194 with SMTP id e185mr166821itb.39.1490906701028; Thu, 30 Mar 2017 13:45:01 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 13:44:59 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 13:44:59 -0700 (PDT)
In-Reply-To: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com>   
From: Robert Raszuk 
Date: Thu, 30 Mar 2017 15:44:59 -0500
X-Google-Sender-Auth: mKCh2bGIY2_AGox3ahNqnu4X-z0
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Mark Smith 
Cc: IETF Discussion , "Leddy, John" ,  "Ackermann, Michael" , 6man WG ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1143d1484f0c27054bf8c466
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 20:45:07 -0000

--001a1143d1484f0c27054bf8c466
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Mark,

And this is precisely what we are saying.

Enterprise I work for has global L3VPN network with MPLS, LDP, 3107 across
3 ASes spanning the globe. Obviously with that you also need various
InterAS options.

On top of that there is some limited need for inter-as TE so you employ
static EROs and RSVP-TE.

We have need to do efficient p2mp data distribution in WAN which again
requires another set of different protocols.

Imagine opex with all of the above.

And at this time SRv6 delivers all of the above applications with huge
reduction of need of various protocols mentioned above.

That was the point.

Cheers,
R.





On Mar 30, 2017 15:24, "Mark Smith"  wrote:

> The thing to keep in mind is that enterprises use technology to solve
> business problems. Technology is a means to an end, not the end
> itself.
>
> For general Internet or internal networking problems, IPv6 doesn't
> solve the problem any better than IPv4 does. That is why Enterprises
> haven't adopted it for their Internet or general internal networks.
> Adding IPv6 is actually worse - it just increases their capex and opex
> for no business benefit.
>
> I've heard SR recently called the next MPLS. So how many Enterprises
> have adopted MPLS?
>
> When Enterprises need to access IPv6 Internet services, they'll just
> IPv6 enable their boundary Internet access security devices and mail
> servers.
>
> IPv6 will be used by Enterprises when it either provides a compelling
> advantage over IPv4, or where a vendor's "turn key" solution uses it.
> I've seen that recently with AMI smartmeter mesh networks.
>
> Here in Victoria, AU, there are probably in the order of 1M+ IPv6 AMI
> smart meters across multiple electricity distributors. They're using
> IPv6 for that because that is what the vendor's end-to-end AMI
> solution uses. They use IPv4 to access the OSS and servers that are
> used to troubleshoot that network, and there is no real benefit for
> the organisation to deploy IPv6 on their internal LANs to access those
> servers.
>
> Inventing a new IPv6 feature just to try to encourage adoption isn't
> going to be that successful. The new feature has to be a compelling
> solution to a problem that the enterprise has, that justifies the
> additional and typically very large expense of deploying IPv6 to get
> it.
>
> Regards,
> Mark.
>
>
>
> On 31 March 2017 at 03:54, Ackermann, Michael 
> wrote:
> > This is something I tried to say at the mic today, but I was too late.
> > If we put potentially valuable use cases into the bucket of
> "Exceptions",  this becomes yet another excuse to delay or avoid adoption
> of IPv6 by the very large percentage of Enterprises who have yet to do so
> (and have no serious plans) today.
> >
> > I am hopeful that work in the IETF will provide features and hence
> motivation for us sadly delinquent Enterprises to begin actually using
> IPv6.    I am concerned that perception of solutions being "Exceptions" o=
r
> non standard, will cause consternation (warranted or not) and avoidance.
> >
> >
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Suresh Krishnan
> > Sent: Thursday, March 30, 2017 9:30 AM
> > To: Leddy, John 
> > Cc: draft-ietf-6man-rfc2460bis.all@ietf.org; 6man WG ;
> ietf@ietf.org
> > Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-0=
8
> >
> > Hi John,
> >   Thanks for chiming in. I recognize that you might have use cases that
> might be better off with header insertion but I think they should be
> handled as and when they come up for consideration (e.g. in the SRv6
> discussions). Holding up this document is not going to help in any way in
> reinterpreting what RFC2460 intended. My suggestion for proponents of saf=
e
> header insertion to write up how it is expected to work and have the
> discussion then.
> >
> > Thanks
> > Suresh
> >
> >> On Mar 29, 2017, at 9:59 PM, Leddy, John 
> wrote:
> >>
> >>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan <
> suresh.krishnan@ericsson.com> wrote:
> >>>
> >>> NEW:
> >>>
> >>> With one exception, extension headers are not examined, processed,
> >>> inserted, or deleted by any node along a packet's delivery path,
> >>> until the packet reaches the node (or each of the set of nodes, in
> >>> the case of multicast) identified in the Destination Address field of
> >>> the IPv6 header...
> >>>
> >>> Please feel free to comment either privately or on list if you have
> any concerns with this resolution going forward.
> >>
> >>
> >> Suresh,
> >>
> >> I still have concerns that we are eliminating a tool that may prove
> very helpful in migrations without understanding its value.
> >>
> >> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has
> been long, operationally complex and full of unexpected challenges.
> >> We are only now starting to make the transition from Dual Stack to IPV=
6
> Only, there are still many unknowns on how to complete this migration.
> >>
> >> As we contemplate finishing this major Network shift =E2=80=93 We find
> ourselves in the early stages of another.
> >>
> >> The transition from Physical to Virtual Infrastructure.  Again, the
> migration will be long, operationally complex and full of unexpected
> challenges.
> >>
> >> In the old world with Servers running Applications in Physical
> locations designed for very predictable loads; using an encap/decap tunne=
l
> to emulate a physical circuit between locations has many attractive
> properties =E2=80=93 but that is compared to actually ordering and provis=
ioning
> real circuits between locations.
> >>
> >> In the new world of dynamic resources spun up on demand in distributed
> environments across multiple providers, Applications having the
> Intelligence and State to bring up their own required connectivity is ver=
y
> natural.  This is where we are putting the majority of our efforts.  SRv6
> enables very attractive solutions by Applications building their own
> headers.
> >>
> >> The challenges come as we try to migrate and require these two
> infrastructures to Interoperate for a long time.
> >> Burdening the new Virtual world with Old, Static circuit paradigms is
> not optimal.
> >> Supplementing the legacy infrastructure with an assist function seems
> >> a reasonable solution.  (Ext Hdr insertion/deletion or encap/decap
> >> tunnels)
> >>
> >> The preferred assist mechanism seems to be the one that allows the New
> >> World to operate in its final preferred state, sending and receiving
> packets with their own headers. (SRv6) But what does an Application in th=
e
> new world due when it is attempting to communicate with an Application in
> the Old World?
> >> Shouldn=E2=80=99t it build an SRv6 header?  That would mean that the a=
ssist
> function would need to be the last SID in the Segment List and be capable
> of removing the SRH.
> >> Wouldn=E2=80=99t it make sense for the assist function to do the same =
thing in
> the reverse direction; an Old World Server talking to a New Virtual World
> Application?  Insert an SRH.
> >>
> >> If this insert/delete of an SRH is prematurely prohibited;  What is a
> recommended solution to the Real World problem above.  Not use case, we a=
re
> implementing.
> >>
> >> Again; I=E2=80=99m worried we are eliminating a tool that may prove ve=
ry
> >> helpful, preclude its use in future IETF work and shutdown a path for
> >> Innovation in Networking,
> >>
> >> Thank you for asking and listening to my concerns,
> >>
> >> John Leddy
> >> Comcast
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > The information contained in this communication is highly confidential
> and is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue Cross an=
d
> Blue Shield Association.
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>

--001a1143d1484f0c27054bf8c466
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Hi Mark,

    And=
 this is precisely what we are saying.

    Enterprise I work for has global L3VPN network with MPLS, LD=
P, 3107 across 3 ASes spanning the globe. Obviously with that you also need=
 various InterAS options.

    On top of that there is some limited need for inter-as TE so you employ s=
tatic EROs and RSVP-TE.

    =
We have need to do efficient p2mp data distribution in WAN which again requ=
ires another set of different protocols.

    <=
div dir=3D"auto">Imagine opex with all of the above.

    And at this time SRv6 delivers all of the abov=
e applications with huge reduction of need of various protocols mentioned a=
bove.

    That was the point=
.

    Cheers,
    R.


    <=
div dir=3D"auto">


    On Mar 30, 2017 15:24, "Ma=
rk Smith" <markzzzsmith@g=
mail.com> wrote:
    The thing to keep in mind is that enterprises use technology to solve
business problems. Technology is a means to an end, not the end
    
itself.
    

    
For general Internet or internal networking problems, IPv6 doesn't
    
solve the problem any better than IPv4 does. That is why Enterprises
    
haven't adopted it for their Internet or general internal networks.
    
Adding IPv6 is actually worse - it just increases their capex and opex
    
for no business benefit.
    

    
I've heard SR recently called the next MPLS. So how many Enterprises
have adopted MPLS?
    

    
When Enterprises need to access IPv6 Internet services, they'll just
IPv6 enable their boundary Internet access security devices and mail
    
servers.
    

    
IPv6 will be used by Enterprises when it either provides a compelling
    
advantage over IPv4, or where a vendor's "turn key" solution =
uses it.
    
I've seen that recently with AMI smartmeter mesh networks.
    

    
Here in Victoria, AU, there are probably in the order of 1M+ IPv6 AMI
    
smart meters across multiple electricity distributors. They're using
IPv6 for that because that is what the vendor's end-to-end AMI
    
solution uses. They use IPv4 to access the OSS and servers that are
    
used to troubleshoot that network, and there is no real benefit for
    
the organisation to deploy IPv6 on their internal LANs to access those
    
servers.
    

    
Inventing a new IPv6 feature just to try to encourage adoption isn't
going to be that successful. The new feature has to be a compelling
    
solution to a problem that the enterprise has, that justifies the
    
additional and typically very large expense of deploying IPv6 to get
    
it.
    

    
Regards,
    
Mark.
    

    

    

    
On 31 March 2017 at 03:54, Ackermann, Michael <MAckermann@bcbsm.com> wrote:
    
> This is something I tried to say at the mic today, but I was too late.=

    
> If we put potentially valuable use cases into the bucket of "Exce=
ptions",=C2=A0 this becomes yet another excuse to delay or avoid adopt=
ion of IPv6 by the very large percentage of Enterprises who have yet to do =
so (and have no serious plans) today.
    
>
    
> I am hopeful that work in the IETF will provide features and hence mot=
ivation for us sadly delinquent Enterprises to begin actually using IPv6.=
=C2=A0 =C2=A0 I am concerned that perception of solutions being "Excep=
tions" or non standard, will cause consternation (warranted or not) an=
d avoidance.
    
>
    
>
    
> -----Original Message-----
    
> From: ipv6 [mailto:ipv6-bounc=
es@ietf.org] On Behalf Of Suresh Krishnan
    
> Sent: Thursday, March 30, 2017 9:30 AM
    
> To: Leddy, John <John_Led=
dy@comcast.com>
    
> Cc: draft-i=
etf-6man-rfc2460bis.all@ietf.org; 6man WG <ipv6@ietf.org>; ietf@i=
etf.org
    
> Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-=
08
    
>
    
> Hi John,
    
>=C2=A0 =C2=A0Thanks for chiming in. I recognize that you might have use=
 cases that might be better off with header insertion but I think they shou=
ld be handled as and when they come up for consideration (e.g. in the SRv6 =
discussions). Holding up this document is not going to help in any way in r=
einterpreting what RFC2460 intended. My suggestion for proponents of safe h=
eader insertion to write up how it is expected to work and have the discuss=
ion then.
    
>
    
> Thanks
    
> Suresh
    
>
    
>> On Mar 29, 2017, at 9:59 PM, Leddy, John <John_Leddy@comcast.com> wrote:
    
>>
    
>>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan <suresh.krishnan@ericsson.com> wro=
te:
    
>>>
    
>>> NEW:
    
>>>
    
>>> With one exception, extension headers are not examined, proces=
sed,
    
>>> inserted, or deleted by any node along a packet's delivery=
 path,
    
>>> until the packet reaches the node (or each of the set of nodes=
, in
    
>>> the case of multicast) identified in the Destination Address f=
ield of
    
>>> the IPv6 header...
    
>>>
    
>>> Please feel free to comment either privately or on list if you=
 have any concerns with this resolution going forward.
    
>>
    
>>
    
>> Suresh,
    
>>
    
>> I still have concerns that we are eliminating a tool that may prov=
e very helpful in migrations without understanding its value.
    
>>
    
>> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 =
Only; has been long, operationally complex and full of unexpected challenge=
s.
    
>> We are only now starting to make the transition from Dual Stack to=
 IPV6 Only, there are still many unknowns on how to complete this migration=
.
    
>>
    
>> As we contemplate finishing this major Network shift =E2=80=93 We =
find ourselves in the early stages of another.
    
>>
    
>> The transition from Physical to Virtual Infrastructure.=C2=A0 Agai=
n, the migration will be long, operationally complex and full of unexpected=
 challenges.
    
>>
    
>> In the old world with Servers running Applications in Physical loc=
ations designed for very predictable loads; using an encap/decap tunnel to =
emulate a physical circuit between locations has many attractive properties=
 =E2=80=93 but that is compared to actually ordering and provisioning real =
circuits between locations.
    
>>
    
>> In the new world of dynamic resources spun up on demand in distrib=
uted environments across multiple providers, Applications having the Intell=
igence and State to bring up their own required connectivity is very natura=
l.=C2=A0 This is where we are putting the majority of our efforts.=C2=A0 SR=
v6 enables very attractive solutions by Applications building their own hea=
ders.
    
>>
    
>> The challenges come as we try to migrate and require these two inf=
rastructures to Interoperate for a long time.
    
>> Burdening the new Virtual world with Old, Static circuit paradigms=
 is not optimal.
    
>> Supplementing the legacy infrastructure with an assist function se=
ems
    
>> a reasonable solution.=C2=A0 (Ext Hdr insertion/deletion or encap/=
decap
    
>> tunnels)
    
>>
    
>> The preferred assist mechanism seems to be the one that allows the=
 New
    
>> World to operate in its final preferred state, sending and receivi=
ng packets with their own headers. (SRv6) But what does an Application in t=
he new world due when it is attempting to communicate with an Application i=
n the Old World?
    
>> Shouldn=E2=80=99t it build an SRv6 header?=C2=A0 That would mean t=
hat the assist function would need to be the last SID in the Segment List a=
nd be capable of removing the SRH.
    
>> Wouldn=E2=80=99t it make sense for the assist function to do the s=
ame thing in the reverse direction; an Old World Server talking to a New Vi=
rtual World Application?=C2=A0 Insert an SRH.
    
>>
    
>> If this insert/delete of an SRH is prematurely prohibited;=C2=A0 W=
hat is a recommended solution to the Real World problem above.=C2=A0 Not us=
e case, we are implementing.
    
>>
    
>> Again; I=E2=80=99m worried we are eliminating a tool that may prov=
e very
    
>> helpful, preclude its use in future IETF work and shutdown a path =
for
    
>> Innovation in Networking,
    
>>
    
>> Thank you for asking and listening to my concerns,
    
>>
    
>> John Leddy
    
>> Comcast
    
>>
    
>>
    
>>
    
>>
    
>>
    
>>
    
>
    
>
    
>
    
> The information contained in this communication is highly confidential=
 and is intended solely for the use of the individual(s) to whom this commu=
nication is directed. If you are not the intended recipient, you are hereby=
 notified that any viewing, copying, disclosure or distribution of this inf=
ormation is prohibited. Please notify the sender, by electronic mail or tel=
ephone, of any unintended receipt and delete the original message without m=
aking any copies.
    
>
    
>=C2=A0 Blue Cross Blue Shield of Michigan and Blue Care Network of Mich=
igan are nonprofit corporations and independent licensees of the Blue Cross=
 and Blue Shield Association.
    
> ------------------------------------------------------------=
--------
    
> IETF IPv6 working group mailing list
    
> ipv6@ietf.org
    
> Administrative Requests: https://www.ietf.org/mailman=
/listinfo/ipv6
    
> ------------------------------------------------------------=
--------
    

    

    

--001a1143d1484f0c27054bf8c466--


From nobody Thu Mar 30 13:48:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A109A1294B4; Thu, 30 Mar 2017 13:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 vfzLOwZp-1ez; Thu, 30 Mar 2017 13:48:33 -0700 (PDT)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id E3B701270A7; Thu, 30 Mar 2017 13:48:33 -0700 (PDT)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 30 Mar 2017 20:48:33 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 2CE12D788B; Thu, 30 Mar 2017 13:48:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=R6/E6qQB9Vdy8Fmo4vFMT5KkYaU=; b= aYHRnINlSPUF6SgDQU8JpPNMEQUriGs0Zj2raMb38isbtW7LRcztn9Rw4jZxIKhI x52yMAqTXfplknHXcCWznVlWIC5TLwQd6aogR4DSoTIVb/PwDPermZfw2xkg059K s/FKgpQSZzWNJjZNVgLskjqKvZ2T/vHVcs0loiYL2po=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=oXy8lBJKZvg8KOPLehmzRyp ML/Q45Ys+qV8Ml6zPhenVXrKn7TNJ0G0WpzUtsKe/jRMc5BK81TKkKlAzy/2b0BO OKx2aMR/YuJccSk2bWl7OIqIXzTpQ6RWuLUabmIm4i1SzqAabHrItS+foxZn9ZGj mM7OgD5ifnrswxuFxgXI=
Received: from h.hanazo.no (dhcp-8e77.meeting.ietf.org [31.133.142.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 13A96D788A; Thu, 30 Mar 2017 13:48:33 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 18B9AA6BF52F; Thu, 30 Mar 2017 15:48:34 -0500 (CDT)
From: otroan@employees.org
Message-Id: <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_6EEA9F65-61B6-4EAE-A7B6-8F3ECDF9BD3F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Date: Thu, 30 Mar 2017 15:48:33 -0500
In-Reply-To: 
Cc: Suresh Krishnan , 6man WG , IETF Discussion , "Leddy, John" , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
To: Robert Raszuk 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>   
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 20:48:37 -0000

--Apple-Mail=_6EEA9F65-61B6-4EAE-A7B6-8F3ECDF9BD3F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Robert,

> Ok so till a new document updates 2460bis any further work on EHs is =
frozen as it would reference 2460bis with new text. That was my main =
point.
>=20
> And what current EH implementations are supposed to do in the mean =
time ? Would IANA allocate codepoints for EH work before 2460bis is =
formally updated which in the current IETF speed is easy 2+years ?
>=20
> Note that without the proposed clarification none of the above =
obstacles exist.

Write a document describing the mechanism using header insertion. That =
document should cover the issues raised with header insertion in =
general. I don't think the document should update 2460bis. The general =
restriction still stands.

Best regards,
Ole

--Apple-Mail=_6EEA9F65-61B6-4EAE-A7B6-8F3ECDF9BD3F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJY3W8hAAoJEL7aWKiYQt92oekP/jtEM/Mv2VGRwdthn85nF/u0
Zi8kx+ntOl9Lcydv1BOYGkCWzYDWyImzkSFCSvee4GJ94Do2obV7kVRyYX+eQGKd
UhTBf/uDjX7dUDsSk9v0qqiyw2jA3BTTn+dvhWF+9SG1B+45Cx8qr9qnir8G20sw
8Y+DssH3NF8Uq0gzNamlMgbv7LN+sXRlT9eDVV9G+NEg+6dEatjPfcNkE4FK+zjI
DlSWwfwz//nJeOLrGQC4q8QH94B+7MF1U7rrKi+XTkz0R8BW4m7yBofuK45d9aCC
T3oIEiHqOiEG3TsN0oA2YnSkvb0DhoeGq8ZIKxl7u5qCdtgDlXDTt7IrgrBvK1hG
dGBhPlvvWRluZkWlAcvZjrtr1CMGrjCO4O7B5SCUuotXiCw/nbTNk38nB7hN468y
2L2oHqDC6MQaX1IscVTcT5WFQYeVRM456fuMjEIyqxClVy8du5q7xrEUdJ5FOhr8
KRnppK5qKspw+28mJ2fMLT0TlKCsqP0Z+8Us3KtyBAfIpX3McBuCLMZaL3tGQBK6
ngcJBd+BtIwBGdbO0YFjeH9F1wOG3ZcMTtDsLnlOFPcFziz6XO1VDjg/QRrX9+jU
ZPZlKJbO5uASFeRj+aP7AYA+nSlk5iwXkeOLfvYE7fl0/CUhtgf2N9XQZVAgsj5G
hvyRCOmu2CN1ZL2JRst2
=sV/U
-----END PGP SIGNATURE-----

--Apple-Mail=_6EEA9F65-61B6-4EAE-A7B6-8F3ECDF9BD3F--


From nobody Thu Mar 30 13:55:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9166D129543; Thu, 30 Mar 2017 13:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RBk_3X708ev9; Thu, 30 Mar 2017 13:55:26 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A501294A9; Thu, 30 Mar 2017 13:55:25 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id 68so3726303itx.0; Thu, 30 Mar 2017 13:55:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AixT/WLWTOfZZpk0BxcpNSjX4D5f6CEkuMsD1cSvhis=; b=UJjuh6gDOraEu+aNVO4UDmpFZo9vb/4Ko+NmYb/lMS4DN0XlXcj24HQmL1waTUpcvj hQ3FCmzObLIKMgH+wn24ej6kGEEwUP4/JZvhEv+Fb6IwNpMLE1cmzqXetKEriqEzwNiE ElttXj5OzRRWYDNIJK6c57IlVB9TWWKazfVqNKpveHwhKyRqqEddFJc/YHPuKnDDylmf ITL2Mv5ZQXrFpVVzSavw7MJJDWReMaZkT1E4Hxngljlb/yar66l9eDR0S7I8CHF1xfLx EW0L/vuyVRR5fpVKqv9TLnC1CkhiD0REbqV+/cLcEJVtcA+rBNsulaU1Q3lv9lBh7AlI uTEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AixT/WLWTOfZZpk0BxcpNSjX4D5f6CEkuMsD1cSvhis=; b=jn6ekjPosguP8vp3w5UcpvRkVTMPslka904HMjhDP8dmiyTByJZObmsnpFMa+Yncyk nz0uHyGehy0uhYuOCDkz68kRP+c/p3kJjPv/0hSVQzA/uiyG9oB8ZYnm/8cN6+DIoAqs x/ibxzsgZIqG7dRoyLW0wbO9DzzVlavDybnOUYyHyapZNeO6rEMfJr5BpeXWOOu9aYdN HI5RCrkKkPUShskPncba1eMt5Hq3C3+y2K9sb67v10dAqsYoyGibXVWg0FisO1qBC5xQ K9nioXvQaVS4PB7ZOKhu5hr5zPkrvuA5hLeZX+qQWQAh1LpCdY8XeYaWpREBNRtoaxCN /ipg==
X-Gm-Message-State: AFeK/H2LOPWM52oT+VXRBNlsCfZxOV+ZDkMbBhDz6lQu511rKNkw+soMlyXnQrvF+TLaWK91e1DE0CMKa36xwA==
X-Received: by 10.36.90.144 with SMTP id v138mr303222ita.24.1490907325175; Thu, 30 Mar 2017 13:55:25 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 13:55:23 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 13:55:23 -0700 (PDT)
In-Reply-To: <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>
From: Robert Raszuk 
Date: Thu, 30 Mar 2017 15:55:23 -0500
X-Google-Sender-Auth: 5sgGtpmhSpPUDVnaclKbRTtLkGI
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: otroan@employees.org
Cc: Suresh Krishnan , "Leddy, John" ,  IETF Discussion , 6man WG ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11429e7882a8de054bf8e9d9
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 20:55:28 -0000

--001a11429e7882a8de054bf8e9d9
Content-Type: text/plain; charset=UTF-8

Ole,

Correct me if I am missing someting but the entire debate is not about
describing or not header insertion.

I am under assumption that originating hosts still can legally insert it.

It is all about to modify EH in flight - right ? Moreover concerns raised
are about side effects of it like MTU .. not lack of instructions on how to
insert, modify or remove EH elements.

So what exactly are you expecting WG to deliver as next step if 2460bis
goes fwd ? Is detecting the max MTU on end to end path even in 6man's
charter ?

Cheers,
R.

On Mar 30, 2017 15:48,  wrote:

> Robert,
>
> > Ok so till a new document updates 2460bis any further work on EHs is
> frozen as it would reference 2460bis with new text. That was my main point.
> >
> > And what current EH implementations are supposed to do in the mean time
> ? Would IANA allocate codepoints for EH work before 2460bis is formally
> updated which in the current IETF speed is easy 2+years ?
> >
> > Note that without the proposed clarification none of the above obstacles
> exist.
>
> Write a document describing the mechanism using header insertion. That
> document should cover the issues raised with header insertion in general. I
> don't think the document should update 2460bis. The general restriction
> still stands.
>
> Best regards,
> Ole
>

--001a11429e7882a8de054bf8e9d9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Ole,

    Correct=
 me if I am missing someting but the entire debate is not about describing =
or not header insertion.

    I am under assumption that originating hosts still can legally insert it.<=
/div>

    It is all about to modif=
y EH in flight - right ? Moreover concerns raised are about side effects of=
 it like MTU .. not lack of instructions on how to insert, modify or remove=
 EH elements.

    So what ex=
actly are you expecting WG to deliver as next step if 2460bis goes fwd ? Is=
 detecting the max MTU on end to end path even in 6man's charter ?

    Cheers,
    R.

    =
On Mar 30, 2017 15:48,  <otroan@=
employees.org> wrote:
    Robert,
    

    
> Ok so till a new document updates 2460bis any further work on EHs is f=
rozen as it would reference 2460bis with new text. That was my main point.<=
br>
>
    
> And what current EH implementations are supposed to do in the mean tim=
e ? Would IANA allocate codepoints for EH work before 2460bis is formally u=
pdated which in the current IETF speed is easy 2+years ?
    
>
    
> Note that without the proposed clarification none of the above obstacl=
es exist.
    

    
Write a document describing the mechanism using header insertion. That docu=
ment should cover the issues raised with header insertion in general. I don=
't think the document should update 2460bis. The general restriction st=
ill stands.
    

    
Best regards,
    
Ole
    

    

--001a11429e7882a8de054bf8e9d9--


From nobody Thu Mar 30 13:55:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077EE1294CC for ; Thu, 30 Mar 2017 13:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 FmnPcQUUR3Tb for ; Thu, 30 Mar 2017 13:55:42 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812FA129583 for ; Thu, 30 Mar 2017 13:55:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14496; q=dns/txt; s=iport; t=1490907338; x=1492116938; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pwcTQyEKTIc+7ytfWs9+h2DPP5HvDvomByB2mHOZ5Vk=; b=cjvFDBldT6HDo8IFVwbXpnQK54M2u9bG3Ow/kIH9UlwCKewHG482YrrF MsWarM/lypxwTPNODvwbyyjCgTAl+tWX6RyaYVctVacl7/pY4GVXwhrF4 u41Yk7x88QoVCZ8pJ250aJDn39GSoykoZrxEXVePVUUmXur9/mZHbbs7/ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAgBPcN1Y/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgysrYYELB4NbihGRNh+IGY03gg4fC4V4AhqDHj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECAQEBIRE6CwULAgEIGAICJgICAh8GCxUQAgQOBYlzAw0IDq18g?= =?us-ascii?q?iaHKg2DHwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQ4IFCIJiglGBXwEjgwY?= =?us-ascii?q?ugjEFiSKMdoYXOwGOF4Q4gXyJA4Y4inKIegEfOIEFWxVBEQGERx2BY3WHUgElg?= =?us-ascii?q?QqBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.36,248,1486425600"; d="scan'208";a="401486309"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2017 20:55:37 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2UKtbi7031256 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2017 20:55:37 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 16:55:36 -0400
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 30 Mar 2017 16:55:36 -0400
From: "Stefano Previdi (sprevidi)" 
To: Mark Smith 
CC: 6man WG 
Subject: Re: draft-voyer-6man-extension-header-insertion
Thread-Topic: draft-voyer-6man-extension-header-insertion
Thread-Index: AQHSqZEvd+Uy42v52UGCywl39635aKGuH6aA
Date: Thu, 30 Mar 2017 20:55:36 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.100.200]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 20:55:45 -0000

DQo+IE9uIE1hciAzMCwgMjAxNywgYXQgMTA6MDYgUE0sIE1hcmsgU21pdGggPG1hcmt6enpzbWl0
aEBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMzAgTWFyY2ggMjAxNyBhdCAwNzo1NSwgU3Rl
ZmFubyBQcmV2aWRpIChzcHJldmlkaSkNCj4gPHNwcmV2aWRpQGNpc2NvLmNvbT4gd3JvdGU6DQo+
PiANCj4+PiBPbiBNYXIgMjgsIDIwMTcsIGF0IDEwOjA3IFBNLCBNYXJrIFNtaXRoIDxtYXJrenp6
c21pdGhAZ21haWwuY29tPiB3cm90ZToNCj4+PiANCj4+PiBUaGV5J3JlIG1pc3NpbmcgdGhlIGRp
ZmZlcmVuY2UgYmV0d2VlbiBlbmNhcHN1bGF0aW9uIGFuZCBpbnNlcnRpb24uDQo+PiANCj4+IA0K
Pj4gbm90IHJlYWxseToNCj4+IA0KPj4gLiBhIHBhY2tldCBpcyByZWNlaXZlZCBhdCBpbmdyZXNz
IG9mIHRoZSBjb250cm9sbGVkIGRvbWFpbg0KPj4gLiB0aGUgcGFja2V0IGlzIGVuY2Fwc3VsYXRl
ZCBpbnRvIGEgbmV3IG91dGVyIGlwdjYgaGVhZGVyIHdoZXJlIFNBL0RBIGFyZSBpbnRlcm5hbCB0
byB0aGUgZG9tYWluLg0KPj4gLiBmcm9tIG5vdyBvbjoNCj4+ICAgIC4gdGhpcyBwYWNrZXQgaXMg
YSBwYWNrZXQgc291cmNlZCBhbmQgZGVzdGluZWQgd2l0aGluIHRoZSBjb250cm9sbGVkIGRvbWFp
bi4NCj4+ICAgIC4gdGhlIG9yaWdpbmFsIHBhY2tldCBpcyBlbmNhcHN1bGF0ZWQgYW5kIHdpbGwg
cmVtYWluIHVudG91Y2hlZC91bm1vZGlmaWVkIChpLmUuLCBub3Rpbmcgd2lsbCBiZSBpbnNlcnRl
ZCBpbnRvIHRoZSBvcmlnaW5hbCBwYWNrZXQpLg0KPiANCj4gU28gdGhhdCBpcyB0aGUgdHJhbnNp
dCBjYXNlLCBhbmQgeWVzLCB0aGF0IHBhY2tldCBpcyBsZWZ0IGFzIHNlbnQgYnkNCj4gaXQncyBv
cmlnaW5hdGluZyBob3N0Lg0KPiANCj4gVGhlIDZQRSBleGFtcGxlIGlzIHRoZSBvbmUgdGhhdCBp
cyBjbGFpbWluZyB0aGF0ICJwYWNrZXQiIGlzIGNoYW5naW5nDQo+IGluIHNpemUsIGFuZCB0aGF0
IGlzIG5vdCBjb3JyZWN0Lg0KDQoNCjZQRSBlbmNhcHN1bGF0ZXMgdGhlIHBhY2tldCBpbnRvIGEg
bGFiZWwgc3RhY2sNCg0KU1J2NiBlbmNhcHN1bGF0ZXMgdGhlIHBhY2tldCBpbnRvIGFuIG91dGVy
IElQdjYgaGVhZGVyIGFuZCBzdWhjIG91dGVyIElQdjYgaGVhZGVyIG1heSBoYXZlIFNSSCBpbnNl
cnRlZCBieSBub2RlcyBpbiB0cmFuc2l0Lg0KDQpCb3R0b20gbGluZSwgdGhlIHNpdHVhdGlvbiBo
ZXJlIHRoZSBwYWNrZXQgaW5jcmVhc2VzIGlzIG5vdCBuZXcgKDZQRSkuDQoNCg0KPiAiV2hpbGUg
dHJhbnNpdGluZyBpbiB0aGUgY29yZSwgdGhlIHNpemUgb2YgdGhlIGxhYmVsIHN0YWNrIChoZW5j
ZQ0KPiAgICAgIHRoZSBzaXplIG9mIHRoZSBwYWNrZXQpIg0KPiANCj4gQW55IHRpbWUgdGhpcyBk
cmFmdCBtZW50aW9ucyAicGFja2V0IiB3aXRob3V0IGNvbnRleHQsIGl0IGlzIGdvaW5nIHRvDQo+
IGJlIHJlYWQgYXMgIklQdjYgcGFja2V0IiBiZWNhdXNlIHRoaXMgZHJhZnQgaXMgYW4gSVB2NiBk
cmFmdCBhbmQgdGhpcw0KPiBpcyBhbiBJUHY2IHdvcmtpbmcgZ3JvdXAuDQoNCg0Kc3RpbGwgdGhl
IGFzc2VydGlvbiBpcyBjb3JyZWN0Lg0KDQoNCj4gV2hpbGUgdGhhdCBtaWdodCBzb3VuZCBsaWtl
IEknbSBiZWluZyBwZWRhbnRpYywgdGhpcyA2UEUgZXhhbXBsZSBzZWVtcw0KPiB0byBiZSBiZWlu
ZyB1c2VkIHRvIHNob3cgdGhhdCA2UEUgYWxyZWFkeSBjaGFuZ2VzIHRoZSBzaXplIG9mIHRoZSBJ
UHY2DQo+IHBhY2tldCwgYW5kIHRoZXJlZm9yZSBjaGFuZ2luZyBJUHY2IHBhY2tldCBzaXplcyBt
aWQtZmxpZ2h0IGlzIG5vcm1hbA0KPiBhbmQgYWNjZXB0YWJsZS4NCg0KDQpuby4gSXQgbWVhbnMg
aXTigJlzIG5vdCBuZXcgYW5kIHRoZXJlZm9yZSBpc3N1ZXMgaGF2ZSBiZWVuIGFscmVhZHkgYWRk
cmVzc2VkIChlLmcuLCBNVFUpLg0KDQoNCj4+IC4gYSBwYWNrZXQgc291cmNlZCBhbmQgZGVzdGlu
ZWQgaW50ZXJuYWxseSBpbiB0aGUgY29udHJvbGxlZCBkb21haW4gY2FuIHNhZmVseSBiZSBpbmNy
ZWFzZWQgaW4gaXRzIHNpemUgYW5kIGNhbiBiZSBzYWZlbHkgaGF2ZSBFSHMgaW5zZXJ0ZWQgYnkg
dHJhbnNpdCBub2Rlcy4NCj4gDQo+IEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGF0IHN0YXRlbWVudC4g
V2hhdCBpZiB0aGUgaW5zZXJ0ZWQgRUggaXNuJ3QNCj4gYWN0dWFsbHkgcmVtb3ZlZCB3aGVuIGl0
IHNob3VsZCBiZT8NCg0KDQphIHBhY2tldCAiZGVzdGluZWQgd2l0aGluIHRoZSBkb21haW4iIGlt
cGxpZXMgdGhhdCBhdCB0aGUgZWRnZSBvZiB0aGUgZG9tYWluIHRoZSBvdXRlciBlbmNhcHN1bGF0
aW9uIGlzIHJlbW92ZWQgKHdpdGggdGhlIHVuZGVybmVhdGggU1JIKS4gT3RoZXJ3aXNlIGl0IGRv
ZXNu4oCZdCBmaXQgdGhlIGRlZmluaXRpb24gb2Yg4oCcZGVzdGluZWQgd2l0aGluIHRoZSBkb21h
aW7igJ0uIA0KDQoNCj4gVGhlIGRvbWFpbiBhbHJlYWR5IHN1cHBvcnRzIElQdjYtaW4tSVB2NiBl
bmNhcHN1bGF0aW9uLCBnb2luZyB0aGUNCj4gdHJhbnNpdCBwYWNrZXQgZXhhbXBsZS4gV2h5IGNv
bXBsaWNhdGUgdGhpbmdzIGJ5IGFsc28gaGF2aW5nIHRoZSBzYW1lDQo+IGRvbWFpbiBzdXBwb3J0
IGluc2VydGlvbiwgd2hlbiBhbHJlYWR5IHN1cHBvcnRlZCBJUHY2LWluLUlQdjYNCj4gZW5jYXBz
dWxhdGlvbiBjYW4gYmUgdXNlZCB0byBhY2hpZXZlIHRoZSBzYW1lIG91dGNvbWU/DQoNCg0Kc291
cmNlIHJvdXRpbmcgYnkgc3RhY2tpbmcgaXB2NiBvdXRlciBoZWFkZXJzID8gSXTigJlzIGEgam9r
ZSwgcmlnaHQgPyBNYXliZSB5b3Ugc2hvdWxkIGxvb2sgYSBiaXQgZGVlcGVyIG9uIHdoYXQgc2Vn
bWVudCByb3V0aW5nIGlzIGFib3V0Og0KCWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu
Zw0KCWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzDQoJUkZDNzg1NQ0KCWRy
YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50cmFsLWVwZQ0KCWRyYWZ0LWlldGYt
Nm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyDQoJZHJhZnQtZmlsZmlscy1zcHJpbmctc3J2Ni1u
ZXR3b3JrLXByb2dyYW1taW5nDQoNCg0KPiBFSCBpbnNlcnRpb24gYW5kIERBIGFkZHJlc3Mgc3dh
cHBpbmcgc2VlbSB0byBiZSB0byBiZSBmYXIgbW9yZQ0KPiBjb21wbGljYXRlZCBhbmQgdGhlcmVm
b3JlIGV4cGVuc2l2ZSBhbmQgZXJyb3IgcHJvbmUgb3BlcmF0aW9ucyB0aGFuDQo+IG5ldHdvcmst
bGF5ZXIgdG8gbGluay1sYXllciAod2hlcmUgSVB2NiBpcyBhbHNvIGJlaW5nIHVzZWQgYXMgYQ0K
PiBsaW5rLWxheWVyKSB0eXBlIGVuY2Fwc3VsYXRpb24vZGVjYXBzdWxhdGlvbi4NCg0KDQpzb3Jy
eSwgSSBkb27igJl0IGZvbGxvdyB5b3UuIFNSIHJlLXVzZXMgdGhlIHNvdXJjZSByb3V0aW5nIHBh
cmFkaWdtIHdoZXJlIHRoZSBzb3VyY2Ugcm91dGVkIChsb29zZSkgcGF0aCBpcyBlbmNvZGVkIGFz
IGEgbGlzdCBvZiBzZWdtZW50cyB3aGljaCBhcmUgdXNlZCB0byBvdmVycmlkZSB0aGUgREEgYXQg
ZWFjaCBzZWdtZW50IGhvcC4gSSBkb27igJl0IGtub3cgd2hhdCwgaW4gdGhpcywgaXMgY29tcGxp
Y2F0ZWQuDQoNCg0KPj4gLiB3aGVuIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgZWdyZXNzIG5vZGUg
b2YgdGhlIGNvbnRyb2xsZWQgZG9tYWluLCB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBhbmQgYW55
IGluc2VydGVkIEVIIGFyZSByZW1vdmVkLiBJT1csIHRoZSBwYWNrZXQgdGhhdCBsZWF2ZXMgdGhl
IGRvbWFpbiBpcyBleGFjdGx5IHRoZSBzYW1lIHBhY2tldCB0aGF0IGVudGVyZWQgdGhlIGRvbWFp
bi4NCj4gDQo+IFlvdXIgc3BlY2lmaWNhdGlvbiB3aWxsIHNheSB0aGF0LCBwcm9iYWJseSBhcyBh
IE1VU1QuIFRoZSB0cm91YmxlIGlzDQo+IHRoYXQgaW1wbGVtZW50YXRpb25zIGRvbid0IGFsd2F5
cyBiZWhhdmUgYXMgc3BlY2lmaWVkLiAiSW4gdGhlb3J5LA0KPiBwcmFjdGljZSBhbmQgdGhlb3J5
IGFyZSB0aGUgc2FtZS4gSW4gcHJhY3RpY2UgdGhleSdyZSBub3Qu4oCdDQoNCg0KcHJhY3RpY2Fs
IGV4cGVyaWVuY2Ugc2hvd2VkIHRoYXQgaW1wbGVtZW50YXRpb24gZXJyb3JzIG1heSBoYXBwZW4g
YXQgZWFjaCBsZXZlbCwgbm8gbWF0dGVyIHdoYXQgeW91IHdyaXRlIGluIHlvdXIgc3BlY3MuIEVu
IGVuY2Fwc3VsYXRlZCBwYWNrZXQgKGkuZS4sIHdpdGhvdXQgYW55IEVIKSBtYXkgYWxzbyDigJxl
c2NhcGXigJ0gaW4gc29tZSBwbGFjZXMgd2hlcmUgd2UgZG9u4oCZdCB3YW50IGl0IHRvIGdvLg0K
DQpPcGVyYXRvcnMgaGF2ZSBsZWFybmVkIG92ZXIgdGhlIHllYXIgaG93IHRvIGNvbmZpbmUgd2l0
aGluIHRoZSBkb21haW4gc3VjaCBpc3N1ZXMuDQoNCg0KPiBJZiBhIGxhdGVyIHJvdXRlciBvciBo
b3N0IHJlY2VpdmVzIGEgcGFja2V0IHdpdGggYW4gRUggdGhhdCBoYXNuJ3QNCj4gYmVlbiByZW1v
dmVkIHdoZW4gaXQgc2hvdWxkIGhhdmUgYmVlbiwgd2hhdCB3aWxsIGhhcHBlbj8gVGhhdA0KPiBi
ZWhhdmlvdXIgaXNuJ3QgY3VycmVudGx5IHNwZWNpZmllZC4NCg0KDQphZ2FpbiBhbmQgYWdhaW46
IHRoZSBvdXRlciBoZWFkZXIgY29udGFpbnMgU0EvREEgaW5zaWRlIHRoZSBkb21haW4gc28gdGhl
IHBhY2tldCBjYW7igJl0IHJlYWNoIGFueSBhZGRyZXNzIG90aGVyIHRoYW4gaW50ZXJuYWwgdG8g
dGhlIGRvbWFpbi4NCg0KDQo+IFdlIGtub3cgdGhhdCBwcm90b2NvbHMgYXNzdW1lIHRoYXQgdGhl
IHJlY2VpdmVkIHBhY2tldCdzIHN0cnVjdHVyZSBhbmQNCj4gbW9zdCBvZiBpdHMgZmllbGQgdmFs
dWVzIChlLmcuLCBleGNsdWRpbmcgSG9wIExpbWl0LCBmbG93IGxhYmVsIGV0Yy4pDQo+IHdlcmUg
c2V0IGJ5IHRoZSBkZXZpY2Ugc3BlY2lmaWVkIGluIHRoZSBzb3VyY2UgYWRkcmVzcyBmaWVsZC4g
SWYgYW4NCj4gaW5zZXJ0ZWQgRUggaXMgbm90IHJlbW92ZWQsIGFuZCB5b3UgY2FuJ3QgZ3VhcmFu
dGVlIHRoYXQsIHRoZW4gZGV2aWNlcw0KPiBhcmUgcmVjZWl2aW5nIHBhY2tldHMgdGhhdCBhcmUg
Y29ycnVwdCBieSB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9ucy4NCg0KDQp0aGF0IGRldmljZSBp
cyBpbnRlcm5hbCB0byB0aGUgZG9tYWluIHNvIHRoZSBlZmZlY3RzIGFyZSBhbnl3YXkgbWl0aWdh
dGVkLg0KDQoNCj4gSSB0aGluayB0aGlzIGlzIGEgY2hhbmdlIHRoYXQgaXMgdmlvbGF0aW5nIFBv
c3RlbCdzIFJvYnVzdG5lc3MgcHJpbmNpcGxlLg0KDQoNCnRoYXTigJlzIG5vdCB0cnVlLg0KDQpB
bnl3YXksIGhpc3RvcnkgaXMgZnVsbCBvZiBwcmluY2lwbGUgdmlvbGF0aW9ucy4uLg0KDQoNCj4g
SSB0aGluayBvbmUgbWVhbmluZyBvZiAiQmUgY29uc2VydmF0aXZlIHdpdGggd2hhdCB5b3Ugc2Vu
ZCwiIGlzIGRvbid0DQo+IHNlbmQgc29tZXRoaW5nIHRoYXQgbWlnaHQgYnJlYWsgc29tZWJvZHkg
ZWxzZSdzIGRldmljZXMuWW91IG1pZ2h0DQo+IGFyZ3VlIHlvdSBhcmVuJ3QsIGJlY2F1c2UgeW91
ciBzcGVjaWZpY2F0aW9uIHdpbGwgc2F5IHRoZSBpbnNlcnRlZCBFSA0KPiBNVVNUIGJlIHJlbW92
ZWQuIEhvd2V2ZXIsIHlvdSBjYW4ndCBndWFyYW50ZWUgdGhhdCwgYW5kIHRoYXQgaXMgd2h5DQo+
IEpvbiBzYWlkLCBwYXJhcGhyYXNpbmcsICJkb24ndCBzZW5kIHRoZW0gaW4gdGhlIGZpcnN0IHBs
YWNlLyINCj4gDQo+IA0KPiANCj4+IC4gdGhlIHNpemUgb2YgdGhlIHBhY2tldCBpbmNyZWFzZWQg
aW5zaWRlIHRoZSBkb21haW4gZHVlIHRvIGVuY2Fwc3VsYXRpb24gb2YgY291cnNlIGJ1dCBhbHNv
IGR1ZSB0byBFSCBpbnNlcnRpb24gd2hpbGUgaW4gdHJhbnNpdCBpbiB0aGUgZG9tYWluLiBUaGUg
TVRVIHByb2JsZW0gZG9lc27igJl0IGV4aXN0IGluIHJlYWxpdHkgYmVjYXVzZSB0aGUgTVRVIG9m
IGludGVyZmFjZXMgaW4gdGhlIGNvbnRyb2xsZWQgZG9tYWluIGlzIHJvdWdobHkgNCB0aW1lcyB3
aGF0IGlzIGF0IHRoZSBpbmdyZXNzLg0KPj4gLiB0aGUgcG9pbnQgb2YgdGhlIGRyYWZ0IGlzIHRv
IHNheSB0aGF0IGlmIHRoZSBwYWNrZXQgaXMgc291cmNlZCBhbmQgZGVzdGluZWQgd2l0aGluIGEg
Y29udHJvbGxlZCBkb21haW4sIGl0IGlzIHNhZmUgdG8gYWxsb3cgaW5zZXJ0aW9uIG9mIEVIcyBi
eSB0cmFuc2l0IG5vZGVzLg0KPj4gDQo+PiBvbmNlIGFnYWluOiB0aGUgRUggaW5zZXJ0aW9uIGhh
cHBlbnMgaW50byB0aGUgb3V0ZXIgaGVhZGVyLCBub3QgaW50byB0aGUgb3JpZ2luYWwgcGFja2V0
Lg0KPj4gDQo+IA0KPiBUaGUgb3V0ZXIgSVB2NiBwYWNrZXQgaXMgYWxzbyBhbiBJUHY2IHBhY2tl
dCAtIHRoZSBpbm5lciBJUHY2IGlzDQo+IHJlYWxseSBqdXN0IGFwcGxpY2F0aW9uIHBheWxvYWQg
KHR1bm5lbGxpbmcgaXMgcmVhbGx5IGp1c3QgYQ0KPiBob3N0LXRvLWhvc3QgYXBwbGljYXRpb24p
LiBTbyBpbnNlcnRpbmcgYW4gRUggaW50byB0aGUgb3V0ZXIgSVB2Ng0KPiBwYWNrZXQgaXMgYWxz
byB2aW9sYXRpbmcgdGhlIElQdjYgc3BlY2lmaWNhdGlvbnMuDQoNCg0Kc3VyZS4gdGhlIGRyYWZ0
IHByb3Bvc2VzIGEgY29udGV4dC91c2UtY2FzZSB3aGVyZSB0aGlzIGlzIHNhZmVseSBkb25lOiBp
bnRlcm5hbCB0byBhIGNvbnRyb2xsZWQgZG9tYWluLg0KDQoNCj4+PiBUaGUgaW5jcmVhc2UgYW5k
IGRlY3JlYXNlIGluICJwYWNrZXQiIHNpemUgdGhhdCBpcyBvY2N1cnJpbmcgaW4gdGhlaXINCj4+
PiA2UEUgZXhhbXBsZSBpcyBhcyB0aGUgUERVIGNyb3NzZXMgbGF5ZXIgYm91bmRhcmllcyBkdWUg
dG8NCj4+PiBlbmNhcHN1bGF0aW9uIG9yIGRlY2Fwc3VsYXRpb24uIFRoaXMgaXMgb2NjdXJyaW5n
IGFzIHRoZSBQRFUgdHJhdmVscw0KPj4+IHZlcnRpY2FsbHkgYmV0d2VlbiBsYXllcnMuIEZyb20g
dGhlIElQdjYgcGVyc3BlY3RpdmUsIHRoZSA2UEUgbGF5ZXIgaXMNCj4+PiBhIGxpbmsgbGF5ZXIg
YmVsb3cgdGhlIG5ldHdvcmsgbGF5ZXIuDQo+PiANCj4+IA0KPj4gdGhlIGV4YW1wbGUgb2YgNnBl
IG91dGxpbmVzIHRoZSBmYWN0IHRoYXQgdGhlIHBhY2tldCwgd2hpbGUgdHJhbnNpdGluZyB3aXRo
aW4gYSBkb21haW4sIGNhbiAgaW5jcmVhc2UgaW4gaXRzIHNpemUgZHVlIHRvIGxhYmVsIHN0YWNr
IGJlaW5nIHB1c2hlZC4NCj4+IA0KPj4gDQo+Pj4gV2hpbGUgdGhlIElQdjYgcGFja2V0IHRyYXZl
cnNlcyB0aGUgNlBFIGRvbWFpbiwgdGhlIElQdjYncyBwYWNrZXQgc2l6ZQ0KPj4+IGFuZCBzdHJ1
Y3R1cmUgaXMgbm90IGNoYW5nZWQgaW4gYW55IHdheS4NCj4+IA0KPj4gDQo+PiB0aGUgc2FtZSBp
cyBpbiBvdXIgYXBwcm9hY2g6DQo+PiANCj4+IC4gdGhlIG9yaWdpbmFsIHBhY2tldCBpcyBlbmNh
cHN1bGF0ZWQgaW50byBhbiBvdXRlciBoZWFkZXIgYW5kIGl0cyBzaXplIHdpbGwgbm90IGNoYW5n
ZS4NCj4+IC4gdGhlIGVuY2Fwc3VsYXRpbmcgcGFja2V0IHdpbGwgZ2V0IEVIIGluc2VydGVkLg0K
Pj4gDQo+PiANCj4+PiBFSCBpbnNlcnRpb24gaXMgaW5jcmVhc2luZyB0aGUgUERVIHNpemUgYW5k
IGNoYW5naW5nIHRoZSBwYWNrZXQNCj4+PiBzdHJ1Y3R1cmUgd2hpbGUgdGhlIHBhY2tldCB0cmF2
ZWxzIGhvcml6b250YWxseSB3aXRoaW4gdGhlIElQdjYgbGF5ZXIuDQo+Pj4gVGhhdCB3aWxsIGJy
ZWFrIHRoaW5ncyBpZiB0aGUgZGVzdGluYXRpb24gaG9zdCBkb2Vzbid0IGV4cGVjdCB0aGUNCj4+
PiBwYWNrZXQgc2l6ZSBvciBzdHJ1Y3R1cmUgdG8gY2hhbmdlLCBhbmQgdGhleSBkb24ndCwgYmVj
YXVzZSBpdCBpcyBub3QNCj4+PiBhIGRlc2NyaWJlZCAid2l0aGluIGxheWVyIiBwYWNrZXQgcHJv
Y2Vzc2luZyBiZWhhdmlvdXIgaW4gUkZDMjQ2MC4gVGhlDQo+Pj4gZGVzdGluYXRpb24gaG9zdCBl
eHBlY3RzIHRoYXQgdGhlIHBhY2tldCByZWNlaXZlZCBoYXMgYSBzdHJ1Y3R1cmUgYW5kDQo+Pj4g
c2l6ZSB0aGF0IGlzIHRoZSBzYW1lIGFzIHNlbnQgYnkgdGhlIGRldmljZSBpZGVudGlmaWVkIGlu
IHRoZSBzb3VyY2UNCj4+PiBhZGRyZXNzIGZpZWxkLCB3aGljaCBpcyB0aGUgaG9zdCB0aGF0IG9y
aWdpbmF0ZWQgdGhlIHBhY2tldC4NCj4+PiANCj4+PiBFSCBpbnNlcnRpb24gbWFrZXMgdGhlIHNv
dXJjZSBhZGRyZXNzIGZpZWxkIGJvdGggbWVhbmluZ2xlc3MgYW5kDQo+Pj4gaG9sZGluZyBhbiBp
bmNvcnJlY3QgdmFsdWUgd2hpbGUgdGhlIGluc2VydGVkIEVIIGlzIHByZXNlbnQuDQo+PiANCj4+
IA0KPj4gbm90IHJlYWxseToNCj4+IC4gdGhlIFNBIGlzIHVudG91Y2hlZCBieSB0aGUgRUggaW5z
ZXJ0aW9uLiBUaGUgU0EgaXMgdGhlIGFkZHJlc3Mgb2YgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUg
Y29udHJvbGxlZCBkb21haW4uDQo+PiAuIHRoZSBEQSBpcyB1cGRhdGVkIHdpdGggdGhlIGZpcnN0
IHNlZ21lbnQgb2YgdGhlIEVIICh3ZSBhc3N1bWUgdGhlIGluc2VydGVkIEVIIGlzIHRoZSBTUkgp
Lg0KPj4gLiB0aGUgREEgaXMgdXBkYXRlZCBhdCBlYWNoIHNlZ21lbnQNCj4+IA0KPj4gDQo+Pj4g
QQ0KPj4+IHNwZWNpZmljYXRpb24gZm9yIEVIIGluc2VydGlvbiB3b3VsZCBuZWVkIHRvIHN0YXRl
IHRoaXMgdmVyeSBjbGVhcmx5Lg0KPj4+IE1hbnkgb2YgdGhlIG5lZ2F0aXZlIGNvbnNlcXVlbmNl
cyBvZiBFSCBpbnNlcnRpb24gYXJlIGJlY2F1c2UgaXQgbWFrZXMNCj4+PiB0aGUgcGFja2V0J3Mg
c291cmNlIGFkZHJlc3MgZmllbGQgbWVhbmluZ2xlc3MgYW5kIGhvbGRpbmcgYSBpbmNvcnJlY3QN
Cj4+PiB2YWx1ZS4NCj4+IA0KPj4gDQo+PiBhZ2Fpbiwgbm90IHJlYWxseSBpbiB0aGlzIGNhc2U6
IHRoZSBTQSBpcyB1bnRvdWNoZWQgYW5kIGl0IHJlcHJlc2VudHMgdGhlIGluZ3Jlc3Mgbm9kZSBv
ZiB0aGUgY29udHJvbGxlZCBkb21haW4uDQo+PiANCj4+IA0KPj4+IFRoZSBvbmx5IHRoaW5ncyB0
aGF0IGFyZSBwZXJtaXR0ZWQgdG8gY2hhbmdlIHdoaWxlIGFuIElQdjYgcGFja2V0IGlzDQo+Pj4g
aW4gZmxpZ2h0ICh3aXRoaW4gdGhlIElQdjYgbGF5ZXIpIGFyZSB2YWx1ZXMgb2YgYSBkZWZpbmVk
IHNldCBvZg0KPj4+IGZpZWxkcyBzcGVjaWZpZWQgaW4gUkZDMjQ2MCBlLmcuLCBob3AgbGltaXQs
IGZsb3cgbGFiZWwsIHRyYWZmaWMNCj4+PiBjbGFzcy4gT25seSBmaWVsZCB2YWx1ZXMgY2hhbmdl
LCBubyBmaWVsZHMgYXJlIGFkZGVkIG9yIHJlbW92ZWQgLSB0aGUNCj4+PiBwYWNrZXQncyBzdHJ1
Y3R1cmUgYW5kIHNpemUgc3RheXMgdGhlIHNhbWUgYWZ0ZXIgdGhlc2UgbW9kaWZpY2F0aW9ucw0K
Pj4+IGlmIG9yIHdoZW4gdGhleSBvY2N1ci4NCj4+IA0KPj4gDQo+PiBJIHVuZGVyc3RhbmQgd2hh
dCByZmMyNDYwIHNwZWNpZmllZCBhbmQgdGhlIHJlYXNvbiBvZiBvdXIgZHJhZnQgaXMgdG8gZXhw
bGFpbiB0aGF0IHRoaW5ncyBoYXZlIGNoYW5nZWQgaW4gdGhlIGxhc3QgMjAgeWVhcnMgYW5kIHdl
IHNob3VsZCB0YWtlIHRoZW0gaW50byBjb25zaWRlcmF0aW9uLg0KPj4gDQo+IA0KPiBUaGF0J3Mg
dGhlIHRoaW5nIHRoYXQgaXMgbWlzc2luZy4gVGhlcmUgaXMgYW4gYXNzZXJ0aW9uIHRoYXQgaW5z
ZXJ0aW5nDQo+IEVIcyBpcyByZXF1aXJlZCAoYSBtdWNoIHN0cm9uZ2VyIHdvcmQgdGhhbiAicHJl
ZmVycmVkIiksIHlldCBubw0KPiBleHBsYW5hdGlvbiBvZiB3aHkgaXQgaXMgcmVxdWlyZWQgb3Ig
ZXNzZW50aWFsLg0KDQoNCkkgd2lsbCBlbGFib3JhdGUgYSBtb3JlIG9uIHRoaXMgaW4gdGhlIG5l
eHQgcmV2aXNpb24uDQoNCg0KPiBUaGUgdXNlIG9mIHRoZSB3b3JkICJyZXF1aXJlZCIgaW1wbGll
cyB0aGF0IHRoZSBpbnNlcnRpbmcgRUggaXMNCj4gZXNzZW50aWFsIGZvciB0aGlzIHRvIHdvcmsu
DQoNCg0KeWVzLiBJdCBpcyByZXF1aXJlZCB0byB0YWtlIHRoZSBiZXN0IGJlbmVmaXQgb3V0IG9m
IHNvdXJjZSByb3V0aW5nIGluIGlwdjYuDQoNCg0KPiBJIGRvbid0IHRoaW5rIGl0IGlzLCBlbmNh
cHN1bGF0aW9uIGNvdWxkDQo+IGFjaGlldmUgdGhlIHNhbWUgb3V0Y29tZSwNCg0KDQppdCBjYW7i
gJl0Lg0KDQoNCj4gYW5kIGl0IGlzIGFuIGV4aXN0aW5nLCB3ZWxsIGtub3duIG1ldGhvZA0KPiB0
aGF0IHdvbid0IGludGVyYWN0IHVuZXhwZWN0ZWRseSB3aXRoIGV4aXN0aW5nIElQdjYgaW1wbGVt
ZW50YXRpb25zLg0KDQoNCmVuY2Fwc3VsYXRpb24gaXMgYSB2ZXJ5IGxpbWl0ZWQgdG9vbCB0aGF0
IHdpbGwgZG8gdmVyeSBsaW1pdGVkIHRoaW5ncyB0aGF0IG1heSBoYXZlIHdvcmtlZCBpbiB0aGUg
cGFzdCAyMCB5ZWFycyBidXQgdG9kYXkgbW9kZXJuIG5ldHdvcmtpbmcgcmVxdWlyZW1lbnRzIHJh
aXNlZCB0aGUgYmFyLi4uIGEgYml0IG1vcmUuDQoNCnMuDQoNCg0KPiANCj4gUmVnYXJkcywNCj4g
TWFyay4NCj4gDQo+PiBzLg0KPj4gDQo+PiANCj4gDQo+IFJlZ2FyZHMsDQo+IE1hcmsuDQo+IA0K
Pj4+IA0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+Pj4gTWFyay4NCj4+PiANCj4+PiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4+IGlwdjZAaWV0
Zi5vcmcNCj4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9pcHY2DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IA0KDQo=


From nobody Thu Mar 30 14:05:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562901294D2; Thu, 30 Mar 2017 14:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 4BtAXcfibokg; Thu, 30 Mar 2017 14:05:33 -0700 (PDT)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id BC3B51294B5; Thu, 30 Mar 2017 14:05:33 -0700 (PDT)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 30 Mar 2017 21:05:33 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 63B0AD788B; Thu, 30 Mar 2017 14:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=20/sY23ATwWs938r1mKHHsMmqIM=; b= so4QzReKNniG2WGVUIeLaR22wgKvI4xcVpB5YJDJkMTv1sRuq/EbF8vVZ71jmk0q +sSJ/lzyANkEcu+Dlubbq1pma0YQFU5cy/ivX9tVFbJpyDGQQgdw7g9s7nckXrKl A65jjTV9qF0KNadIaxuDMErr77080ZjRK+wuz8aPq04=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=TKFt1sXYHRZO6eUCkxICs/k uGT/Ec7vOp+RJg1X9hhYMqyTsVroBHSk7UyNA2T9q/4awkVLY4NWU+kEgmnu+Ksv Zdn4u8eN1TaYbLg3vzbBdEvqX43LYfxSsifDdiljM5p4U60Ed+y0f43xeRpoTOym 3H7y41mkALFh4EKk35RM=
Received: from h.hanazo.no (dhcp-8e77.meeting.ietf.org [31.133.142.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 52FF0D788E; Thu, 30 Mar 2017 14:05:33 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 4C92BA6BF80F; Thu, 30 Mar 2017 16:05:34 -0500 (CDT)
From: otroan@employees.org
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_73849059-1387-463D-9569-A8415D49DB84"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Date: Thu, 30 Mar 2017 16:05:33 -0500
In-Reply-To: 
Cc: Suresh Krishnan , "Leddy, John" , IETF Discussion , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
To: Robert Raszuk 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 21:05:36 -0000

--Apple-Mail=_73849059-1387-463D-9569-A8415D49DB84
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Robert,

> Correct me if I am missing someting but the entire debate is not about =
describing or not header insertion.
>=20
> I am under assumption that originating hosts still can legally insert =
it.
>=20
> It is all about to modify EH in flight - right ? Moreover concerns =
raised are about side effects of it like MTU .. not lack of instructions =
on how to insert, modify or remove EH elements.
>=20
> So what exactly are you expecting WG to deliver as next step if =
2460bis goes fwd ? Is detecting the max MTU on end to end path even in =
6man's charter ?

You can write a new protocol specification independently of 2460bis that =
does whatever it has to do, and then we can argue over that document on =
its own merits.

Cheers,
Ole

--Apple-Mail=_73849059-1387-463D-9569-A8415D49DB84
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJY3XMeAAoJEL7aWKiYQt92P88QAMN8er2L40pnH7J5XocUDKH0
acB5cTMAYgtF66CnxOKSQTwpSP7/gH21tiroVx/27FySV97yYk5o8usf5joECqin
iSDnyigr6/NMV31B/xC/Berp7Mqp0h95xGOEhdMaLgnDfb1L8L7sKiwJuroRvr/G
GAuk4/l5qOg2ONcyxcCdsJldEDYbUO3aKKwGqEYo5Wi+xpDCd/pjFP1SaXTIM/ki
Qbf3PkiDCiAZbDjQDYhc8aTVQHU7/KzcUQEquXPEF8mrr1fcl/1oWw+SqL+ALR2y
/tYzMWIomuLqiOP1HDNdLT5hl+zrbflOnSxAUP3Nwsjdz54kdSKCvjO8niu41eHm
cxLVrkYcQgg3opd7n0hEydRCbq4vLgO7nNL2ZEDJv7Dev1pliqgf9BzQ2k87M09S
M0Iru6kvEGtloYUSJLoFWsAjrG5hcGIUoawo2j+ykjeASXCiec6az35rGUp/wex/
W2G7vHhH58bgIAKLLhVJ0SxT5S3aDHdf6VEdwFgbSsULn7bbgXvSlXpMrTUwJW9u
pc+zY2jpP/vOT7M0usDfQ4kTNjK1WFDZVNzEX2B5NkvQfRZv4szLsLW+qoDOinvQ
lQkMre/wOmtAUsvR/+tKO2zgQrmn8r2R4vtF4vTNpe4JHXh6gBKNb0rm+xu6xKKJ
XRwEV5ZpLY97mS4zWRP+
=UlCU
-----END PGP SIGNATURE-----

--Apple-Mail=_73849059-1387-463D-9569-A8415D49DB84--


From nobody Thu Mar 30 14:13:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4F129483; Thu, 30 Mar 2017 14:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 niRhNV8m2Vv6; Thu, 30 Mar 2017 14:13:09 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4081294FF; Thu, 30 Mar 2017 14:13:05 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id y18so3793814itc.1; Thu, 30 Mar 2017 14:13:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9qHEfACCnq5wDrqZG/5dXKPkaffAc4qLLnCUgsQxEU4=; b=pkyKnu1v0obvciCDC2WXQhiztpwaexkSaSfOdulK39PJaGjnJEf/0FKYvPg3Edpv0+ UmoOE9OA3hXK6Qsf0dAX7u+zKldytmo6M6/0a9YJ8682cGHFA2t3Jpy6hZOUdjiaHUZU KrSHjb3iJJs/dYTbko9JJ5GO207/fJ0yWbg27y8arnvAU58UvMKbwhouIt3GmM+W9Ln7 H1uOsJSOydR1N9ADBN0MqiEdjfe/idI6H7GGuQZxMQszCS9aRET2ebHZiIt8ub4hsIle gyOSsHSI34XLCD2VdUoHNmD1jgKB2FJh5YeYQhvZkU/pHqdfXklrnXiohippupf+ev1r 3slw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9qHEfACCnq5wDrqZG/5dXKPkaffAc4qLLnCUgsQxEU4=; b=pXLK4WJlxlODDtBDLUEM1Nbx3ftCOhQfGt/EuIb2oK04j6PeUtMVB/ZuUewUv+J0jZ lUA4c7kukHTJVncsDUHh+j7iUtnbKmWIVBXjP7R40K3Zp13kxIBWuORzHg7QkzT8Uv2f 19KawoPBlLeHoGDmI6KsV4jyKXdhXocxWa4wuy9NskuEKlutFFdnc7xdQ3hGDUpx4qsi 1xtC2SYq3mwC2D0TtfkfTC7ejEMCwO1iId+dxrAf4tTQUx1bIDOA7mVs7vlGBqVV3NIt ZiUeBMy+Rmcdev1V/ZbsKulnQ/XlArfqvBBQ3g9xoCvGqkwEeVDym9wTjqznSOmE/4Xj MqaA==
X-Gm-Message-State: AFeK/H3Hdmhlh67eA17RL+jR7PsMu1/3j5dX5a/NDiiaCAp58dbMlboRR88gw96rDDdZ2Xh4ZSs3YXY1Z1KbAg==
X-Received: by 10.36.43.78 with SMTP id h75mr308573ita.25.1490908384722; Thu, 30 Mar 2017 14:13:04 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 14:13:03 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Thu, 30 Mar 2017 14:13:03 -0700 (PDT)
In-Reply-To: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>  
From: Robert Raszuk 
Date: Thu, 30 Mar 2017 16:13:03 -0500
X-Google-Sender-Auth: AOK4OYC5rm0V-o8rlpvQ1A0Et8M
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: otroan@employees.org
Cc: Suresh Krishnan , "Leddy, John" ,  IETF Discussion , 6man WG ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1146f426aa0381054bf92898
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 21:13:11 -0000

--001a1146f426aa0381054bf92898
Content-Type: text/plain; charset=UTF-8

What's wrong or what is missing in
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-05

?

On Mar 30, 2017 16:05,  wrote:

> Robert,
>
> > Correct me if I am missing someting but the entire debate is not about
> describing or not header insertion.
> >
> > I am under assumption that originating hosts still can legally insert it.
> >
> > It is all about to modify EH in flight - right ? Moreover concerns
> raised are about side effects of it like MTU .. not lack of instructions on
> how to insert, modify or remove EH elements.
> >
> > So what exactly are you expecting WG to deliver as next step if 2460bis
> goes fwd ? Is detecting the max MTU on end to end path even in 6man's
> charter ?
>
> You can write a new protocol specification independently of 2460bis that
> does whatever it has to do, and then we can argue over that document on its
> own merits.
>
> Cheers,
> Ole
>

--001a1146f426aa0381054bf92898
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



    On Mar 30, 2017 16:05,  <otroan@employees.org> wrote:
    Robert,
    

    
> Correct me if I am missing someting but the entire debate is not about=
 describing or not header insertion.
    
>
    
> I am under assumption that originating hosts still can legally insert =
it.
    
>
    
> It is all about to modify EH in flight - right ? Moreover concerns rai=
sed are about side effects of it like MTU .. not lack of instructions on ho=
w to insert, modify or remove EH elements.
    
>
    
> So what exactly are you expecting WG to deliver as next step if 2460bi=
s goes fwd ? Is detecting the max MTU on end to end path even in 6man's=
 charter ?
    

    
You can write a new protocol specification independently of 2460bis that do=
es whatever it has to do, and then we can argue over that document on its o=
wn merits.
    

    
Cheers,
    
Ole
    

    

--001a1146f426aa0381054bf92898--


From nobody Thu Mar 30 14:50:26 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C7512960F; Thu, 30 Mar 2017 14:50:24 -0700 (PDT)
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 autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 URTPAMwqAydp; Thu, 30 Mar 2017 14:50:22 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B16129548; Thu, 30 Mar 2017 14:50:22 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id 68so4279466ioh.3; Thu, 30 Mar 2017 14:50:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7CUCyhvMUQ4PAI3Cn4+2B3y0kH2rADicqfAqtWpYvGs=; b=ii37flu6MV9XGHe1b9kMACSAwcS5xnsR6ethpw6qJfcWORqBL9ZC7amDLfTO4DPYh8 fTU6hu3MolNqO4mTOGDpSZG+HZtJxn8S5HTA5Yp11PBgfdxObjC6yrbp4X4/610httJ2 FK3sIL/DFKhynGcPKEBVtXFiSsVaDuHMIliFOnXSvNEm/Coqjeog7nwm4KXj8YW59feh R6AJoJiV0KEUWTVx7XeRRBElPMYjKNa6FsjBtyamG9r9v9U6pCH0ijprk+1ojvALZtoc dgXYiNk7nLXvmfOzNwfYfaOeE/n9Wlz0VUeF0ZnTJiuhw9Rwyl27nxs+Fr/jRbL6arOO hAGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=7CUCyhvMUQ4PAI3Cn4+2B3y0kH2rADicqfAqtWpYvGs=; b=OY5ajjow2bb4DBbYy1rbR9lesrZRDkR/UYMBeKRNMn6+cijZCl5yVP96uyZ6toSFTx UWr7tIPPbkvXVjO6NsC8ZkytVkCdlCq+qpzQhdarvnVxzAbjobT6YrTviPw5IuafKTER f5lEaC8fWVfCyW2VtFii+WBebRCbVxQ6etgcEklv0tmlVg+1uogNR7REPxiGPrdHOiYd vGeZv16LEQl934L0KdwV04rsInFWJEeL5b0azfT1UhepVQwFpyHx1rsGbe8TyvmqdArJ wrEG6tbrwlcn/PbES3MHuyTJBUqpJS9i6EqkP/TIgMScmYVMp5p1vhh65fjRieWC0aYF ndPw==
X-Gm-Message-State: AFeK/H0sv7bmZfh2eMcKXPAKstqhrF1x4qtxG/IgitDhNm8nwoBwJp48wspRrPizBjpN+g==
X-Received: by 10.107.46.24 with SMTP id i24mr3577782ioo.84.1490910621700; Thu, 30 Mar 2017 14:50:21 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c91sm2091019iod.18.2017.03.30.14.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 14:50:21 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Robert Raszuk , otroan@employees.org
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>   
Cc: "Leddy, John" , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" , IETF Discussion 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>
Date: Fri, 31 Mar 2017 10:50:29 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 21:50:24 -0000

On 31/03/2017 10:13, Robert Raszuk wrote:
> What's wrong or what is missing in
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-05
> 
> ?

Once we get 2460bis out of the door, we should seriously tackle that question.
Honestly it's going to be easier then. I perhaps disagree with Ole whether we
need an Updates: 2460bis but that depends on the details.

    Brian

> 
> On Mar 30, 2017 16:05,  wrote:
> 
>> Robert,
>>
>>> Correct me if I am missing someting but the entire debate is not about
>> describing or not header insertion.
>>>
>>> I am under assumption that originating hosts still can legally insert it.
>>>
>>> It is all about to modify EH in flight - right ? Moreover concerns
>> raised are about side effects of it like MTU .. not lack of instructions on
>> how to insert, modify or remove EH elements.
>>>
>>> So what exactly are you expecting WG to deliver as next step if 2460bis
>> goes fwd ? Is detecting the max MTU on end to end path even in 6man's
>> charter ?
>>
>> You can write a new protocol specification independently of 2460bis that
>> does whatever it has to do, and then we can argue over that document on its
>> own merits.
>>
>> Cheers,
>> Ole
>>
> 


From nobody Thu Mar 30 14:59:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A48129567 for ; Thu, 30 Mar 2017 14:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 5IFzsOaRZu01 for ; Thu, 30 Mar 2017 14:59:26 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80A7128CB9 for ; Thu, 30 Mar 2017 14:59:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490911164; bh=2zqT1BEFXVLlP+FR3MG/S9d1oxjI/0Pm3trq6WYZ+q0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BeGnVdMRigdSd5CC/pSqzmN58p27u3oERCz/zE64qGfREA1UXxQbOfhJ7Q2j1RLUiSjXchuWteNGIYiJJiBRy1t65b9ARFnZy6WpzE6XfMhXwR9AbGwRAmIjrLgSnCYBWUgjybyUpHo+AVoT1qRWiFKZwdkU+/28fRJG+MJfGMc=
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0177.outbound.protection.outlook.com [213.199.180.177]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-97-m-SicZteMcqoQXph4Ge7Zw-1; Thu, 30 Mar 2017 22:59:19 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Thu, 30 Mar 2017 21:59:18 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.009; Thu, 30 Mar 2017 21:59:18 +0000
From: Tim Chown 
To: Brian E Carpenter 
CC: Robert Raszuk , =?utf-8?B?T2xlIFRyw7hhbg==?= , "Leddy, John" , 6man WG , IETF Discussion , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGssVmAgAC6+QCAAAergIAAIVqAgAAFggCAAASRAIAAEj+AgABB54CAAAHpgIAAAteAgAACGICAAAp2gIAAAnWA
Date: Thu, 30 Mar 2017 21:59:18 +0000
Message-ID: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>
In-Reply-To: <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [31.133.149.62]
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:n6Vj6a+otlRpgM+wKyryPNDwgOR7R8RKco0s2OoPv0XtUbm0ly6g+U4wBlG1m9lgGJm0CaRokyFMiOkhae3kT8TMcIbIgKFikgEHxVWSiEjwY/nMsKUXZQvtGLv8zKpD1zAEinKPbmhRTHglY6HBUY46ADw0PZD+j4fnNsudMWZxW4LmRxDca3q/ciH3P8yBggdM7GOhYA3ZPO7dbBgPVzgy4xlwtF0QO8vGoVUVmikH0UG9e0RuAXk9Iqq3caMqwRBoOTZHfAlgoKQGylE5zKWRrIbQKKqlIIGsyqoZx5MwJgudP1SNVXG6S/2HqDaV1RN5tDIL0sR4G3ctPu46Vg==; 20:9yCO++Gi85BLIyFzNYoFtpcslabzo5ZNQGgQVaPXH2GXrYqyNA6BTXqHw7ZFfuOvgT3GmpTGZbrxtQZHVaipLlYezzUjUZKDiHCeHlnR//zDDvFSiBlpVYQmKIhdoDNNdCzZWh3pLc3R7GisIaSeDvo0jgR3NWCxYvZHu7W/Tmw=
x-ms-office365-filtering-correlation-id: 6b4551e3-71eb-4050-9ff1-08d477b80387
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1138; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006075)(93001075)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; 
x-forefront-prvs: 02622CEF0A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39850400002)(39400400002)(39840400002)(24454002)(54906002)(7736002)(57306001)(81166006)(83716003)(189998001)(42882006)(99286003)(6916009)(2950100002)(8936002)(110136004)(38730400002)(305945005)(3660700001)(4326008)(25786009)(2906002)(36756003)(6436002)(53546009)(6306002)(66066001)(2900100001)(82746002)(74482002)(3280700002)(229853002)(33656002)(39060400002)(6116002)(3846002)(6512007)(50226002)(5660300001)(102836003)(6486002)(86362001)(8676002)(6246003)(53936002)(230783001)(5250100002)(76176999)(93886004)(6506006)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: 
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 21:59:18.2052 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138
X-MC-Unique: m-SicZteMcqoQXph4Ge7Zw-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 21:59:29 -0000

PiBPbiAzMCBNYXIgMjAxNywgYXQgMjI6NTAsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh
cnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMzEvMDMvMjAxNyAxMDoxMywgUm9i
ZXJ0IFJhc3p1ayB3cm90ZToNCj4+IFdoYXQncyB3cm9uZyBvciB3aGF0IGlzIG1pc3NpbmcgaW4N
Cj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1y
b3V0aW5nLWhlYWRlci0wNQ0KPj4gDQo+PiA/DQo+IA0KPiBPbmNlIHdlIGdldCAyNDYwYmlzIG91
dCBvZiB0aGUgZG9vciwgd2Ugc2hvdWxkIHNlcmlvdXNseSB0YWNrbGUgdGhhdCBxdWVzdGlvbi4N
Cj4gSG9uZXN0bHkgaXQncyBnb2luZyB0byBiZSBlYXNpZXIgdGhlbi4gSSBwZXJoYXBzIGRpc2Fn
cmVlIHdpdGggT2xlIHdoZXRoZXIgd2UNCj4gbmVlZCBhbiBVcGRhdGVzOiAyNDYwYmlzIGJ1dCB0
aGF0IGRlcGVuZHMgb24gdGhlIGRldGFpbHMuDQoNCkFncmVlZCAob24gYm90aCBwb2ludHMpLiBB
bmQgSSB0aGluayB5b3XigJlsbCBmaW5kIG1hbnkgd2hvIHdhbnQgMjQ2MGJpcyB0byBzaGlwIGFz
IHByb3Bvc2VkIGJ5IG91ciBBRCB3aWxsIGFsc28gYmUgdmVyeSB3aWxsaW5nIHRvIGhlbHAgd29y
ayB0aHJvdWdoIHRoZSBpc3N1ZXMuIA0KDQpUaW0NCg0KPiAgICBCcmlhbg0KPiANCj4+IA0KPj4g
T24gTWFyIDMwLCAyMDE3IDE2OjA1LCA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+IHdyb3RlOg0KPj4g
DQo+Pj4gUm9iZXJ0LA0KPj4+IA0KPj4+PiBDb3JyZWN0IG1lIGlmIEkgYW0gbWlzc2luZyBzb21l
dGluZyBidXQgdGhlIGVudGlyZSBkZWJhdGUgaXMgbm90IGFib3V0DQo+Pj4gZGVzY3JpYmluZyBv
ciBub3QgaGVhZGVyIGluc2VydGlvbi4NCj4+Pj4gDQo+Pj4+IEkgYW0gdW5kZXIgYXNzdW1wdGlv
biB0aGF0IG9yaWdpbmF0aW5nIGhvc3RzIHN0aWxsIGNhbiBsZWdhbGx5IGluc2VydCBpdC4NCj4+
Pj4gDQo+Pj4+IEl0IGlzIGFsbCBhYm91dCB0byBtb2RpZnkgRUggaW4gZmxpZ2h0IC0gcmlnaHQg
PyBNb3Jlb3ZlciBjb25jZXJucw0KPj4+IHJhaXNlZCBhcmUgYWJvdXQgc2lkZSBlZmZlY3RzIG9m
IGl0IGxpa2UgTVRVIC4uIG5vdCBsYWNrIG9mIGluc3RydWN0aW9ucyBvbg0KPj4+IGhvdyB0byBp
bnNlcnQsIG1vZGlmeSBvciByZW1vdmUgRUggZWxlbWVudHMuDQo+Pj4+IA0KPj4+PiBTbyB3aGF0
IGV4YWN0bHkgYXJlIHlvdSBleHBlY3RpbmcgV0cgdG8gZGVsaXZlciBhcyBuZXh0IHN0ZXAgaWYg
MjQ2MGJpcw0KPj4+IGdvZXMgZndkID8gSXMgZGV0ZWN0aW5nIHRoZSBtYXggTVRVIG9uIGVuZCB0
byBlbmQgcGF0aCBldmVuIGluIDZtYW4ncw0KPj4+IGNoYXJ0ZXIgPw0KPj4+IA0KPj4+IFlvdSBj
YW4gd3JpdGUgYSBuZXcgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBpbmRlcGVuZGVudGx5IG9mIDI0
NjBiaXMgdGhhdA0KPj4+IGRvZXMgd2hhdGV2ZXIgaXQgaGFzIHRvIGRvLCBhbmQgdGhlbiB3ZSBj
YW4gYXJndWUgb3ZlciB0aGF0IGRvY3VtZW50IG9uIGl0cw0KPj4+IG93biBtZXJpdHMuDQo+Pj4g
DQo+Pj4gQ2hlZXJzLA0KPj4+IE9sZQ0KPj4+IA0KPj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJ
RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBB
ZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KDQo=


From nobody Thu Mar 30 15:14:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD2F1295E7; Thu, 30 Mar 2017 15:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 x_IsCxudx0mC; Thu, 30 Mar 2017 15:14:05 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B7A12426E; Thu, 30 Mar 2017 15:14:05 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id y18so2823125itc.0; Thu, 30 Mar 2017 15:14:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xfRV0uNVwkm5pRQtWVuMEUfHqVsUdlRyijKL5Hc1Tpc=; b=mxy3f9V4DCMOycfXjjH2A2qd7e2Bhi4tbFdCBO/oq0tuFiNs4quSweD7TLupsN9ZOR VPVqIO5lYozHvm01lA5L8izBNTbN9yEjDwEaveGAJdZnZhnlXFFnAIUL42UTMmmgW754 DCSW4ryK2o2p910qhLxz6GAusOu2qijTRmd/xWdleBM47m6ex0XwApIXs54EQ4w2l4Vb gny/F/YyBr17e5SXRLAsEAmgsn+5qxQIfIodwAuYZozjyfpujMgqUypeB0/eaOtT99Pq e56f60TPkt1VP2GDCYOHEtDabLE1H2FDff2KqIFBcUZ4j6rtjskb/p0/qPXwBBTptXVS pfEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xfRV0uNVwkm5pRQtWVuMEUfHqVsUdlRyijKL5Hc1Tpc=; b=pSyyj9HXIIznRu6reg2h5u0nHaPYZtrM6AELzQBMWXeJYmxr9RpFthqO1v7UKQGnoQ v49Zmkwg3sz5lEm49q6nJdWmW6I1aelQlr80/GSk/99gHbmhLK410PSl2Kb9QGkxECsi pml+eCl2zaX9vmf6aaM3mwCcQUgIrdWydU7hc+SU1gpQik0lkszTDHuB1aY4xzoYSl/s 71NgUeEa7kYXHohUoLDMpKYSm4r0kcQ4MFWpVisleHQBMAyzSVUgrIPVZnYXrXeDjSux iSqxpkYM7rB93IX7Ybff0bh7UHKHV2TjHXogv2iBZy/PvUU4wy3Qp+Lx2eTOkU6KwBtG emug==
X-Gm-Message-State: AFeK/H17CtTMWQRTjQXatUqgwWD0rksqzHU80HS9VLtg8kmXi0LTqnTtIUk/NH5vOtAONRQafN5iBGd0pQq1eg==
X-Received: by 10.36.48.66 with SMTP id q63mr624614itq.18.1490912044818; Thu, 30 Mar 2017 15:14:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.184.197 with HTTP; Thu, 30 Mar 2017 15:13:44 -0700 (PDT)
In-Reply-To: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>
From: Jen Linkova 
Date: Fri, 31 Mar 2017 00:13:44 +0200
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Suresh Krishnan 
Cc: "ietf@ietf.org" , 6man WG ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 22:14:07 -0000

On Wed, Mar 15, 2017 at 3:47 AM, Suresh Krishnan
 wrote:
> Thanks to everyone who commented during the IETF Last Call of draft-ietf-=
6man-rfc2460bis-08. The IETF last call discussion for this draft was mainly=
 focused around the text in Section 4 that discusses the handling of extens=
ion headers. The biggest concern raised was that the current text is ambigu=
ous on whether header insertion is allowed on intermediate nodes or not. Th=
ere were some people arguing that an explicit prohibition is not necessary =
as the text is already clear, while others believed that explicitly listing=
 the prohibitions will minimize any misunderstandings in the future. There =
was also a small number of people who wanted to explicitly allow header ins=
ertion and describe how to do it, but this was clearly out of scope for thi=
s draft (but may be in scope for future work in 6man). Overall, no one argu=
ed against the fact that the intent of the text in RFC2460 was to forbid in=
sertion of extension headers on any other node but the source of the packet=
.  The only argument made against adding clarifying text was that the text =
was already clear. Given this, I believe there is consensus to add explicit=
 text about header insertion into the draft before it progresses further. I=
 have discussed this with the editor and the document shepherd and would li=
ke to propose the following text change.
>
> OLD (from -08):
>
>  The insertion of Extension Headers by any node other than the source
>  of the packet causes serious problems.  Two examples include breaking
>  the integrity checks provided by the Authentication Header Integrity
>  [RFC4302], and breaking Path MTU Discovery which can result in ICMP
>  error messages being sent to the source of the packet that did not
>  insert the header, rather than the node that inserted the header.
>
>  One approach to avoid these problems is to encapsulate the packet
>  using another IPv6 header and including the additional extension
>  header after the first IPv6 header, for example, as defined in
>  [RFC2473]
>
>  With one exception, extension headers are not processed by any node
>  along a packet's delivery path, until the packet reaches the node (or
>  each of the set of nodes, in the case of multicast) identified in the
>  Destination Address field of the IPv6 header...
>
> NEW:
>
>  With one exception, extension headers are not examined, processed,
>  inserted, or deleted by any node along a packet's delivery path,
>  until the packet reaches the node (or each of the set of nodes, in
>  the case of multicast) identified in the Destination Address field of
>  the IPv6 header...

I have some concerns with how that sentence AND the following note
comes together:

"  With one exception, extension headers are not examined, processed,
   inserted, or deleted by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  Note: If an intermediate forwarding node examines
   an extension header for any reason, it must do so in accordance with
   the provisions of [RFC7045].  "

I'm afraid that the lack of the normative language strikes back..
If 'are not examined" is to be interpreted as RFC2119 'MUST NOT',
then the following note conflicts with that statement. 'A node MUST
NOT examine EHs
but if it does it must do it as per RFC7045' - it is extremely controversia=
l.

If ''are not examined" is to be read as RFC2119 'SHOULD NOT' then I
have a very good news for
those who would still like to insert/delete EHs: they can do it  as
long as  they have
"valid reasons in particular circumstances when the particular
behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.".
But from today's presentation I've got an impression that the
intention of this text was actually to prohibit EH insertion
(the sildes say 'no one argued against the fact that the intent of the
text in RFC2460
was to forbid insertion of extension headers on any other node but the sour=
ce
of the packet.).

So to summarize: the proposed text either explicitly prohibits the
examination (and then it contradicts the next sentence and we need to
do smth with the note and RFC7045) OR it allows EH insertion - it
depends how the text is interpreted.

--=20
SY, Jen Linkova aka Furry


From nobody Thu Mar 30 16:09:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1043129495 for ; Thu, 30 Mar 2017 16:09:09 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xn3QjNjWNrPl for ; Thu, 30 Mar 2017 16:09:07 -0700 (PDT)
Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD0B126C23 for ; Thu, 30 Mar 2017 16:08:58 -0700 (PDT)
Received: by mail-it0-x243.google.com with SMTP id w11so543992itb.0 for ; Thu, 30 Mar 2017 16:08:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=+JNDGyvxz+iZCoeQc4S3mTe5Ir/sxc/tEbD+c2XWfeY=; b=RqJsaw9gfWgNkPVLSqFAi7Q5ByGOW00JcFjAwLsPe8LcAv5NtWh5Rjt0UsagWv4a8d DWuuOxjlTQU5cETiNuP8gILWahMzCFfDQD9XIYMeyOLJNorruVdpuUHgUfpB2N1bNizr WOgkIjXlBHPJovND5XUcpHjD5INFgqJyBepERocI7WjmDvFVhoKiKNPeMbmxJ5r7vxnJ /KfxYh2JgkDpAieEw/S0dp7tWUxjnZ74+RPCUMPjYHhM7Jv9RQLhUR/nPUHm/P35BNNE gMAla2eJxom2qG4P9QY5lzpxwJxVchVAqv0ggLPluDgxY6XqmMioJFmlJc4at6+1a+mI RW3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=+JNDGyvxz+iZCoeQc4S3mTe5Ir/sxc/tEbD+c2XWfeY=; b=KsaCFoXi8+JVdyjN+Oeqj9odlZZ51J0fXsY7CWdubYy1I70m/SvkNkUqRL23gSTtN8 3Yq31nf/i+75SqHYOPpBPUUuwTsikOD4rDEM6Z8yPyqjc8H8r3KiHsTKi3A80frOZ95H u+6zuUHzCRUrPlproaeFSqbP2hSTJ/6ZrAqV0nAVoWN7TLH7Rzf2YyRKcgD02uCnbd7P mY4l/6/QLnTiaZ2smCI3HSz3M9wpZ7gYwIduIKiISnbk1Wa4RUSZUyVzs7rlyuQvUbRw 4TDqM1kL4df7ytJgEEwRJRAR+GD4eDglxdAoQX+hLpx/YTdxXwgTuO/6KQJoAHE9KaVb tvXg==
X-Gm-Message-State: AFeK/H0n13U4mqR5y6yn8JQdjds59AEo5S47Zy35DYPcxZA+JeaAa6SiFTnKtkmdjzLauA==
X-Received: by 10.36.241.15 with SMTP id c15mr740726iti.77.1490915337765; Thu, 30 Mar 2017 16:08:57 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f102sm2195844ioj.26.2017.03.30.16.08.57 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 16:08:57 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: ipv6@ietf.org
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Fri, 31 Mar 2017 12:09:06 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 23:09:10 -0000

T24gMzEvMDMvMjAxNyAxMToxMywgSmVuIExpbmtvdmEgd3JvdGU6DQo+IE9uIFdlZCwgTWFy
IDE1LCAyMDE3IGF0IDM6NDcgQU0sIFN1cmVzaCBLcmlzaG5hbg0KPiA8c3VyZXNoLmtyaXNo
bmFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiBUaGFua3MgdG8gZXZlcnlvbmUgd2hvIGNv
bW1lbnRlZCBkdXJpbmcgdGhlIElFVEYgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtNm1hbi1y
ZmMyNDYwYmlzLTA4LiBUaGUgSUVURiBsYXN0IGNhbGwgZGlzY3Vzc2lvbiBmb3IgdGhpcyBk
cmFmdCB3YXMgbWFpbmx5IGZvY3VzZWQgYXJvdW5kIHRoZSB0ZXh0IGluIFNlY3Rpb24gNCB0
aGF0IGRpc2N1c3NlcyB0aGUgaGFuZGxpbmcgb2YgZXh0ZW5zaW9uIGhlYWRlcnMuIFRoZSBi
aWdnZXN0IGNvbmNlcm4gcmFpc2VkIHdhcyB0aGF0IHRoZSBjdXJyZW50IHRleHQgaXMgYW1i
aWd1b3VzIG9uIHdoZXRoZXIgaGVhZGVyIGluc2VydGlvbiBpcyBhbGxvd2VkIG9uIGludGVy
bWVkaWF0ZSBub2RlcyBvciBub3QuIFRoZXJlIHdlcmUgc29tZSBwZW9wbGUgYXJndWluZyB0
aGF0IGFuIGV4cGxpY2l0IHByb2hpYml0aW9uIGlzIG5vdCBuZWNlc3NhcnkgYXMgdGhlIHRl
eHQgaXMgYWxyZWFkeSBjbGVhciwgd2hpbGUgb3RoZXJzIGJlbGlldmVkIHRoYXQgZXhwbGlj
aXRseSBsaXN0aW5nIHRoZSBwcm9oaWJpdGlvbnMgd2lsbCBtaW5pbWl6ZSBhbnkgbWlzdW5k
ZXJzdGFuZGluZ3MgaW4gdGhlIGZ1dHVyZS4gVGhlcmUgd2FzIGFsc28gYSBzbWFsbCBudW1i
ZXIgb2YgcGVvcGxlIHdobyB3YW50ZWQgdG8gZXhwbGljaXRseSBhbGxvdyBoZWFkZXIgaW5z
ZXJ0aW9uIGFuZCBkZXNjcmliZSBob3cgdG8gZG8gaXQsIGJ1dCB0aGlzIHdhcyBjbGVhcmx5
IG91dCBvZiBzY29wZSBmb3IgdGhpcyBkcmFmdCAoYnV0IG1heSBiZSBpbiBzY29wZSBmb3Ig
ZnV0dXJlIHdvcmsgaW4gNm1hbikuIE92ZXJhbGwsIG5vIG9uZSBhcmd1ZWQgYWdhaW5zdCB0
aGUgZmFjdCB0aGF0IHRoZSBpbnRlbnQgb2YgdGhlIHRleHQgaW4gUkZDMjQ2MCB3YXMgdG8g
Zm9yYmlkIGluc2VydGlvbiBvZiBleHRlbnNpb24gaGVhZGVycyBvbiBhbnkgb3RoZXIgbm9k
ZSBidXQgdGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0LiAgVGhlIG9ubHkgYXJndW1lbnQgbWEN
Cj4gIGRlIGFnYWluc3QgYWRkaW5nIGNsYXJpZnlpbmcgdGV4dCB3YXMgdGhhdCB0aGUgdGV4
dCB3YXMgYWxyZWFkeSBjbGVhci4gR2l2ZW4gdGhpcywgSSBiZWxpZXZlIHRoZXJlIGlzIGNv
bnNlbnN1cyB0byBhZGQgZXhwbGljaXQgdGV4dCBhYm91dCBoZWFkZXIgaW5zZXJ0aW9uIGlu
dG8gdGhlIGRyYWZ0IGJlZm9yZSBpdCBwcm9ncmVzc2VzIGZ1cnRoZXIuIEkgaGF2ZSBkaXNj
dXNzZWQgdGhpcyB3aXRoIHRoZSBlZGl0b3IgYW5kIHRoZSBkb2N1bWVudCBzaGVwaGVyZCBh
bmQgd291bGQgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dCBjaGFuZ2UuDQo+
Pg0KPj4gT0xEIChmcm9tIC0wOCk6DQo+Pg0KPj4gIFRoZSBpbnNlcnRpb24gb2YgRXh0ZW5z
aW9uIEhlYWRlcnMgYnkgYW55IG5vZGUgb3RoZXIgdGhhbiB0aGUgc291cmNlDQo+PiAgb2Yg
dGhlIHBhY2tldCBjYXVzZXMgc2VyaW91cyBwcm9ibGVtcy4gIFR3byBleGFtcGxlcyBpbmNs
dWRlIGJyZWFraW5nDQo+PiAgdGhlIGludGVncml0eSBjaGVja3MgcHJvdmlkZWQgYnkgdGhl
IEF1dGhlbnRpY2F0aW9uIEhlYWRlciBJbnRlZ3JpdHkNCj4+ICBbUkZDNDMwMl0sIGFuZCBi
cmVha2luZyBQYXRoIE1UVSBEaXNjb3Zlcnkgd2hpY2ggY2FuIHJlc3VsdCBpbiBJQ01QDQo+
PiAgZXJyb3IgbWVzc2FnZXMgYmVpbmcgc2VudCB0byB0aGUgc291cmNlIG9mIHRoZSBwYWNr
ZXQgdGhhdCBkaWQgbm90DQo+PiAgaW5zZXJ0IHRoZSBoZWFkZXIsIHJhdGhlciB0aGFuIHRo
ZSBub2RlIHRoYXQgaW5zZXJ0ZWQgdGhlIGhlYWRlci4NCj4+DQo+PiAgT25lIGFwcHJvYWNo
IHRvIGF2b2lkIHRoZXNlIHByb2JsZW1zIGlzIHRvIGVuY2Fwc3VsYXRlIHRoZSBwYWNrZXQN
Cj4+ICB1c2luZyBhbm90aGVyIElQdjYgaGVhZGVyIGFuZCBpbmNsdWRpbmcgdGhlIGFkZGl0
aW9uYWwgZXh0ZW5zaW9uDQo+PiAgaGVhZGVyIGFmdGVyIHRoZSBmaXJzdCBJUHY2IGhlYWRl
ciwgZm9yIGV4YW1wbGUsIGFzIGRlZmluZWQgaW4NCj4+ICBbUkZDMjQ3M10NCj4+DQo+PiAg
V2l0aCBvbmUgZXhjZXB0aW9uLCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IHByb2Nlc3Nl
ZCBieSBhbnkgbm9kZQ0KPj4gIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwgdW50
aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvcg0KPj4gIGVhY2ggb2YgdGhlIHNl
dCBvZiBub2RlcywgaW4gdGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBpZGVudGlmaWVkIGluIHRo
ZQ0KPj4gIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YgdGhlIElQdjYgaGVhZGVyLi4u
DQo+Pg0KPj4gTkVXOg0KPj4NCj4+ICBXaXRoIG9uZSBleGNlcHRpb24sIGV4dGVuc2lvbiBo
ZWFkZXJzIGFyZSBub3QgZXhhbWluZWQsIHByb2Nlc3NlZCwNCj4+ICBpbnNlcnRlZCwgb3Ig
ZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGgsDQo+
PiAgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNoIG9mIHRoZSBz
ZXQgb2Ygbm9kZXMsIGluDQo+PiAgdGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBpZGVudGlmaWVk
IGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mDQo+PiAgdGhlIElQdjYgaGVh
ZGVyLi4uDQo+IA0KPiBJIGhhdmUgc29tZSBjb25jZXJucyB3aXRoIGhvdyB0aGF0IHNlbnRl
bmNlIEFORCB0aGUgZm9sbG93aW5nIG5vdGUNCj4gY29tZXMgdG9nZXRoZXI6DQo+IA0KPiAi
ICBXaXRoIG9uZSBleGNlcHRpb24sIGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBub3QgZXhhbWlu
ZWQsIHByb2Nlc3NlZCwNCj4gICAgaW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUg
YWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLA0KPiAgICB1bnRpbCB0aGUgcGFja2V0
IHJlYWNoZXMgdGhlIG5vZGUgKG9yIGVhY2ggb2YgdGhlIHNldCBvZiBub2RlcywgaW4NCj4g
ICAgdGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBpZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlv
biBBZGRyZXNzIGZpZWxkIG9mDQo+ICAgIHRoZSBJUHY2IGhlYWRlci4gIE5vdGU6IElmIGFu
IGludGVybWVkaWF0ZSBmb3J3YXJkaW5nIG5vZGUgZXhhbWluZXMNCj4gICAgYW4gZXh0ZW5z
aW9uIGhlYWRlciBmb3IgYW55IHJlYXNvbiwgaXQgbXVzdCBkbyBzbyBpbiBhY2NvcmRhbmNl
IHdpdGgNCj4gICAgdGhlIHByb3Zpc2lvbnMgb2YgW1JGQzcwNDVdLiAgIg0KPiANCj4gSSdt
IGFmcmFpZCB0aGF0IHRoZSBsYWNrIG9mIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugc3RyaWtl
cyBiYWNrLi4NCg0KRXhhY3RseSB0aGUgb3Bwb3NpdGUsIElNSE8uIEkgdGhpbmsgaXQncyBt
dWNoIGJldHRlciBsaWtlIHRoaXMgdGhhbiBpdA0Kd291bGQgYmUgdW5kZXIgUkZDMjExOSAo
YWx0aG91Z2ggaW4gZmFjdCB0aGF0IGRvZXNuJ3QgY2hhbmdlIHRoZSANCkVuZ2xpc2ggbWVh
bmluZyBvZiAnbXVzdCcpLiBUaGUgIk5vdGU6IiBkZXNjcmliZXMgYSBzaXR1YXRpb24gd2hl
cmUNCm1pZGRsZWJveGVzIGFyZSBhY3R1YWxseSBicmVha2luZyB0aGUgcnVsZS4gV2UgaGFk
IHRoYXQgZmlnaHQgYmVmb3JlDQpSRkM3MDQ1Lg0KDQogICAgIEJyaWFuDQogDQoNCj4gSWYg
J2FyZSBub3QgZXhhbWluZWQiIGlzIHRvIGJlIGludGVycHJldGVkIGFzIFJGQzIxMTkgJ01V
U1QgTk9UJywNCj4gdGhlbiB0aGUgZm9sbG93aW5nIG5vdGUgY29uZmxpY3RzIHdpdGggdGhh
dCBzdGF0ZW1lbnQuICdBIG5vZGUgTVVTVA0KPiBOT1QgZXhhbWluZSBFSHMNCj4gYnV0IGlm
IGl0IGRvZXMgaXQgbXVzdCBkbyBpdCBhcyBwZXIgUkZDNzA0NScgLSBpdCBpcyBleHRyZW1l
bHkgY29udHJvdmVyc2lhbC4NCj4gDQo+IElmICcnYXJlIG5vdCBleGFtaW5lZCIgaXMgdG8g
YmUgcmVhZCBhcyBSRkMyMTE5ICdTSE9VTEQgTk9UJyB0aGVuIEkNCj4gaGF2ZSBhIHZlcnkg
Z29vZCBuZXdzIGZvcg0KPiB0aG9zZSB3aG8gd291bGQgc3RpbGwgbGlrZSB0byBpbnNlcnQv
ZGVsZXRlIEVIczogdGhleSBjYW4gZG8gaXQgIGFzDQo+IGxvbmcgYXMgIHRoZXkgaGF2ZQ0K
PiAidmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgd2hlbiB0aGUg
cGFydGljdWxhcg0KPiBiZWhhdmlvciBpcyBhY2NlcHRhYmxlIG9yIGV2ZW4gdXNlZnVsLCBi
dXQgdGhlIGZ1bGwNCj4gICAgaW1wbGljYXRpb25zIHNob3VsZCBiZSB1bmRlcnN0b29kIGFu
ZCB0aGUgY2FzZSBjYXJlZnVsbHkgd2VpZ2hlZA0KPiAgICBiZWZvcmUgaW1wbGVtZW50aW5n
IGFueSBiZWhhdmlvciBkZXNjcmliZWQgd2l0aCB0aGlzIGxhYmVsLiIuDQo+IEJ1dCBmcm9t
IHRvZGF5J3MgcHJlc2VudGF0aW9uIEkndmUgZ290IGFuIGltcHJlc3Npb24gdGhhdCB0aGUN
Cj4gaW50ZW50aW9uIG9mIHRoaXMgdGV4dCB3YXMgYWN0dWFsbHkgdG8gcHJvaGliaXQgRUgg
aW5zZXJ0aW9uDQo+ICh0aGUgc2lsZGVzIHNheSAnbm8gb25lIGFyZ3VlZCBhZ2FpbnN0IHRo
ZSBmYWN0IHRoYXQgdGhlIGludGVudCBvZiB0aGUNCj4gdGV4dCBpbiBSRkMyNDYwDQo+IHdh
cyB0byBmb3JiaWQgaW5zZXJ0aW9uIG9mIGV4dGVuc2lvbiBoZWFkZXJzIG9uIGFueSBvdGhl
ciBub2RlIGJ1dCB0aGUgc291cmNlDQo+IG9mIHRoZSBwYWNrZXQuKS4NCj4gDQo+IFNvIHRv
IHN1bW1hcml6ZTogdGhlIHByb3Bvc2VkIHRleHQgZWl0aGVyIGV4cGxpY2l0bHkgcHJvaGli
aXRzIHRoZQ0KPiBleGFtaW5hdGlvbiAoYW5kIHRoZW4gaXQgY29udHJhZGljdHMgdGhlIG5l
eHQgc2VudGVuY2UgYW5kIHdlIG5lZWQgdG8NCj4gZG8gc210aCB3aXRoIHRoZSBub3RlIGFu
ZCBSRkM3MDQ1KSBPUiBpdCBhbGxvd3MgRUggaW5zZXJ0aW9uIC0gaXQNCj4gZGVwZW5kcyBo
b3cgdGhlIHRleHQgaXMgaW50ZXJwcmV0ZWQuDQo+IA0K


From nobody Thu Mar 30 16:18:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088BC128B38 for ; Thu, 30 Mar 2017 16:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 zjhTGKS7Qh-B for ; Thu, 30 Mar 2017 16:18:37 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC67126C23 for ; Thu, 30 Mar 2017 16:18:36 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id v76so31454583ywg.0 for ; Thu, 30 Mar 2017 16:18:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OTOuFKbnu0tVbA39Lp5+Uq9MX6IpK7ApX3v5nh7rV8c=; b=kgno6aCsXWZM9DRb5biI3Qt4QbGtQ1YFpSXwJ+FAm5dw4awlxze9yi25OiNbLltrjl LGx/NfC2w7jE+Ugzf1lmdobJGynbO8hys2c5sxIUvYW1ApbHxIHXn1IB43LH0EKo5sRo X3t+iiEMH2y9O6iWumfdhsvvBpzydkaL3DVGeUSntp4hxocLygwkbLGEAp5pjQfFpBE5 Ep5AG7Y1ZkJIqfklddcWVvytT3buQKabo0C9xZxG3gQKy2Z0ZbRzxXPhph0IRCVbadkn CmQRx9vsTFanC8R7w5GQX28Zfhyzg2JeOHWmWcwRQ/97AzpmhSWl2N/24pNeU2tzlaiD wRNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OTOuFKbnu0tVbA39Lp5+Uq9MX6IpK7ApX3v5nh7rV8c=; b=rqVVSiuy8DKIG5X6ODH+sA9pAvp6vssPX8imR1KrcmhcjRK8HxWjO8baZ06LK6X22d qrJ1cgt24uf04nPLXo5kEVkZF4/gEPBEO6mo9xxvqMD+SFDk1CrxYmNncjKFRa2sQUmW AnMgsznMP+HMzDjI43JKIPjVWP6Fk1xUL0UVHbGrBB7o3UeHRY2I8aFnux0bkDzGLXtz lZplRn5eExqcOSWlorsWmldb/dlsg2Z1t5BnfuVC/67P1V3su47E71L/CgpW1pMPF02+ CMXy1T5iT9ma39N3BMMGSdET5GYKUmjlOvGBj8bZe5SDn/ThDXejoeO4Y1qBw5cWCaGP T/HQ==
X-Gm-Message-State: AFeK/H3I/9sPf0ywwaA9wQ9TROB07xsiUpeba7oxVS+FvWqnn7zqdLSR4JM/tIkCEES34ZP2EpnqV5+lEt3AlOs1
X-Received: by 10.129.137.66 with SMTP id z63mr2059859ywf.211.1490915915768; Thu, 30 Mar 2017 16:18:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.50.7 with HTTP; Thu, 30 Mar 2017 16:18:15 -0700 (PDT)
In-Reply-To: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com>
References:  <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com>
From: Erik Kline 
Date: Thu, 30 Mar 2017 18:18:15 -0500
Message-ID: 
Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02
To: Alexandre Petrescu 
Cc: IETF IPv6 Mailing List 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c064e08955da6054bfae9fb"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 23:18:40 -0000

--94eb2c064e08955da6054bfae9fb
Content-Type: multipart/alternative; boundary=94eb2c064e088d29a2054bfae9d4

--94eb2c064e088d29a2054bfae9d4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I failed to explain myself at the mic, but I am thinking I need to state in
the document is the following:

    PIO-X and DHCPv6 PD are orthogonal

A network can serve a client a PIO-X *and* simultaneously answer any PD
requests from the same client.  They are not mutually exclusive nor are
they redundant.

In the model we tried to describe in the applicability statement, the
client has attached to the network, issued a vanilla RS, and the router
(perhaps doing PD on the client's behalf, or radius/diameter, or whatever)
has selected to send the client a PIO.  The extra bit just tells the client
that the PIO is not going to be given to anyone else (subject to various
lifetimes, etc).

If the client doesn't understand the X flag then it can still process the
PIO according to its existing code.  That's all.  No conflict with PD,
really.

On 30 March 2017 at 10:48, Alexandre Petrescu 
wrote:

> Hi, authors of PIO-X,
>
> My comment on the microphone:
>
> This is an earlier draft I co-authored that uses RS/RA messages to do
> Prefix Delegation.
>
> draft-kaiser-nd-pd-02
>
> https://tools.ietf.org/html/draft-kaiser-nd-pd-02
>
>
> I can resurrect it if necessary.
>
> Alex
>
> Le 28/03/2017 =C3=A0 11:57, Alexandre Petrescu a =C3=A9crit :
>
> In addition to asking how is this draft helping with DHCPv6 Prefix
> Delegation,
>
> I suggest addition of the following references.
>
> Where draft-pioxfolks-6man-pio-exclusive-bit-01 says:
> >    There are several initiatives that propose network side practices
> >    that provide customer isolation, enhanced operational scalability,
> >    power efficiency, security and other benefits in IPv6 network
> >    deployments.  Some of these involve isolating a host (or RA acceptin=
g
> >    client node) so that the host is the only node to receive a specific
> >    prefix, including
> >
> >    o  DHCPv6 Prefix Delegation to hosts ( >       draft-templin-v6ops-pdhost>), and
> >
> >    o  advertising a unique prefix per host via unique RAs.
> >       ( >       per-host>).
>
> it makes sense to add:
>
>     o  Prefix Delegation extensions to ND protocol have been introduced
>        in ,         option-00> and , and
>        probably earlier.
>
> Alex
>
> Le 04/03/2017 =C3=A0 06:31, Alexandre Petrescu a =C3=A9crit :
> > I do not oppose a slot presenting PIO-X if time allows.
> >
> > However, as I understand it, PIO-X has a single goal - that to
> > accomodate 64share.
> >
> > I wonder whether PIO-X could work with DHCPv6-PD?  Would PIO-X help
> > DHCPv6-PD deployment?
> >
> > This is what I am going to ask at the mic.
> >
> > Alex
> >
> >
> >
> > Le 01/03/2017 =C3=A0 11:27, Erik Kline a =C3=A9crit :
> >> Ole,
> >>
> >> It's on me to get a -02 of PIO-X written and uploaded.  Might it be
> >> possible to get 5 minutes on that?
> >>
> >> -ek
> >>
> >> On 27 February 2017 at 06:16,  >> > wrote:
> >>
> >>     The 6MAN chairs are planning the meeting in Chicago at IETF98.
> >>
> >>     If you have a draft you would like to discuss, please send your
> >>     request for agenda time to the 6man chairs.   Please include in th=
e
> >>     request, the title of the presentation, file name of the draft, th=
e
> >>     speaker's name (and email), and how much time you would like.
> >>
> >>     We will prioritise drafts that are working group items and drafts
> >>     that have been actively discussed on the list.
> >>
> >>     We expect at least half of each talk=E2=80=99s presentation time t=
o be used
> >>     for open discussion,
> >>     please plan your presentation accordingly.
> >>
> >>     New drafts not discussed on the mailing list prior to the meeting,
> >>     or drafts that do not appear to have support from the working grou=
p
> >>     are unlikely to get time at the meeting.
> >>
> >>     Please have agenda items to us by 2017-03-15.
> >>
> >>     Regards,
> >>
> >>     Bob & Ole
> >>
> >>     ------------------------------------------------------------
> --------
> >>     IETF IPv6 working group mailing list
> >>     ipv6@ietf.org 
> >>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv=
6
> >>     
> >>     ------------------------------------------------------------
> --------
> >>
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing listipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

--94eb2c064e088d29a2054bfae9d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I failed to explain myself at the mic, but I am thinking I=
 need to state in the document is the following:

    =C2=A0 =
=C2=A0 PIO-X and DHCPv6 PD are orthogonal

    A networ=
k can serve a client a PIO-X *and* simultaneously answer any PD requests fr=
om the same client.=C2=A0 They are not mutually exclusive nor are they redu=
ndant.

    In the model we tried to describe in the ap=
plicability statement, the client has attached to the network, issued a van=
illa RS, and the router (perhaps doing PD on the client's behalf, or ra=
dius/diameter, or whatever) has selected to send the client a PIO.=C2=A0 Th=
e extra bit just tells the client that the PIO is not going to be given to =
anyone else (subject to various lifetimes, etc).

    I=
f the client doesn't understand the X flag then it can still process th=
e PIO according to its existing code.=C2=A0 That's all.=C2=A0 No confli=
ct with PD, really.

    On 30 March 2017 at 10:48, Alexandre Petrescu <al=
exandre.petrescu@gmail.com> wrote:
    
 =20
   =20
 =20
  
    
    
    Hi, authors of PIO-X,
    
    
    My comment on the
          microphone:
    
    
    This is an earlier draf=
t
          I co-authored that uses RS/RA messages to do Prefix Delegation.
    
    
    draft-kaiser-nd-pd-02
    
    
    https://tools.ietf.org/html/draft-k=
aiser-nd-pd-02
    
    

    
          I can resurrect it if necessary.
    
        
    
    
    Alex
    
        
    
    
    
    
    Le 28/03/2017 =C3=
=A0 11:57, Alexandre
      Petrescu a =C3=A9crit=C2=A0:
    
    
    
    
    
     =20
      
    In addition to
          asking how is this draft helping with DHCPv6 Prefix
          Delegation,
    
          
    
          I suggest addition of the following references.
    
          
    
          Where draft-pioxfolks-6man-pio-exclusive-bit-01 says:
    
          >=C2=A0=C2=A0=C2=A0 There are several initiatives that propose=
 network
          side practices
    
          >=C2=A0=C2=A0=C2=A0 that provide customer isolation, enhanced =
operational
          scalability,
    
          >=C2=A0=C2=A0=C2=A0 power efficiency, security and other benef=
its in IPv6
          network
    
          >=C2=A0=C2=A0=C2=A0 deployments.=C2=A0 Some of these involve i=
solating a host
          (or RA accepting
    
          >=C2=A0=C2=A0=C2=A0 client node) so that the host is the only =
node to
          receive a specific
    
          >=C2=A0=C2=A0=C2=A0 prefix, including
    
          > 
    
          >=C2=A0=C2=A0=C2=A0 o=C2=A0 DHCPv6 Prefix Delegation to hosts =
(<https://too=
ls.ietf.org/html/
    
          >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-templin-v6ops-pdho=
st>), and
    
          > 
    
          >=C2=A0=C2=A0=C2=A0 o=C2=A0 advertising a unique prefix per ho=
st via unique
          RAs.
    
          >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (<https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-=

    
          >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 per-host>).
    
          
    
          it makes sense to add:
    
          
    
          =C2=A0=C2=A0=C2=A0 o=C2=A0 Prefix Delegation extensions to ND pro=
tocol have been
          introduced 
    
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in <draft-kaiser-nd-pd-02=
>,
          <draft-lutchann-ipv6-delegate-
    
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 option-00> and
          <draft-haberman-ipngwg-auto-prefix-02>, and 
    
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 probably earlier.
    
          
    
          Alex
    
          
    
          Le 04/03/2017 =C3=A0 06:31, Alexandre Petrescu a =C3=A9crit :
    
          > I do not oppose a slot presenting PIO-X if time allows.
    
          > 
    
          > However, as I understand it, PIO-X has a single goal -
          that to
    
          > accomodate 64share.
    
          > 
    
          > I wonder whether PIO-X could work with DHCPv6-PD?=C2=A0 Woul=
d
          PIO-X help
    
          > DHCPv6-PD deployment?
    
          > 
    
          > This is what I am going to ask at the mic.
    
          > 
    
          > Alex
    
          > 
    
          > 
    
          > 
    
          > Le 01/03/2017 =C3=A0 11:27, Erik Kline a =C3=A9crit :
    
          >> Ole,
    
          >>
    
          >> It's on me to get a -02 of PIO-X written and
          uploaded.=C2=A0 Might it be
    
          >> possible to get 5 minutes on that?
    
          >>
    
          >> -ek
    
          >>
    
          >> On 27 February 2017 at 06:16, <otroan@employees.org
    
          >> <mailto:otroan@employees.org>>
          wrote:
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 The 6MAN chairs are planning the=
 meeting in
          Chicago at IETF98.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 If you have a draft you would li=
ke to discuss,
          please send your
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 request for agenda time to the 6=
man chairs.=C2=A0=C2=A0
          Please include in the
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 request, the title of the presen=
tation, file name
          of the draft, the
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 speaker's name (and email), =
and how much time you
          would like.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 We will prioritise drafts that a=
re working group
          items and drafts
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 that have been actively discusse=
d on the list.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 We expect at least half of each =
talk=E2=80=99s
          presentation time to be used
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 for open discussion,
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 please plan your presentation ac=
cordingly.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 New drafts not discussed on the =
mailing list
          prior to the meeting,
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 or drafts that do not appear to =
have support from
          the working group
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 are unlikely to get time at the =
meeting.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 Please have agenda items to us b=
y 2017-03-15.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 Regards,
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 Bob & Ole
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0
          ------------------------------------------------------------=
--------
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 IETF IPv6 working group mailing =
list
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 ipv6@ietf.org <mailto:ipv6@ietf.org>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 Administrative Requests: https://w=
ww.ietf.org/mailman/listinfo/ipv6
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 <https://www.ietf.org/mailman/<=
wbr>listinfo/ipv6>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0
          ------------------------------------------------------------=
--------
    
          >>
    
          >>
    
          >>
    
          >>
    
          >>
          ------------------------------------------------------------=
--------
    
          >> IETF IPv6 working group mailing list
    
          >> ipv6@=
ietf.org
    
          >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    
          >>
          ------------------------------------------------------------=
--------
    
          >>
    
          > 
    
          >
          ------------------------------------------------------------=
--------
    
          > IETF IPv6 working group mailing list
    
          > ipv6@ietf=
.org
    
          > Administrative Requests: https://www.ietf.org/mailman/lis=
tinfo/ipv6
    
          >
          ------------------------------------------------------------=
--------
    
          > 
    
        
    
      
    
      
    
      
    
      
    
      
    -----------------------------------------------------------=
---------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------=
---

    
    
    
    
    
  
    


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


    

--94eb2c064e088d29a2054bfae9d4--

--94eb2c064e08955da6054bfae9fb
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy
MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L
KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N
LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7
oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8
kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm
MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo
dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud
DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg
PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i
YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh
bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX
iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S
toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2
/5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c
UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw
jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgHLSNZCD2e89qihPZ7gdZMs9RXl38Y6+u
0iRoAuzP71MwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzMw
MjMxODM2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAKrh/smycAz98SCYzs14bHoFors51lU4sXg5h3kbrrMx/th31ky5
0DokUPc/xNtjRCMCo62AqiPtaahNzLkenIk2FpTOeVLyePCw0Nc8lWqPhlbxjnmQyD+Evacb4ar+
6Y4p1XEZ4P/+C69iR5rFsdopPvC0W4pbZmiCXTUVboN52wD5RHLfXSxOrvW62YDJPgT1lHrK4XMJ
NHpZaJGHh3becyGnGEFZPIYX5Xcm38+UKFI3B6iiFZDBP3HnG3CmxqfzOpD+jOfjU4yhOSo6QTa3
dVJZBsyz9IN0VSj2goHJsH1tEvemHMH25cfjTqvczkNDwzMulRDtlvYM3Y6gDqA=
--94eb2c064e08955da6054bfae9fb--


From nobody Thu Mar 30 16:53:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95719129642 for ; Thu, 30 Mar 2017 16:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 JTyBIa3DBXEV for ; Thu, 30 Mar 2017 16:53:25 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0613A129635 for ; Thu, 30 Mar 2017 16:53:25 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id z13so30168650iof.2 for ; Thu, 30 Mar 2017 16:53:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uX17oR05lSZ53QBzMDLKlNuzdAfEOeZGZLrvAfCk7Tk=; b=m7WJ7Kzdp2CxmnrnvROVhG9tKHMJ3WMw4cLm58YN7a7bUo9ItvA/3ziFRqfbi69ia0 a5duKd78f8ks4gmWOE1LR+N0ez69r0CPELUdNu491rJeoctFEMWqVlMs9r6BZPEsN6V7 QLa9fSS9koli0uvgKEKWx1u/h49gWZ3T5CutoPujs/8y60EYRLIYfcf8cAF1n5R3iHmE v9nrDyIQtYFp/062uiERFVm+qyU3GfveP3/ODDsQ3MjSJCc+c9iLehMZkr9FkH6o4NVp 2p9M3CFRtG9TvH6ZckjYn6rjmwMQZURJFcupFOuF0h9GF0RcB0SQAb1AdSnJ/LUI8Dq4 OXgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uX17oR05lSZ53QBzMDLKlNuzdAfEOeZGZLrvAfCk7Tk=; b=kqDpPw7G+f2tP+0GzSabuQzKiIQE8POURGpaexBkzUji3jUyxXKgYwTuoh95t+E7Jm Vd359YTCryDKng9Yz60o6ShdZXSTU4eA/9XAhCgpyPtbzAUG4hwk77joduc62b8Vyi4c GeeZUwwBSy0inGEAzqxfHGs3SAmboNNPpBgPuU089T1eYM3pk/JTdSM2otfn0hx627Qy f+ypm7LTdylA6+PpKQ/1rmjQbdPaB2Z4ego23pU+fNZWgTFj7yRMb3PEMEwmsVvqSrr2 ABXE1RXZ77i2cXrqu+7CkvUf1b3szZH3Wg8yN4vBd5c8MPIllFcZzsspR0a3VZ7MbxyF U6hg==
X-Gm-Message-State: AFeK/H0VhAjLrqo6HfVRrau/LlR//fnkEndjVxAVc576FqM10pL2RqBaagDTxkDIOMpTciS+sjhnjraTa4MgYQ==
X-Received: by 10.107.198.193 with SMTP id w184mr131513iof.19.1490918004394; Thu, 30 Mar 2017 16:53:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.184.197 with HTTP; Thu, 30 Mar 2017 16:53:03 -0700 (PDT)
In-Reply-To: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>  
From: Jen Linkova 
Date: Fri, 31 Mar 2017 01:53:03 +0200
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Brian E Carpenter 
Cc: 6man 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Mar 2017 23:53:27 -0000

On Fri, Mar 31, 2017 at 1:09 AM, Brian E Carpenter
 wrote:
>>> NEW:
>>>
>>>  With one exception, extension headers are not examined, processed,
>>>  inserted, or deleted by any node along a packet's delivery path,
>>>  until the packet reaches the node (or each of the set of nodes, in
>>>  the case of multicast) identified in the Destination Address field of
>>>  the IPv6 header...
>>
>> I have some concerns with how that sentence AND the following note
>> comes together:
>>
>> "  With one exception, extension headers are not examined, processed,
>>    inserted, or deleted by any node along a packet's delivery path,
>>    until the packet reaches the node (or each of the set of nodes, in
>>    the case of multicast) identified in the Destination Address field of
>>    the IPv6 header.  Note: If an intermediate forwarding node examines
>>    an extension header for any reason, it must do so in accordance with
>>    the provisions of [RFC7045].  "
>>
>> I'm afraid that the lack of the normative language strikes back..
>
> Exactly the opposite, IMHO. I think it's much better like this than it
> would be under RFC2119 (although in fact that doesn't change the
> English meaning of 'must'). The "Note:" describes a situation where
> middleboxes are actually breaking the rule. We had that fight before
> RFC7045.

Shell we then say
'Extension headers are not processed by intermediate nodes unless
those nodes strictly
follow [RFC7045].  With one exception, extension headers are not modified,
inserted, or deleted by any node along a packet's delivery path,
 until the packet reaches the node (or each of the set of nodes, in
the case of multicast) identified in the Destination Address field of
the IPv6 header."
?


-- 
SY, Jen Linkova aka Furry


From nobody Thu Mar 30 22:03:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33271289B5 for ; Thu, 30 Mar 2017 22:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zGrcaeTgMMeK for ; Thu, 30 Mar 2017 22:03:13 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6071128C81 for ; Thu, 30 Mar 2017 22:03:09 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id y18so6708032itc.0 for ; Thu, 30 Mar 2017 22:03:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=5qt6thMM/6Q8inTps/fP8RQn5kaxoLLRUaUuNjwuoew=; b=eyT4+pQL5uuDAKVP4NVHDT0aWnMWrn3UDueKA155ykgo9bLZg0IpOvOkbTwdzkEqo9 iqrEUIBN1w7AjdB05scFNiYqnNFAn7MJK7wFQ3rYmgjNKZWh5yRbnXn7hYsySpzMV9kY ZL8ApwIv+8QeeZVPzduuH8dyLaufLm90l8SK54UT78TdU2Ai4zaDlLkDQtVanKn1Mjud HZEk3NbInuMZfEUHSUA/EBeX+khg6tCnJeQDOE2Ka6Ydz56GEbiHIeXjWisZlG8/phkm 8h4yKXXL6sP2dNrIfwEvXQFYIw5iiigcvfVpgOqRvrYLFlPGvMgi5ZKCHJZEogTR65fr 4UKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5qt6thMM/6Q8inTps/fP8RQn5kaxoLLRUaUuNjwuoew=; b=WnDoEyfr6AXaTeoVohAMtGUW3xgBHsi+8XgkIjW1E/4n2I/n9s8JXvFESMJZplay4u YObu0nL9BaCQzgC7VnJm3cEwtrtYE/xToYZS4aPyg7iwPC0FMtuZsfK6mYtfl0q7hXoc p8+/7MksieUkE3T0Zb/doTyKH6YVra5TEodEMA2vER3m98rCl/Yq6x1CGcdhwKv5L79E UxLaLfxr+o35wDn93s6ry8UepCW9v0E7gByBJPpnO328FMaRmWOYpdHccjgrMUJIopGD 8U9OvXcdOE8hYrftNk8wg4lCWzjSpwuxpuV0Y4Pf/R2G1yUUOYJ3kablqDL7wJIZNpKJ DDHw==
X-Gm-Message-State: AFeK/H38y9RBMkRq4ZXoIlhCWAI+JtaGii1cP1m4pNtcDh+xbCkDpC64D1pnX5Upat4MuHt0Qr15TnDqD5Hfkw==
X-Received: by 10.36.37.71 with SMTP id g68mr1266235itg.66.1490936589232; Thu, 30 Mar 2017 22:03:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.184.197 with HTTP; Thu, 30 Mar 2017 22:02:48 -0700 (PDT)
From: Jen Linkova 
Date: Fri, 31 Mar 2017 07:02:48 +0200
Message-ID: 
Subject: draft-linkova-6man-default-addr-selection-update-00
To: 6man 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 05:03:15 -0000

Hi,

I've just submitted a short draft which proposes minor changes to the source
address selection algorithm to make the implementations a bit more robust
to some failure scenarios:

https://www.ietf.org/id/draft-linkova-6man-default-addr-selection-update-00.txt
https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00

Comments/suggestions are appreciated.

Thanks!

-- 
SY, Jen Linkova aka Furry


From nobody Fri Mar 31 04:57:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBC3129527 for ; Fri, 31 Mar 2017 04:57:12 -0700 (PDT)
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 autolearn_force=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 1WUQzOkCIXxA for ; Fri, 31 Mar 2017 04:57:10 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C46D61294E9 for ; Fri, 31 Mar 2017 04:57:09 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1ctvAx-0000H1C; Fri, 31 Mar 2017 13:57:07 +0200
Message-Id: 
To: ipv6@ietf.org
Cc: Erik Kline 
Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 
From: Philip Homburg 
Sender: pch-bF054DD66@u-1.phicoh.com
References:  <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com>  
In-reply-to: Your message of "Thu, 30 Mar 2017 18:18:15 -0500 ."  
Date: Fri, 31 Mar 2017 13:57:06 +0200
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 11:57:12 -0000

>I failed to explain myself at the mic, but I am thinking I need to state in
>the document is the following:
>
>    PIO-X and DHCPv6 PD are orthogonal
>
>A network can serve a client a PIO-X *and* simultaneously answer any PD
>requests from the same client.  They are not mutually exclusive nor are
>they redundant.

We should try to avoid a situation like we currently have with DNS resolver
configuration. So if PIO-X has considerable overlap with PD then it is 
probably a bad idea.

Let me put up a strawman counter proposal. Instead of allocating a /64 to each
host, in my proposal a router allocates a /63. One /64 of the /63 will be
announced in the RA for SLAAC. The other will be available for PD. An 
unmodified host will use addresses from the SLAAC prefix. A PD aware client
will use addresses from the PD prefix.

The nice thing about PD is that is is future proof. If the 'host' has 
downstream interfaces, it can request additional prefixes using PD and
assign them to any downstream interfaces. The disadvanced of this proposal 
is that is wastes one bit.

(I guess the main worry is that this will grow out to general PD using RAs)

There is however one area where this proposal can do better than PD (but
currently it doesn't seem to do that).

The problem with PD for hosts is that actually forwarding packets to addresses
cover by the prefix is mostly undefined.

When a router receives a prefix using PD, when can expect the router to inject
the prefix in the local routing protocol and there is no issue with forwarding
traffic.

Hosts don't do that. Experience with CPEs that are required to behave as
hosts on their upstream interface shows that this leads to a lot of confusion.

So questions that I think this draft should clearly answer are

1) What happens if a router is rebooted? Does it have to store state on
   stable storage? Is there a way to signal to the host that it needs to do
   something. How does a router know the next hop for prefixes it handed out
   in the past. Can a router assign a new prefix to a host or does that
   have to be static/stable storage?

2) What happens if a host has a 'privacy event' and renumbers its MAC address,
   link local address and all IIDs. 

I think for 2) the draft currently says that this is not allowed, but I guess
that can be fixed.

I think for 1) the draft need to have clear enough language that implementors
will get it right. Otherwise we get the same mess as currently with PD.
There may be a simple way to fix 1) as well.



From nobody Fri Mar 31 05:36:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066CE1297CB for ; Fri, 31 Mar 2017 05:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.8
X-Spam-Level: 
X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 NwfR2mK1O8Z4 for ; Fri, 31 Mar 2017 05:36:18 -0700 (PDT)
Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845E71297BF for ; Fri, 31 Mar 2017 05:36:18 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 0B95CC8A for ; Fri, 31 Mar 2017 12:36:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ryt_UCrlXhj for ; Fri, 31 Mar 2017 07:36:17 -0500 (CDT)
Received: from mail-qt0-f197.google.com (mail-qt0-f197.google.com [209.85.216.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id B035FC83 for ; Fri, 31 Mar 2017 07:36:17 -0500 (CDT)
Received: by mail-qt0-f197.google.com with SMTP id q46so25225121qtb.16 for ; Fri, 31 Mar 2017 05:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lAXTmzhYARBSKiQsLTBEnk3PfPToIF/bhZyjIGR9a9E=; b=Z/akwoT7TE4W+hBxwE8lw2NJt+x4ZzJcD7kqU8QVk3azxjKYfs/xRNPNWbYsCCqs+u fLVukjVX7Pjy3Oo3FsSndo1mXneP1V4o9dGnPUnBPa4vkSnvRZwi1OnwaJig+WAfLlp7 Gy2FUnNqvOjWX75fHoqYGll3FrCpRq2KIWTXf3ioGqw3DP6PClXbfKhdBNDYVWaOEvyi l/jbZaLSYzNs7c/V4DGKQGrvjnzo4AM+jQaUBjqidaacabGYAZ2AI6ukX5A2Q7jA+ivO oCidySTYnDR4y4xJTUJ/fA8EpGB9rn24OhtzdZd2592lS8GoLbfxxOMaB/s2QtOMcDdc BeVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lAXTmzhYARBSKiQsLTBEnk3PfPToIF/bhZyjIGR9a9E=; b=Ht/QWUxxHDDrRifH+5Ii7EUlD9JbDwP45xy4th4dn95qxGIHCuIO0nntC+MXpQhY15 pJ6hAGryvXmytm4Aq0oaG940WQQOzA2BYtmTLWXrxgDlUgUqq2hJ5ylwCLmGNl224Oca 0FiHu92giPtaGECkTGXRdgqsoKF3wYAebM6xi7gUJFQ80Hl0A3Kfd4vdYmKlEVycrVK1 O8EFFq5EzYjDy5j2qBWIJa62Axn/xjFvIogklPpI1+sSw2FDP8+njJ5eaFaQM0KAix77 pOPvN7joikiKyrxA4MlWwEdveMrjLN4CpTovazB/RkQZZtdIZUKP2Vshr6oxbyuZkZM2 x/7g==
X-Gm-Message-State: AFeK/H0Im2oaYVHSdISFEyaTSXJIUj5Q1DL6nJwKvy6iGmDDkUZKHAwdcm90zLdeOH6OWUIwoxXLoJJW66KivoRzKcJf+n8ZNQF3d7sebSXf85FypGIXTBaejFLOSMx0Zbgq88vCecuANCK+O1Q=
X-Received: by 10.55.40.138 with SMTP id o10mr2310521qko.211.1490963776963; Fri, 31 Mar 2017 05:36:16 -0700 (PDT)
X-Received: by 10.55.40.138 with SMTP id o10mr2310501qko.211.1490963776730; Fri, 31 Mar 2017 05:36:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.18.200 with HTTP; Fri, 31 Mar 2017 05:36:16 -0700 (PDT)
In-Reply-To: 
References:  <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> 
From: David Farmer 
Date: Fri, 31 Mar 2017 07:36:16 -0500
Message-ID: 
Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02
To: Erik Kline 
Cc: Alexandre Petrescu , IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary=001a1142e3ac492f43054c060ef3
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 12:36:22 -0000

--001a1142e3ac492f43054c060ef3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I would say "might be" or "can be" orthogonal;  in my opinion, it would be
unfortunate and kind of pointless for a network to provide a /64 with PIO-X
and then only offer a /64 prefix through DHCPv6-PD, and in my opinion this
would be over-lapping, and not orthogonal.  However, if a network provided
a /64 via PIO-X and offered a /60, /56, or larger, prefix via DHCPv6-PD
that would make a lot of sense to me and would be orthogonal.

A question; would it be valid for a network offer a /64 via PIO-X and then
offer the /56 encompassing the /64 via DHCPv6-PD, I think it would be good
to cover this case, stating if it is valid or not, in any discussion of
concurrent use of PIO-X with DHCPv6-PD. I can see where some would think
it's a valid case, and others would not, clearly stating it's one way or
the other seems like a good idea in my opinion.

On Thu, Mar 30, 2017 at 6:18 PM, Erik Kline  wrote:

> I failed to explain myself at the mic, but I am thinking I need to state
> in the document is the following:
>
>     PIO-X and DHCPv6 PD are orthogonal
>
> A network can serve a client a PIO-X *and* simultaneously answer any PD
> requests from the same client.  They are not mutually exclusive nor are
> they redundant.
>
> In the model we tried to describe in the applicability statement, the
> client has attached to the network, issued a vanilla RS, and the router
> (perhaps doing PD on the client's behalf, or radius/diameter, or whatever=
)
> has selected to send the client a PIO.  The extra bit just tells the clie=
nt
> that the PIO is not going to be given to anyone else (subject to various
> lifetimes, etc).
>
> If the client doesn't understand the X flag then it can still process the
> PIO according to its existing code.  That's all.  No conflict with PD,
> really.
>
> On 30 March 2017 at 10:48, Alexandre Petrescu <
> alexandre.petrescu@gmail.com> wrote:
>
>> Hi, authors of PIO-X,
>>
>> My comment on the microphone:
>>
>> This is an earlier draft I co-authored that uses RS/RA messages to do
>> Prefix Delegation.
>>
>> draft-kaiser-nd-pd-02
>>
>> https://tools.ietf.org/html/draft-kaiser-nd-pd-02
>>
>>
>> I can resurrect it if necessary.
>>
>> Alex
>>
>> Le 28/03/2017 =C3=A0 11:57, Alexandre Petrescu a =C3=A9crit :
>>
>> In addition to asking how is this draft helping with DHCPv6 Prefix
>> Delegation,
>>
>> I suggest addition of the following references.
>>
>> Where draft-pioxfolks-6man-pio-exclusive-bit-01 says:
>> >    There are several initiatives that propose network side practices
>> >    that provide customer isolation, enhanced operational scalability,
>> >    power efficiency, security and other benefits in IPv6 network
>> >    deployments.  Some of these involve isolating a host (or RA accepti=
ng
>> >    client node) so that the host is the only node to receive a specifi=
c
>> >    prefix, including
>> >
>> >    o  DHCPv6 Prefix Delegation to hosts (> >       draft-templin-v6ops-pdhost>), and
>> >
>> >    o  advertising a unique prefix per host via unique RAs.
>> >       (> refix-
>> >       per-host>).
>>
>> it makes sense to add:
>>
>>     o  Prefix Delegation extensions to ND protocol have been introduced
>>        in , >        option-00> and , and
>>        probably earlier.
>>
>> Alex
>>
>> Le 04/03/2017 =C3=A0 06:31, Alexandre Petrescu a =C3=A9crit :
>> > I do not oppose a slot presenting PIO-X if time allows.
>> >
>> > However, as I understand it, PIO-X has a single goal - that to
>> > accomodate 64share.
>> >
>> > I wonder whether PIO-X could work with DHCPv6-PD?  Would PIO-X help
>> > DHCPv6-PD deployment?
>> >
>> > This is what I am going to ask at the mic.
>> >
>> > Alex
>> >
>> >
>> >
>> > Le 01/03/2017 =C3=A0 11:27, Erik Kline a =C3=A9crit :
>> >> Ole,
>> >>
>> >> It's on me to get a -02 of PIO-X written and uploaded.  Might it be
>> >> possible to get 5 minutes on that?
>> >>
>> >> -ek
>> >>
>> >> On 27 February 2017 at 06:16, > >> > wrote:
>> >>
>> >>     The 6MAN chairs are planning the meeting in Chicago at IETF98.
>> >>
>> >>     If you have a draft you would like to discuss, please send your
>> >>     request for agenda time to the 6man chairs.   Please include in t=
he
>> >>     request, the title of the presentation, file name of the draft, t=
he
>> >>     speaker's name (and email), and how much time you would like.
>> >>
>> >>     We will prioritise drafts that are working group items and drafts
>> >>     that have been actively discussed on the list.
>> >>
>> >>     We expect at least half of each talk=E2=80=99s presentation time =
to be used
>> >>     for open discussion,
>> >>     please plan your presentation accordingly.
>> >>
>> >>     New drafts not discussed on the mailing list prior to the meeting=
,
>> >>     or drafts that do not appear to have support from the working gro=
up
>> >>     are unlikely to get time at the meeting.
>> >>
>> >>     Please have agenda items to us by 2017-03-15.
>> >>
>> >>     Regards,
>> >>
>> >>     Bob & Ole
>> >>
>> >>     ------------------------------------------------------------
>> --------
>> >>     IETF IPv6 working group mailing list
>> >>     ipv6@ietf.org 
>> >>     Administrative Requests: https://www.ietf.org/mailman/l
>> istinfo/ipv6
>> >>     
>> >>     ------------------------------------------------------------
>> --------
>> >>
>> >>
>> >>
>> >>
>> >> --------------------------------------------------------------------
>> >> IETF IPv6 working group mailing list
>> >> ipv6@ietf.org
>> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> >> --------------------------------------------------------------------
>> >>
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> >
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing listipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>


--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--001a1142e3ac492f43054c060ef3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I would say "might be" or "can be" ort=
hogonal; =C2=A0in my opinion, it would be unfortunate and kind of pointless=
 for a network to provide a /64 with PIO-X and then only offer a /64 prefix=
 through DHCPv6-PD, and in my opinion this would be over-lapping, and not o=
rthogonal.=C2=A0 However, if a network provided a /64 via PIO-X and offered=
 a /60, /56, or larger, prefix via DHCPv6-PD that would make a lot of sense=
 to me and would be orthogonal. =C2=A0

    A question; would=
 it be valid for a network offer a /64 via PIO-X and then offer the /56 enc=
ompassing the /64 via DHCPv6-PD, I think it would be good to cover this cas=
e, stating if it is valid or not, in any discussion of concurrent use of PI=
O-X with DHCPv6-PD. I can see where some would think it's a valid case,=
 and others would not, clearly stating it's one way or the other seems =
like a good idea in my opinion.

    On Thu, Mar 30, 2017 at 6:18 PM, Erik Kline <ek@google.com> wrote:
    <=
div dir=3D"ltr">I failed to explain myself at the mic, but I am thinking I =
need to state in the document is the following:

    =C2=A0 =
=C2=A0 PIO-X and DHCPv6 PD are orthogonal

    A networ=
k can serve a client a PIO-X *and* simultaneously answer any PD requests fr=
om the same client.=C2=A0 They are not mutually exclusive nor are they redu=
ndant.

    In the model we tried to describe in the ap=
plicability statement, the client has attached to the network, issued a van=
illa RS, and the router (perhaps doing PD on the client's behalf, or ra=
dius/diameter, or whatever) has selected to send the client a PIO.=C2=A0 Th=
e extra bit just tells the client that the PIO is not going to be given to =
anyone else (subject to various lifetimes, etc).

    I=
f the client doesn't understand the X flag then it can still process th=
e PIO according to its existing code.=C2=A0 That's all.=C2=A0 No confli=
ct with PD, really.

    On 30 March 2017 at 10:48, Alexandre Petrescu <al=
exandre.petrescu@gmail.com> wrote:
    
 =20
   =20
 =20
  
    
    
    Hi, authors of PIO-X,
    
    
    My comment on the
          microphone:
    
    
    This is an earlier draf=
t
          I co-authored that uses RS/RA messages to do Prefix Delegation.
    
    
    draft-kaiser-nd-pd-02
    
    
    https://tool=
s.ietf.org/html/draft-kaiser-nd-pd-02
    
    

    
          I can resurrect it if necessary.
    
        
    
    
    Alex
    
        
    
    
    
    
    Le 28/03/2017 =C3=A0 11:57, Alexandre
      Petrescu a =C3=A9crit=C2=A0:
    
    
    
    
    
     =20
      
    In addition to
          asking how is this draft helping with DHCPv6 Prefix
          Delegation,
    
          
    
          I suggest addition of the following references.
    
          
    
          Where draft-pioxfolks-6man-pio-exclusive-bit-01 says:
    
          >=C2=A0=C2=A0=C2=A0 There are several initiatives that propose=
 network
          side practices
    
          >=C2=A0=C2=A0=C2=A0 that provide customer isolation, enhanced =
operational
          scalability,
    
          >=C2=A0=C2=A0=C2=A0 power efficiency, security and other benef=
its in IPv6
          network
    
          >=C2=A0=C2=A0=C2=A0 deployments.=C2=A0 Some of these involve i=
solating a host
          (or RA accepting
    
          >=C2=A0=C2=A0=C2=A0 client node) so that the host is the only =
node to
          receive a specific
    
          >=C2=A0=C2=A0=C2=A0 prefix, including
    
          > 
    
          >=C2=A0=C2=A0=C2=A0 o=C2=A0 DHCPv6 Prefix Delegation to hosts =
(<https://too=
ls.ietf.org/html/
    
          >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-templin-v6ops-pdho=
st>), and
    
          > 
    
          >=C2=A0=C2=A0=C2=A0 o=C2=A0 advertising a unique prefix per ho=
st via unique
          RAs.
    
          >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (<https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-=

    
          >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 per-host>).
    
          
    
          it makes sense to add:
    
          
    
          =C2=A0=C2=A0=C2=A0 o=C2=A0 Prefix Delegation extensions to ND pro=
tocol have been
          introduced 
    
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in <draft-kaiser-nd-pd-02=
>,
          <draft-lutchann-ipv6-delegate-
    
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 option-00> and
          <draft-haberman-ipngwg-auto-prefix-02>, and 
    
          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 probably earlier.
    
          
    
          Alex
    
          
    
          Le 04/03/2017 =C3=A0 06:31, Alexandre Petrescu a =C3=A9crit :
    
          > I do not oppose a slot presenting PIO-X if time allows.
    
          > 
    
          > However, as I understand it, PIO-X has a single goal -
          that to
    
          > accomodate 64share.
    
          > 
    
          > I wonder whether PIO-X could work with DHCPv6-PD?=C2=A0 Woul=
d
          PIO-X help
    
          > DHCPv6-PD deployment?
    
          > 
    
          > This is what I am going to ask at the mic.
    
          > 
    
          > Alex
    
          > 
    
          > 
    
          > 
    
          > Le 01/03/2017 =C3=A0 11:27, Erik Kline a =C3=A9crit :
    
          >> Ole,
    
          >>
    
          >> It's on me to get a -02 of PIO-X written and
          uploaded.=C2=A0 Might it be
    
          >> possible to get 5 minutes on that?
    
          >>
    
          >> -ek
    
          >>
    
          >> On 27 February 2017 at 06:16, <otroan@employees.org
    
          >> <mailto:otroan@employees.org>>
          wrote:
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 The 6MAN chairs are planning the=
 meeting in
          Chicago at IETF98.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 If you have a draft you would li=
ke to discuss,
          please send your
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 request for agenda time to the 6=
man chairs.=C2=A0=C2=A0
          Please include in the
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 request, the title of the presen=
tation, file name
          of the draft, the
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 speaker's name (and email), =
and how much time you
          would like.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 We will prioritise drafts that a=
re working group
          items and drafts
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 that have been actively discusse=
d on the list.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 We expect at least half of each =
talk=E2=80=99s
          presentation time to be used
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 for open discussion,
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 please plan your presentation ac=
cordingly.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 New drafts not discussed on the =
mailing list
          prior to the meeting,
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 or drafts that do not appear to =
have support from
          the working group
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 are unlikely to get time at the =
meeting.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 Please have agenda items to us b=
y 2017-03-15.
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 Regards,
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 Bob & Ole
    
          >>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0
          ------------------------------------------------------------=
--------
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 IETF IPv6 working group mailing =
list
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 ipv6@ietf.org <mailto:ipv6@ietf.org>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 Administrative Requests: https://w=
ww.ietf.org/mailman/listinfo/ipv6
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0 <https://www.ietf.org/mailman/<=
wbr>listinfo/ipv6>
    
          >>=C2=A0=C2=A0=C2=A0=C2=A0
          ------------------------------------------------------------=
--------
    
          >>
    
          >>
    
          >>
    
          >>
    
          >>
          ------------------------------------------------------------=
--------
    
          >> IETF IPv6 working group mailing list
    
          >> ipv6@=
ietf.org
    
          >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    
          >>
          ------------------------------------------------------------=
--------
    
          >>
    
          > 
    
          >
          ------------------------------------------------------------=
--------
    
          > IETF IPv6 working group mailing list
    
          > ipv6@ietf=
.org
    
          > Administrative Requests: https://www.ietf.org/mailman/lis=
tinfo/ipv6
    
          >
          ------------------------------------------------------------=
--------
    
          > 
    
        
    
      
    
      
    
      
    
      
    
      
    -----------------------------------------------------------=
---------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv=
6
-----------------------------------------------------------------=
---

    
    
    
    
    
  
    


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


    

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




    -- 
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
    David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0=C2=A0 Em=
ail:farmer@umn.edu
    Networking & Telecommunication Services
    Of=
fice of Information Technology
    University of Minnesota=C2=A0=C2=A0 
    2=
218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
    Min=
neapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
    =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
    

    

--001a1142e3ac492f43054c060ef3--


From nobody Fri Mar 31 06:07:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D115B1294BD for ; Fri, 31 Mar 2017 06:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 UwEf0Gc6nXk9 for ; Fri, 31 Mar 2017 06:07:00 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829A9129407 for ; Fri, 31 Mar 2017 06:07:00 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3F017A4; Fri, 31 Mar 2017 15:06:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1490965618; bh=OHiYpMXbD0gD32tz8Sgfe2XrF7AolSjsQw0Smd1SYkk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=u95imGYywN+2sGzHAcILyF7qWiJn1JonVgqpGk1x++jhnzsAkMKnqpV1pgkEAsK9t KkFegaasffCjj2tzCpPrRPkBEpjYUF3J6wwUz2ra0FnQkl2wlVAPUTwATi6i84BnCO WvuhcB3FmezcTfIHYvEzQOTguVrHrv0e8bnMPkk8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3AB3CA3; Fri, 31 Mar 2017 15:06:58 +0200 (CEST)
Date: Fri, 31 Mar 2017 15:06:58 +0200 (CEST)
From: Mikael Abrahamsson 
To: David Farmer 
cc: IETF IPv6 Mailing List 
Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02
In-Reply-To: 
Message-ID: 
References:  <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.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; charset=US-ASCII; format=flowed
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 13:07:03 -0000

On Fri, 31 Mar 2017, David Farmer wrote:

> A question; would it be valid for a network offer a /64 via PIO-X and 
> then offer the /56 encompassing the /64 via DHCPv6-PD, I think it would 
> be good to cover this case, stating if it is valid or not, in any 
> discussion of concurrent use of PIO-X with DHCPv6-PD. I can see where 
> some would think it's a valid case, and others would not, clearly 
> stating it's one way or the other seems like a good idea in my opinion.

Having a /64 WAN prefix which is the first /64 in a PD /56 is a perfectly 
valid deployment case. That's the whole point of RFC6603 "PD exclude".

"The prefix exclusion mechanism is targeted at deployments where
    DHCPv6-based prefix delegation is used, but a single aggregated
    route/prefix has to represent one customer, instead of using one
    prefix for the link between the delegating router and the requesting
    router and another prefix for the customer network.  The mechanism
    defined in this specification allows a delegating router to use a
    prefix out of the delegated prefix set on the link through which it
    exchanges DHCPv6 messages with the requesting router, and is intended
    for use in networks where each requesting router is on its own
    layer-2 domain."

Using PIO-X on the /64 WAN RA is optional, but would be perfectly suited 
for this deployment scenario if all other aspects are fulfilled.

I don't see any argument why it would not valid, what would the arguments 
be for it not being valid use-case?

The only thing I can imagine is that when using PIO-X for the /64, you're 
basically anyway delegating the entire /56 to the device so why not just 
use the unnumbered model (TR-177 and RFC7084 WAA-7).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Fri Mar 31 07:11:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABB51294C4; Fri, 31 Mar 2017 07:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3vyqiAFLmcsP; Fri, 31 Mar 2017 07:11:47 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9C1120326; Fri, 31 Mar 2017 07:11:47 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id z13so40406491iof.2; Fri, 31 Mar 2017 07:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=isEinDZ38WgcjmpNWTQ4PfYWjZqcWehhG/DenmXpiAo=; b=OGSIjlCAx/OjgRJXpISH1EpwT//PF1SfwRtQ6U97zd0C/nVcpBQNyrgehGVO5kdO83 CBePvRHHpeYZGCcjgBnj6gwy3cQ9SXZvrRWYTDGLtBGN37F6aFL9idZOfvVgE5OOFm2L aZxkimlTIAe1UqbXvkE+gNm0D0Fxq65cw89UbjHhl0iSjqpsUHOLKCcwDYUHg8Oe3c2H r/Eou2WVdFiAO48h2VJPw+DPzYl4RVHxtbCxNrJTV4J5bSFu5uFCEDkXidJahE9plnpN 8+B7e7gY40DuIUnQ+eW/PdhrPtV3iZlJonWIwFt/7fIB1tXGtmaNoM+7DGmBNXJJuI6k R9CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=isEinDZ38WgcjmpNWTQ4PfYWjZqcWehhG/DenmXpiAo=; b=VFvpdFhyUOwZ4kqni8Ol4QRfJttVqxRXEA7ubO4SXhLHPibRtyFSE3RBGRilawCJYa 2LRP6knSUUE69LzPre7vvth3mxXOKUgHilCb7b+95VaJB/FBlsZmcPrZvFq3cDT49/Kb jMk5ZTvfMRPn7z4O8QGWcxaE1eydF/yCqVGdnjpNHEDX92chYYbnDVjbeyG8OU888puT ynWxSUQJ/t1ujZnzepqYJHUWT+6Ue8gYimzwKUOeWy9sNwk8du7BV59i/baj0UHD7FBN pOvSi/tIGK3ZEU9OpT9zT0zTgPskrW5zi8r6Xka+kPH7wu9Mk2O8Lt2agkRjHET3Ofxa Opyw==
X-Gm-Message-State: AFeK/H00BZAn8rSQFiGn9OFP+JFQGn5d6cNs41R1lgjDY2TJErvblWIJ5zM7MjpX6x4aB4eUMKQlqMArGON1vQ==
X-Received: by 10.107.7.29 with SMTP id 29mr3384195ioh.57.1490969506524; Fri, 31 Mar 2017 07:11:46 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 07:11:45 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 07:11:45 -0700 (PDT)
In-Reply-To: <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>
From: Robert Raszuk 
Date: Fri, 31 Mar 2017 09:11:45 -0500
X-Google-Sender-Auth: cEXM4wMcBvEXKRslhp9ltl33Am4
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Brian E Carpenter 
Cc: "Leddy, John" , IETF Discussion , 6man WG , otroan@employees.org,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113ea6f0ced7e1054c0763df
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 14:11:49 -0000

--001a113ea6f0ced7e1054c0763df
Content-Type: text/plain; charset=UTF-8

I do not understand how 2460bis makes it "easier" if proposed change to the
text directly tries to prohibit what is described in a document already
long time back accepted as a 6man working group draft.

That's to the best of my memory an IETF precedent.

Cheers,
R.

On Mar 30, 2017 16:50, "Brian E Carpenter" 
wrote:

On 31/03/2017 10:13, Robert Raszuk wrote:
> What's wrong or what is missing in
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-05
>
> ?

Once we get 2460bis out of the door, we should seriously tackle that
question.
Honestly it's going to be easier then. I perhaps disagree with Ole whether
we
need an Updates: 2460bis but that depends on the details.

    Brian

--001a113ea6f0ced7e1054c0763df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I do not understand how 2460bis makes it "easier&quo=
t; if proposed change to the text directly tries to prohibit what is descri=
bed in a document already long time back accepted as a 6man working group d=
raft.

    That's to the best o=
f my memory an IETF precedent.

    Cheers,
    R.

    On Mar 30, 2017 16:50, "Brian E Ca=
rpenter" <brian.e.ca=
rpenter@gmail.com> wrote:
    On 31/03/2017 10:13, Robert Raszuk wrote=
:
    
> What's wrong or what is missing in
    
> https://tools.ietf.org/htm=
l/draft-ietf-6man-segment-routing-header-05
    
>
    
> ?
    

    

    Once we get 2460bis out of the door, we should seriously tackle that =
question.
    
Honestly it's going to be easier then. I perhaps disagree with Ole whet=
her we
    
need an Updates: 2460bis but that depends on the details.
    

    
=C2=A0 =C2=A0 Brian

    

--001a113ea6f0ced7e1054c0763df--


From nobody Fri Mar 31 07:38:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7D12987B for ; Fri, 31 Mar 2017 07:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level: 
X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 hEEE38YaRcpR for ; Fri, 31 Mar 2017 07:38:49 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C639012422F for ; Fri, 31 Mar 2017 07:38:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1490971126; bh=brGeAz1t9jbFjkk3QmAvM91JX3hpy7RJ+f0qXONjvxg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type; b=bqmFd2yKmXNTGv7WzArJh0tG2cFMG6zAxA2b18uIpf1eWZk7EiCB79s6rADEtsqGl5JqnneUZBlPA5mm/sgo9hjELCOU1FUtscjrpqKh81Nb9BBqTJfSBoklcw+Ok+9xUH0B9pv1N+3lg9vHPGarIEvw0nuCRPUZDS1D7jFQROk=
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0243.outbound.protection.outlook.com [213.199.154.243]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-39-CZFbowWFN0y7SYf_a-hvYQ-1; Fri, 31 Mar 2017 15:38:43 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Fri, 31 Mar 2017 14:38:40 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.009; Fri, 31 Mar 2017 14:38:40 +0000
From: Tim Chown 
To: Brian E Carpenter 
CC: "ipv6@ietf.org" 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGuC10AgAAPeACAAQO2gA==
Date: Fri, 31 Mar 2017 14:38:40 +0000
Message-ID: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3259)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:67c:370:1999:a88e:5bdf:7b5d:1b2f]
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:Dz4Y6B/Cu8s9v3BAX4AaUHFfAVosm5FUwhDOuB6huuW6r8rB8CJviotFHkvlju2pzXAKfQjqS8KiybjoqxtL5oS8ocveDb9/FDUyu5reQuUYG8HS5CPILtqvKGSWx6u/YmcunDzMYQe65QMK5uLwS1UqWcE+Gf/HfWPbPOrQICT3QhhHKhyecOU9ZbsyrNlYLzNmkp4ATcevjMlkkcmwUgz6vyowkaWIm/d+nG7PDraRK6W+0eagNBX42VYdsLkWteCZaK2iCtbKezA07edIEZRBjFAg3EzxPWyy4n6njTOo97RZTn2/ay2Eb0jxEP3ix4QM5iEju3JNdx6iNLUm0g==; 20:APhnWCTNgBTrpj3qbSDJm5zrDh+qPp4NP+v8Zv97P0yapvvl5yC/C8XE2QHOjWFEe2P+IoGP1GlOFFKGAcvAA06cjXXETjIIMMHR3pfZet6/bBf9irUsiq8iCXhRpysHnmfKvvYyANkkO2zGDuiwkIQZWulHn0fYGGziQiTRfaw=
x-ms-office365-filtering-correlation-id: 920ed940-0280-4959-b2f6-08d47843a009
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1140; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; 
x-forefront-prvs: 02638D901B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39450400003)(39400400002)(39850400002)(39410400002)(54164003)(24454002)(377454003)(2900100001)(50226002)(3280700002)(4326008)(106356001)(5250100002)(229853002)(102836003)(189998001)(6116002)(8936002)(53936002)(86362001)(8676002)(81166006)(3660700001)(2906002)(36756003)(6486002)(5660300001)(33656002)(38730400002)(6506006)(6246003)(110136004)(2950100002)(82746002)(7906003)(83716003)(236005)(57306001)(7736002)(6512007)(6916009)(39060400002)(230783001)(54896002)(6306002)(606005)(50986999)(99286003)(53546009)(76176999)(25786009)(74482002)(6436002)(42882006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 14:38:40.8277 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140
X-MC-Unique: CZFbowWFN0y7SYf_a-hvYQ-1
Content-Type: multipart/alternative; boundary="_000_F2FACDFCE7A847D885528E11D7E98345jiscacuk_"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 14:38:53 -0000

--_000_F2FACDFCE7A847D885528E11D7E98345jiscacuk_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

T24gMzEgTWFyIDIwMTcsIGF0IDAwOjA5LCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJw
ZW50ZXJAZ21haWwuY29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+PiB3cm90
ZToNCg0KT24gMzEvMDMvMjAxNyAxMToxMywgSmVuIExpbmtvdmEgd3JvdGU6DQpPbiBXZWQsIE1h
ciAxNSwgMjAxNyBhdCAzOjQ3IEFNLCBTdXJlc2ggS3Jpc2huYW4NCjxzdXJlc2gua3Jpc2huYW5A
ZXJpY3Nzb24uY29tPG1haWx0bzpzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPj4gd3JvdGU6
DQpUaGFua3MgdG8gZXZlcnlvbmUgd2hvIGNvbW1lbnRlZCBkdXJpbmcgdGhlIElFVEYgTGFzdCBD
YWxsIG9mIGRyYWZ0LWlldGYtNm1hbi1yZmMyNDYwYmlzLTA4LiBUaGUgSUVURiBsYXN0IGNhbGwg
ZGlzY3Vzc2lvbiBmb3IgdGhpcyBkcmFmdCB3YXMgbWFpbmx5IGZvY3VzZWQgYXJvdW5kIHRoZSB0
ZXh0IGluIFNlY3Rpb24gNCB0aGF0IGRpc2N1c3NlcyB0aGUgaGFuZGxpbmcgb2YgZXh0ZW5zaW9u
IGhlYWRlcnMuIFRoZSBiaWdnZXN0IGNvbmNlcm4gcmFpc2VkIHdhcyB0aGF0IHRoZSBjdXJyZW50
IHRleHQgaXMgYW1iaWd1b3VzIG9uIHdoZXRoZXIgaGVhZGVyIGluc2VydGlvbiBpcyBhbGxvd2Vk
IG9uIGludGVybWVkaWF0ZSBub2RlcyBvciBub3QuIFRoZXJlIHdlcmUgc29tZSBwZW9wbGUgYXJn
dWluZyB0aGF0IGFuIGV4cGxpY2l0IHByb2hpYml0aW9uIGlzIG5vdCBuZWNlc3NhcnkgYXMgdGhl
IHRleHQgaXMgYWxyZWFkeSBjbGVhciwgd2hpbGUgb3RoZXJzIGJlbGlldmVkIHRoYXQgZXhwbGlj
aXRseSBsaXN0aW5nIHRoZSBwcm9oaWJpdGlvbnMgd2lsbCBtaW5pbWl6ZSBhbnkgbWlzdW5kZXJz
dGFuZGluZ3MgaW4gdGhlIGZ1dHVyZS4gVGhlcmUgd2FzIGFsc28gYSBzbWFsbCBudW1iZXIgb2Yg
cGVvcGxlIHdobyB3YW50ZWQgdG8gZXhwbGljaXRseSBhbGxvdyBoZWFkZXIgaW5zZXJ0aW9uIGFu
ZCBkZXNjcmliZSBob3cgdG8gZG8gaXQsIGJ1dCB0aGlzIHdhcyBjbGVhcmx5IG91dCBvZiBzY29w
ZSBmb3IgdGhpcyBkcmFmdCAoYnV0IG1heSBiZSBpbiBzY29wZSBmb3IgZnV0dXJlIHdvcmsgaW4g
Nm1hbikuIE92ZXJhbGwsIG5vIG9uZSBhcmd1ZWQgYWdhaW5zdCB0aGUgZmFjdCB0aGF0IHRoZSBp
bnRlbnQgb2YgdGhlIHRleHQgaW4gUkZDMjQ2MCB3YXMgdG8gZm9yYmlkIGluc2VydGlvbiBvZiBl
eHRlbnNpb24gaGVhZGVycyBvbiBhbnkgb3RoZXIgbm9kZSBidXQgdGhlIHNvdXJjZSBvZiB0aGUg
cGFja2V0LiAgVGhlIG9ubHkgYXJndW1lbnQgbQ0KYQ0KZGUgYWdhaW5zdCBhZGRpbmcgY2xhcmlm
eWluZyB0ZXh0IHdhcyB0aGF0IHRoZSB0ZXh0IHdhcyBhbHJlYWR5IGNsZWFyLiBHaXZlbiB0aGlz
LCBJIGJlbGlldmUgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIGFkZCBleHBsaWNpdCB0ZXh0IGFib3V0
IGhlYWRlciBpbnNlcnRpb24gaW50byB0aGUgZHJhZnQgYmVmb3JlIGl0IHByb2dyZXNzZXMgZnVy
dGhlci4gSSBoYXZlIGRpc2N1c3NlZCB0aGlzIHdpdGggdGhlIGVkaXRvciBhbmQgdGhlIGRvY3Vt
ZW50IHNoZXBoZXJkIGFuZCB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0
IGNoYW5nZS4NCg0KT0xEIChmcm9tIC0wOCk6DQoNClRoZSBpbnNlcnRpb24gb2YgRXh0ZW5zaW9u
IEhlYWRlcnMgYnkgYW55IG5vZGUgb3RoZXIgdGhhbiB0aGUgc291cmNlDQpvZiB0aGUgcGFja2V0
IGNhdXNlcyBzZXJpb3VzIHByb2JsZW1zLiAgVHdvIGV4YW1wbGVzIGluY2x1ZGUgYnJlYWtpbmcN
CnRoZSBpbnRlZ3JpdHkgY2hlY2tzIHByb3ZpZGVkIGJ5IHRoZSBBdXRoZW50aWNhdGlvbiBIZWFk
ZXIgSW50ZWdyaXR5DQpbUkZDNDMwMl0sIGFuZCBicmVha2luZyBQYXRoIE1UVSBEaXNjb3Zlcnkg
d2hpY2ggY2FuIHJlc3VsdCBpbiBJQ01QDQplcnJvciBtZXNzYWdlcyBiZWluZyBzZW50IHRvIHRo
ZSBzb3VyY2Ugb2YgdGhlIHBhY2tldCB0aGF0IGRpZCBub3QNCmluc2VydCB0aGUgaGVhZGVyLCBy
YXRoZXIgdGhhbiB0aGUgbm9kZSB0aGF0IGluc2VydGVkIHRoZSBoZWFkZXIuDQoNCk9uZSBhcHBy
b2FjaCB0byBhdm9pZCB0aGVzZSBwcm9ibGVtcyBpcyB0byBlbmNhcHN1bGF0ZSB0aGUgcGFja2V0
DQp1c2luZyBhbm90aGVyIElQdjYgaGVhZGVyIGFuZCBpbmNsdWRpbmcgdGhlIGFkZGl0aW9uYWwg
ZXh0ZW5zaW9uDQpoZWFkZXIgYWZ0ZXIgdGhlIGZpcnN0IElQdjYgaGVhZGVyLCBmb3IgZXhhbXBs
ZSwgYXMgZGVmaW5lZCBpbg0KW1JGQzI0NzNdDQoNCldpdGggb25lIGV4Y2VwdGlvbiwgZXh0ZW5z
aW9uIGhlYWRlcnMgYXJlIG5vdCBwcm9jZXNzZWQgYnkgYW55IG5vZGUNCmFsb25nIGEgcGFja2V0
J3MgZGVsaXZlcnkgcGF0aCwgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvcg0K
ZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbiB0aGUgY2FzZSBvZiBtdWx0aWNhc3QpIGlkZW50
aWZpZWQgaW4gdGhlDQpEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mIHRoZSBJUHY2IGhlYWRl
ci4uLg0KDQpORVc6DQoNCldpdGggb25lIGV4Y2VwdGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJl
IG5vdCBleGFtaW5lZCwgcHJvY2Vzc2VkLA0KaW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5v
ZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLA0KdW50aWwgdGhlIHBhY2tldCByZWFj
aGVzIHRoZSBub2RlIChvciBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluDQp0aGUgY2FzZSBv
ZiBtdWx0aWNhc3QpIGlkZW50aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQg
b2YNCnRoZSBJUHY2IGhlYWRlci4uLg0KDQpJIGhhdmUgc29tZSBjb25jZXJucyB3aXRoIGhvdyB0
aGF0IHNlbnRlbmNlIEFORCB0aGUgZm9sbG93aW5nIG5vdGUNCmNvbWVzIHRvZ2V0aGVyOg0KDQoi
ICBXaXRoIG9uZSBleGNlcHRpb24sIGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBub3QgZXhhbWluZWQs
IHByb2Nlc3NlZCwNCiAgaW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUgYWxvbmcgYSBw
YWNrZXQncyBkZWxpdmVyeSBwYXRoLA0KICB1bnRpbCB0aGUgcGFja2V0IHJlYWNoZXMgdGhlIG5v
ZGUgKG9yIGVhY2ggb2YgdGhlIHNldCBvZiBub2RlcywgaW4NCiAgdGhlIGNhc2Ugb2YgbXVsdGlj
YXN0KSBpZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mDQogIHRo
ZSBJUHY2IGhlYWRlci4gIE5vdGU6IElmIGFuIGludGVybWVkaWF0ZSBmb3J3YXJkaW5nIG5vZGUg
ZXhhbWluZXMNCiAgYW4gZXh0ZW5zaW9uIGhlYWRlciBmb3IgYW55IHJlYXNvbiwgaXQgbXVzdCBk
byBzbyBpbiBhY2NvcmRhbmNlIHdpdGgNCiAgdGhlIHByb3Zpc2lvbnMgb2YgW1JGQzcwNDVdLiAg
Ig0KDQpJJ20gYWZyYWlkIHRoYXQgdGhlIGxhY2sgb2YgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBz
dHJpa2VzIGJhY2suLg0KDQpFeGFjdGx5IHRoZSBvcHBvc2l0ZSwgSU1ITy4gSSB0aGluayBpdCdz
IG11Y2ggYmV0dGVyIGxpa2UgdGhpcyB0aGFuIGl0DQp3b3VsZCBiZSB1bmRlciBSRkMyMTE5IChh
bHRob3VnaCBpbiBmYWN0IHRoYXQgZG9lc24ndCBjaGFuZ2UgdGhlDQpFbmdsaXNoIG1lYW5pbmcg
b2YgJ211c3QnKS4gVGhlICJOb3RlOiIgZGVzY3JpYmVzIGEgc2l0dWF0aW9uIHdoZXJlDQptaWRk
bGVib3hlcyBhcmUgYWN0dWFsbHkgYnJlYWtpbmcgdGhlIHJ1bGUuIFdlIGhhZCB0aGF0IGZpZ2h0
IGJlZm9yZQ0KUkZDNzA0NS4NCg0KSW5kZWVkLiBUaGUgUkZDNzA0NSBleGNlcHRpb24gYXBwbGll
cyBzcGVjaWZpY2FsbHkgdG8gKmV4YW1pbmluZyogaGVhZGVycywgd2l0aCB0aGUgY29tbW9uIHVz
ZSBjYXNlIGJlaW5nIGZpcmV3YWxsaW5nLg0KDQpDaGFuZ2luZyB0aGUgUkZDNzA0NSBleGNlcHRp
b24gdGV4dCB0byBjbGFyaWZ5IHRoaXMgaW4gMjQ2MGJpcyB3YXMgcHJvcG9zZWQsIGJ1dCBpdCB3
YXNu4oCZdCB0YWtlbiBmb3J3YXJkLg0KDQpUaW0NCg0KICAgIEJyaWFuDQoNCg0KSWYgJ2FyZSBu
b3QgZXhhbWluZWQiIGlzIHRvIGJlIGludGVycHJldGVkIGFzIFJGQzIxMTkgJ01VU1QgTk9UJywN
CnRoZW4gdGhlIGZvbGxvd2luZyBub3RlIGNvbmZsaWN0cyB3aXRoIHRoYXQgc3RhdGVtZW50LiAn
QSBub2RlIE1VU1QNCk5PVCBleGFtaW5lIEVIcw0KYnV0IGlmIGl0IGRvZXMgaXQgbXVzdCBkbyBp
dCBhcyBwZXIgUkZDNzA0NScgLSBpdCBpcyBleHRyZW1lbHkgY29udHJvdmVyc2lhbC4NCg0KSWYg
JydhcmUgbm90IGV4YW1pbmVkIiBpcyB0byBiZSByZWFkIGFzIFJGQzIxMTkgJ1NIT1VMRCBOT1Qn
IHRoZW4gSQ0KaGF2ZSBhIHZlcnkgZ29vZCBuZXdzIGZvcg0KdGhvc2Ugd2hvIHdvdWxkIHN0aWxs
IGxpa2UgdG8gaW5zZXJ0L2RlbGV0ZSBFSHM6IHRoZXkgY2FuIGRvIGl0ICBhcw0KbG9uZyBhcyAg
dGhleSBoYXZlDQoidmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgd2hl
biB0aGUgcGFydGljdWxhcg0KYmVoYXZpb3IgaXMgYWNjZXB0YWJsZSBvciBldmVuIHVzZWZ1bCwg
YnV0IHRoZSBmdWxsDQogIGltcGxpY2F0aW9ucyBzaG91bGQgYmUgdW5kZXJzdG9vZCBhbmQgdGhl
IGNhc2UgY2FyZWZ1bGx5IHdlaWdoZWQNCiAgYmVmb3JlIGltcGxlbWVudGluZyBhbnkgYmVoYXZp
b3IgZGVzY3JpYmVkIHdpdGggdGhpcyBsYWJlbC4iLg0KQnV0IGZyb20gdG9kYXkncyBwcmVzZW50
YXRpb24gSSd2ZSBnb3QgYW4gaW1wcmVzc2lvbiB0aGF0IHRoZQ0KaW50ZW50aW9uIG9mIHRoaXMg
dGV4dCB3YXMgYWN0dWFsbHkgdG8gcHJvaGliaXQgRUggaW5zZXJ0aW9uDQoodGhlIHNpbGRlcyBz
YXkgJ25vIG9uZSBhcmd1ZWQgYWdhaW5zdCB0aGUgZmFjdCB0aGF0IHRoZSBpbnRlbnQgb2YgdGhl
DQp0ZXh0IGluIFJGQzI0NjANCndhcyB0byBmb3JiaWQgaW5zZXJ0aW9uIG9mIGV4dGVuc2lvbiBo
ZWFkZXJzIG9uIGFueSBvdGhlciBub2RlIGJ1dCB0aGUgc291cmNlDQpvZiB0aGUgcGFja2V0Liku
DQoNClNvIHRvIHN1bW1hcml6ZTogdGhlIHByb3Bvc2VkIHRleHQgZWl0aGVyIGV4cGxpY2l0bHkg
cHJvaGliaXRzIHRoZQ0KZXhhbWluYXRpb24gKGFuZCB0aGVuIGl0IGNvbnRyYWRpY3RzIHRoZSBu
ZXh0IHNlbnRlbmNlIGFuZCB3ZSBuZWVkIHRvDQpkbyBzbXRoIHdpdGggdGhlIG5vdGUgYW5kIFJG
QzcwNDUpIE9SIGl0IGFsbG93cyBFSCBpbnNlcnRpb24gLSBpdA0KZGVwZW5kcyBob3cgdGhlIHRl
eHQgaXMgaW50ZXJwcmV0ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91
cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1p
bmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo=
--_000_F2FACDFCE7A847D885528E11D7E98345jiscacuk_
Content-Type: text/html; charset=UTF-8
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAzMSBNYXIgMjAxNywgYXQgMDA6
MDksIEJyaWFuIEUgQ2FycGVudGVyICZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW4uZS5jYXJwZW50
ZXJAZ21haWwuY29tIiBjbGFzcz0iIj5icmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208L2E+Jmd0
OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8
ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp
emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg
Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0
bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp
bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk9uDQogMzEvMDMvMjAxNyAxMToxMywgSmVuIExp
bmtvdmEgd3JvdGU6PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u
dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt
YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6
IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6
IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl
OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg
LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo
OiAwcHg7IiBjbGFzcz0iIj4NCk9uIFdlZCwgTWFyIDE1LCAyMDE3IGF0IDM6NDcgQU0sIFN1cmVz
aCBLcmlzaG5hbjxiciBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86c3VyZXNoLmtyaXNo
bmFuQGVyaWNzc29uLmNvbSIgY2xhc3M9IiI+c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTwv
YT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz
PSIiPlRoYW5rcyB0byBldmVyeW9uZSB3aG8gY29tbWVudGVkIGR1cmluZyB0aGUgSUVURiBMYXN0
IENhbGwgb2YgZHJhZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMtMDguIFRoZSBJRVRGIGxhc3QgY2Fs
bCBkaXNjdXNzaW9uIGZvciB0aGlzIGRyYWZ0IHdhcyBtYWlubHkgZm9jdXNlZCBhcm91bmQgdGhl
IHRleHQgaW4gU2VjdGlvbiA0IHRoYXQgZGlzY3Vzc2VzIHRoZSBoYW5kbGluZyBvZiBleHRlbnNp
b24NCiBoZWFkZXJzLiBUaGUgYmlnZ2VzdCBjb25jZXJuIHJhaXNlZCB3YXMgdGhhdCB0aGUgY3Vy
cmVudCB0ZXh0IGlzIGFtYmlndW91cyBvbiB3aGV0aGVyIGhlYWRlciBpbnNlcnRpb24gaXMgYWxs
b3dlZCBvbiBpbnRlcm1lZGlhdGUgbm9kZXMgb3Igbm90LiBUaGVyZSB3ZXJlIHNvbWUgcGVvcGxl
IGFyZ3VpbmcgdGhhdCBhbiBleHBsaWNpdCBwcm9oaWJpdGlvbiBpcyBub3QgbmVjZXNzYXJ5IGFz
IHRoZSB0ZXh0IGlzIGFscmVhZHkgY2xlYXIsIHdoaWxlDQogb3RoZXJzIGJlbGlldmVkIHRoYXQg
ZXhwbGljaXRseSBsaXN0aW5nIHRoZSBwcm9oaWJpdGlvbnMgd2lsbCBtaW5pbWl6ZSBhbnkgbWlz
dW5kZXJzdGFuZGluZ3MgaW4gdGhlIGZ1dHVyZS4gVGhlcmUgd2FzIGFsc28gYSBzbWFsbCBudW1i
ZXIgb2YgcGVvcGxlIHdobyB3YW50ZWQgdG8gZXhwbGljaXRseSBhbGxvdyBoZWFkZXIgaW5zZXJ0
aW9uIGFuZCBkZXNjcmliZSBob3cgdG8gZG8gaXQsIGJ1dCB0aGlzIHdhcyBjbGVhcmx5IG91dCBv
ZiBzY29wZQ0KIGZvciB0aGlzIGRyYWZ0IChidXQgbWF5IGJlIGluIHNjb3BlIGZvciBmdXR1cmUg
d29yayBpbiA2bWFuKS4gT3ZlcmFsbCwgbm8gb25lIGFyZ3VlZCBhZ2FpbnN0IHRoZSBmYWN0IHRo
YXQgdGhlIGludGVudCBvZiB0aGUgdGV4dCBpbiBSRkMyNDYwIHdhcyB0byBmb3JiaWQgaW5zZXJ0
aW9uIG9mIGV4dGVuc2lvbiBoZWFkZXJzIG9uIGFueSBvdGhlciBub2RlIGJ1dCB0aGUgc291cmNl
IG9mIHRoZSBwYWNrZXQuICZuYnNwO1RoZSBvbmx5IGFyZ3VtZW50IG08YnIgY2xhc3M9IiI+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl
bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog
bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5hPC9zcGFuPjxiciBz
dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7
IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0i
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt
YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl
ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0
LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg
d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0
OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCmRlIGFn
YWluc3QgYWRkaW5nIGNsYXJpZnlpbmcgdGV4dCB3YXMgdGhhdCB0aGUgdGV4dCB3YXMgYWxyZWFk
eSBjbGVhci4gR2l2ZW4gdGhpcywgSSBiZWxpZXZlIHRoZXJlIGlzIGNvbnNlbnN1cyB0byBhZGQg
ZXhwbGljaXQgdGV4dCBhYm91dCBoZWFkZXIgaW5zZXJ0aW9uIGludG8gdGhlIGRyYWZ0IGJlZm9y
ZSBpdCBwcm9ncmVzc2VzIGZ1cnRoZXIuIEkgaGF2ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIHRoZSBl
ZGl0b3IgYW5kIHRoZSBkb2N1bWVudCBzaGVwaGVyZA0KIGFuZCB3b3VsZCBsaWtlIHRvIHByb3Bv
c2UgdGhlIGZvbGxvd2luZyB0ZXh0IGNoYW5nZS48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpPTEQgKGZyb20gLTA4KTo8YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgaW5zZXJ0aW9uIG9mIEV4dGVuc2lvbiBIZWFkZXJz
IGJ5IGFueSBub2RlIG90aGVyIHRoYW4gdGhlIHNvdXJjZTxiciBjbGFzcz0iIj4NCm9mIHRoZSBw
YWNrZXQgY2F1c2VzIHNlcmlvdXMgcHJvYmxlbXMuICZuYnNwO1R3byBleGFtcGxlcyBpbmNsdWRl
IGJyZWFraW5nPGJyIGNsYXNzPSIiPg0KdGhlIGludGVncml0eSBjaGVja3MgcHJvdmlkZWQgYnkg
dGhlIEF1dGhlbnRpY2F0aW9uIEhlYWRlciBJbnRlZ3JpdHk8YnIgY2xhc3M9IiI+DQpbUkZDNDMw
Ml0sIGFuZCBicmVha2luZyBQYXRoIE1UVSBEaXNjb3Zlcnkgd2hpY2ggY2FuIHJlc3VsdCBpbiBJ
Q01QPGJyIGNsYXNzPSIiPg0KZXJyb3IgbWVzc2FnZXMgYmVpbmcgc2VudCB0byB0aGUgc291cmNl
IG9mIHRoZSBwYWNrZXQgdGhhdCBkaWQgbm90PGJyIGNsYXNzPSIiPg0KaW5zZXJ0IHRoZSBoZWFk
ZXIsIHJhdGhlciB0aGFuIHRoZSBub2RlIHRoYXQgaW5zZXJ0ZWQgdGhlIGhlYWRlci48YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbmUgYXBwcm9hY2ggdG8gYXZvaWQgdGhlc2UgcHJvYmxl
bXMgaXMgdG8gZW5jYXBzdWxhdGUgdGhlIHBhY2tldDxiciBjbGFzcz0iIj4NCnVzaW5nIGFub3Ro
ZXIgSVB2NiBoZWFkZXIgYW5kIGluY2x1ZGluZyB0aGUgYWRkaXRpb25hbCBleHRlbnNpb248YnIg
Y2xhc3M9IiI+DQpoZWFkZXIgYWZ0ZXIgdGhlIGZpcnN0IElQdjYgaGVhZGVyLCBmb3IgZXhhbXBs
ZSwgYXMgZGVmaW5lZCBpbjxiciBjbGFzcz0iIj4NCltSRkMyNDczXTxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NCldpdGggb25lIGV4Y2VwdGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5v
dCBwcm9jZXNzZWQgYnkgYW55IG5vZGU8YnIgY2xhc3M9IiI+DQphbG9uZyBhIHBhY2tldCdzIGRl
bGl2ZXJ5IHBhdGgsIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3I8YnIgY2xh
c3M9IiI+DQplYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluIHRoZSBjYXNlIG9mIG11bHRpY2Fz
dCkgaWRlbnRpZmllZCBpbiB0aGU8YnIgY2xhc3M9IiI+DQpEZXN0aW5hdGlvbiBBZGRyZXNzIGZp
ZWxkIG9mIHRoZSBJUHY2IGhlYWRlci4uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5F
Vzo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpXaXRoIG9uZSBleGNlcHRpb24sIGV4dGVu
c2lvbiBoZWFkZXJzIGFyZSBub3QgZXhhbWluZWQsIHByb2Nlc3NlZCw8YnIgY2xhc3M9IiI+DQpp
bnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5
IHBhdGgsPGJyIGNsYXNzPSIiPg0KdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChv
ciBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluPGJyIGNsYXNzPSIiPg0KdGhlIGNhc2Ugb2Yg
bXVsdGljYXN0KSBpZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9m
PGJyIGNsYXNzPSIiPg0KdGhlIElQdjYgaGVhZGVyLi4uPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1
b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSBoYXZlIHNvbWUgY29uY2VybnMgd2l0aCBob3cgdGhhdCBz
ZW50ZW5jZSBBTkQgdGhlIGZvbGxvd2luZyBub3RlPGJyIGNsYXNzPSIiPg0KY29tZXMgdG9nZXRo
ZXI6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJnF1b3Q7ICZuYnNwO1dpdGggb25lIGV4
Y2VwdGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCwgcHJvY2Vzc2VkLDxi
ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2luc2VydGVkLCBvciBkZWxldGVkIGJ5IGFueSBub2Rl
IGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz
cDt1bnRpbCB0aGUgcGFja2V0IHJlYWNoZXMgdGhlIG5vZGUgKG9yIGVhY2ggb2YgdGhlIHNldCBv
ZiBub2RlcywgaW48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDt0aGUgY2FzZSBvZiBtdWx0aWNh
c3QpIGlkZW50aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2Y8YnIgY2xh
c3M9IiI+DQombmJzcDsmbmJzcDt0aGUgSVB2NiBoZWFkZXIuICZuYnNwO05vdGU6IElmIGFuIGlu
dGVybWVkaWF0ZSBmb3J3YXJkaW5nIG5vZGUgZXhhbWluZXM8YnIgY2xhc3M9IiI+DQombmJzcDsm
bmJzcDthbiBleHRlbnNpb24gaGVhZGVyIGZvciBhbnkgcmVhc29uLCBpdCBtdXN0IGRvIHNvIGlu
IGFjY29yZGFuY2Ugd2l0aDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3RoZSBwcm92aXNpb25z
IG9mIFtSRkM3MDQ1XS4gJm5ic3A7JnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
SSdtIGFmcmFpZCB0aGF0IHRoZSBsYWNrIG9mIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugc3RyaWtl
cyBiYWNrLi48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog
YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi
IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6
ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm
b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRv
OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v
bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7
IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu
bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+RXhhY3RseQ0KIHRoZSBvcHBvc2l0ZSwgSU1ITy4g
SSB0aGluayBpdCdzIG11Y2ggYmV0dGVyIGxpa2UgdGhpcyB0aGFuIGl0PC9zcGFuPjxiciBzdHls
ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu
b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj
YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y
cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy
YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw
YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsg
ZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj53b3VsZA0KIGJlIHVuZGVyIFJG
QzIxMTkgKGFsdGhvdWdoIGluIGZhY3QgdGhhdCBkb2Vzbid0IGNoYW5nZSB0aGU8c3BhbiBjbGFz
cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0i
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt
YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl
ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0
LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg
d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg
Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu
b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh
bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz
cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5FbmdsaXNoDQogbWVhbmluZyBvZiAn
bXVzdCcpLiBUaGUgJnF1b3Q7Tm90ZTomcXVvdDsgZGVzY3JpYmVzIGEgc2l0dWF0aW9uIHdoZXJl
PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt
YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp
dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj
aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz
OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4
OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5taWRk
bGVib3hlcw0KIGFyZSBhY3R1YWxseSBicmVha2luZyB0aGUgcnVsZS4gV2UgaGFkIHRoYXQgZmln
aHQgYmVmb3JlPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z
aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1
dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu
b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFz
cz0iIj5SRkM3MDQ1Ljwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv
bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z
OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JbmRlZWQu
IFRoZSBSRkM3MDQ1IGV4Y2VwdGlvbiBhcHBsaWVzIHNwZWNpZmljYWxseSB0byAqZXhhbWluaW5n
KiBoZWFkZXJzLCB3aXRoIHRoZSBjb21tb24gdXNlIGNhc2UgYmVpbmcgZmlyZXdhbGxpbmcuJm5i
c3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5DaGFuZ2luZyB0aGUg
UkZDNzA0NSBleGNlcHRpb24gdGV4dCB0byBjbGFyaWZ5IHRoaXMgaW4gMjQ2MGJpcyB3YXMgcHJv
cG9zZWQsIGJ1dCBpdCB3YXNu4oCZdCB0YWtlbiBmb3J3YXJkLjwvZGl2Pg0KPGRpdj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NClRpbTwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm
b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh
Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93
czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QnJpYW48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v
cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7
IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz
cz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt
YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp
dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFt
aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog
YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi
IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg
dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg
d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQpJZiAnYXJlIG5vdCBleGFtaW5l
ZCZxdW90OyBpcyB0byBiZSBpbnRlcnByZXRlZCBhcyBSRkMyMTE5ICdNVVNUIE5PVCcsPGJyIGNs
YXNzPSIiPg0KdGhlbiB0aGUgZm9sbG93aW5nIG5vdGUgY29uZmxpY3RzIHdpdGggdGhhdCBzdGF0
ZW1lbnQuICdBIG5vZGUgTVVTVDxiciBjbGFzcz0iIj4NCk5PVCBleGFtaW5lIEVIczxiciBjbGFz
cz0iIj4NCmJ1dCBpZiBpdCBkb2VzIGl0IG11c3QgZG8gaXQgYXMgcGVyIFJGQzcwNDUnIC0gaXQg
aXMgZXh0cmVtZWx5IGNvbnRyb3ZlcnNpYWwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
SWYgJydhcmUgbm90IGV4YW1pbmVkJnF1b3Q7IGlzIHRvIGJlIHJlYWQgYXMgUkZDMjExOSAnU0hP
VUxEIE5PVCcgdGhlbiBJPGJyIGNsYXNzPSIiPg0KaGF2ZSBhIHZlcnkgZ29vZCBuZXdzIGZvcjxi
ciBjbGFzcz0iIj4NCnRob3NlIHdobyB3b3VsZCBzdGlsbCBsaWtlIHRvIGluc2VydC9kZWxldGUg
RUhzOiB0aGV5IGNhbiBkbyBpdCAmbmJzcDthczxiciBjbGFzcz0iIj4NCmxvbmcgYXMgJm5ic3A7
dGhleSBoYXZlPGJyIGNsYXNzPSIiPg0KJnF1b3Q7dmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFy
IGNpcmN1bXN0YW5jZXMgd2hlbiB0aGUgcGFydGljdWxhcjxiciBjbGFzcz0iIj4NCmJlaGF2aW9y
IGlzIGFjY2VwdGFibGUgb3IgZXZlbiB1c2VmdWwsIGJ1dCB0aGUgZnVsbDxiciBjbGFzcz0iIj4N
CiZuYnNwOyZuYnNwO2ltcGxpY2F0aW9ucyBzaG91bGQgYmUgdW5kZXJzdG9vZCBhbmQgdGhlIGNh
c2UgY2FyZWZ1bGx5IHdlaWdoZWQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtiZWZvcmUgaW1w
bGVtZW50aW5nIGFueSBiZWhhdmlvciBkZXNjcmliZWQgd2l0aCB0aGlzIGxhYmVsLiZxdW90Oy48
YnIgY2xhc3M9IiI+DQpCdXQgZnJvbSB0b2RheSdzIHByZXNlbnRhdGlvbiBJJ3ZlIGdvdCBhbiBp
bXByZXNzaW9uIHRoYXQgdGhlPGJyIGNsYXNzPSIiPg0KaW50ZW50aW9uIG9mIHRoaXMgdGV4dCB3
YXMgYWN0dWFsbHkgdG8gcHJvaGliaXQgRUggaW5zZXJ0aW9uPGJyIGNsYXNzPSIiPg0KKHRoZSBz
aWxkZXMgc2F5ICdubyBvbmUgYXJndWVkIGFnYWluc3QgdGhlIGZhY3QgdGhhdCB0aGUgaW50ZW50
IG9mIHRoZTxiciBjbGFzcz0iIj4NCnRleHQgaW4gUkZDMjQ2MDxiciBjbGFzcz0iIj4NCndhcyB0
byBmb3JiaWQgaW5zZXJ0aW9uIG9mIGV4dGVuc2lvbiBoZWFkZXJzIG9uIGFueSBvdGhlciBub2Rl
IGJ1dCB0aGUgc291cmNlPGJyIGNsYXNzPSIiPg0Kb2YgdGhlIHBhY2tldC4pLjxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NClNvIHRvIHN1bW1hcml6ZTogdGhlIHByb3Bvc2VkIHRleHQgZWl0
aGVyIGV4cGxpY2l0bHkgcHJvaGliaXRzIHRoZTxiciBjbGFzcz0iIj4NCmV4YW1pbmF0aW9uIChh
bmQgdGhlbiBpdCBjb250cmFkaWN0cyB0aGUgbmV4dCBzZW50ZW5jZSBhbmQgd2UgbmVlZCB0bzxi
ciBjbGFzcz0iIj4NCmRvIHNtdGggd2l0aCB0aGUgbm90ZSBhbmQgUkZDNzA0NSkgT1IgaXQgYWxs
b3dzIEVIIGluc2VydGlvbiAtIGl0PGJyIGNsYXNzPSIiPg0KZGVwZW5kcyBob3cgdGhlIHRleHQg
aXMgaW50ZXJwcmV0ZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w
b3J0YW50OyIgY2xhc3M9IiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls
eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12
YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6
IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1
dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj
bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6
IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u
dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp
bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPklFVEYNCiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGlu
ZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl
OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt
YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl
ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0
LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg
d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i
Ij48YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgY2xhc3M9IiI+aXB2NkBpZXRmLm9yZzwv
YT48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy
cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13
ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw
YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k
ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv
d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw
cHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkFk
bWluaXN0cmF0aXZlDQogUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vaXB2NiIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9pcHY2PC9hPjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp
Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv
cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10
cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0
YW50OyIgY2xhc3M9IiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg==
--_000_F2FACDFCE7A847D885528E11D7E98345jiscacuk_--


From nobody Fri Mar 31 08:04:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC7A1294ED for ; Fri, 31 Mar 2017 08:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.09
X-Spam-Level: 
X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com
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 Xz4eMd7LdEDC for ; Fri, 31 Mar 2017 08:04:09 -0700 (PDT)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAED5129511 for ; Fri, 31 Mar 2017 08:04:09 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 2220DC15C7 for ; Fri, 31 Mar 2017 10:04:09 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 70FE2C15A8; Fri, 31 Mar 2017 10:04:08 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F18F4FE066; Fri, 31 Mar 2017 11:04:19 -0400 (EDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8199FE064; Fri, 31 Mar 2017 11:04:19 -0400 (EDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (unknown [216.32.180.175]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Fri, 31 Mar 2017 11:04:19 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com;  s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=an/rHYnEPEQ2iUIKEo2E3JGctcNXZdfr4tP4kR5Hj7k=; b=IVkwrNXPYoJte4WPLTDwIN8t7qx1QQv1w9pnRmsuR01JbsaypGWHF498xyNAKKOG9mIw4EtariaciCOW8RMS5QF4CkbOEGwofsv6+jYWWu1q6+xEQqqyyODIHyewoh4cE2c8YDCNmO4LBbGY1U+NAz6kibsgHH5yGI8fqk4kZro=
Received: from BN6PR14MB1361.namprd14.prod.outlook.com (10.172.149.135) by BN6PR14MB1362.namprd14.prod.outlook.com (10.172.149.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Fri, 31 Mar 2017 15:04:05 +0000
Received: from BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) by BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) with mapi id 15.01.1005.014; Fri, 31 Mar 2017 15:04:05 +0000
From: "Ackermann, Michael" 
To: Tim Chown , Brian E Carpenter 
CC: "ipv6@ietf.org" 
Subject: RE: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGuC10AgAAPeACAAQO2gIAABphg
Date: Fri, 31 Mar 2017 15:04:05 +0000
Message-ID: 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com; 
x-originating-ip: [31.133.134.235]
x-microsoft-exchange-diagnostics: 1; BN6PR14MB1362; 7:RXxDVH0BzeJN3Sl5+G7/EZaU+Caeuzn5CIfONUhKse5MQApWJGoVTsXQVnTxUgTtt6N+wU5eKOUma6xojKa/t7dnfn9FNL+g2sjYV5/SN2q7lSpFIIkTUr/YX1y8P7e6lLDMdh965J1iavqmCYNv0jWbynE1SPhfk5rTcPHCoQlezdA3Jx10j0o6E9bw81BnuC7Ue9HAicYqCD9oeKMNu5iNh+ApCr72sWAd2nFAVUtHb7H1/HOPuZ7Zt09RCPKsAAUJmO8HEUs1adcWWEIyQssMReRxJrRcdw1JBHJ5aLHeWwcylBw/NFXhP2jV0c4+HrvEu/cIjzfJdnfTX8V+lw==; 20:BaJdVfkRVo/AlDmn/p2gdjgvwpR4gvVcwjWLKdNNPI/XfPAv5dE1+CixEj+ik60Z3pGddf0uk70AphWytbfRS7+2skHlk7SbJf31yPAU//gN49p1MC0gTkxbUGhClUwYsYOn3zWKeA5pMZ9F4NYkvn0IUIAtL34+Qypq5UQaPMc=
x-ms-office365-filtering-correlation-id: 613b319a-9941-4f3e-f361-08d478472cfb
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR14MB1362; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(100405760836317)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BN6PR14MB1362; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1362; 
x-forefront-prvs: 02638D901B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400002)(39410400002)(39400400002)(39450400003)(54164003)(24454002)(377454003)(2900100001)(19609705001)(230783001)(7696004)(229853002)(2950100002)(7736002)(7906003)(74316002)(106356001)(122556002)(66066001)(86362001)(5660300001)(6506006)(4326008)(77096006)(6436002)(53546009)(8676002)(790700001)(606005)(6246003)(25786009)(80792005)(38730400002)(3846002)(6116002)(102836003)(54356999)(189998001)(2906002)(236005)(3660700001)(39060400002)(3280700002)(8936002)(6306002)(76176999)(50986999)(55016002)(9686003)(99286003)(54896002)(53936002)(33656002)(81166006)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1362; H:BN6PR14MB1361.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR14MB136174D6D442396781347270D7370BN6PR14MB1361namp_"
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 15:04:05.6771 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1362
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm02.z120.zixworks.com
X-VPM-GROUP-ID: dd9a81cc-a64f-4472-9678-26d9ff511c00
X-VPM-MSG-ID: cd027ab1-d474-4c30-98f7-786b31890f2a
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 15:04:13 -0000

--_000_BN6PR14MB136174D6D442396781347270D7370BN6PR14MB1361namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UVVFU1RJT046DQpEb2VzIHRoZSB3b3JkIFBST0NFU1NFRCwgbWVhbiBjaGFuZ2UsIGltcGx5
aW5nIHdyaXRlIGNhcGFiaWxpdHk/DQpJZiB5ZXMsIGNhbiB0aGF0IGJlIHN0YXRlZD8NCg0K
DQpGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgVGltIENob3duDQpTZW50OiBGcmlkYXksIE1hcmNoIDMxLCAyMDE3IDEwOjM5IEFNDQpU
bzogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4NCkNj
OiBpcHY2QGlldGYub3JnDQpTdWJqZWN0OiBSZTogSUVURiBMYXN0IENhbGwgY29uY2x1c2lv
biBmb3IgZHJhZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMtMDgNCg0KT24gMzEgTWFyIDIwMTcs
IGF0IDAwOjA5LCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwu
Y29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+PiB3cm90ZToNCg0KT24g
MzEvMDMvMjAxNyAxMToxMywgSmVuIExpbmtvdmEgd3JvdGU6DQoNCk9uIFdlZCwgTWFyIDE1
LCAyMDE3IGF0IDM6NDcgQU0sIFN1cmVzaCBLcmlzaG5hbg0KPHN1cmVzaC5rcmlzaG5hbkBl
cmljc3Nvbi5jb208bWFpbHRvOnN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20+PiB3cm90
ZToNCg0KVGhhbmtzIHRvIGV2ZXJ5b25lIHdobyBjb21tZW50ZWQgZHVyaW5nIHRoZSBJRVRG
IExhc3QgQ2FsbCBvZiBkcmFmdC1pZXRmLTZtYW4tcmZjMjQ2MGJpcy0wOC4gVGhlIElFVEYg
bGFzdCBjYWxsIGRpc2N1c3Npb24gZm9yIHRoaXMgZHJhZnQgd2FzIG1haW5seSBmb2N1c2Vk
IGFyb3VuZCB0aGUgdGV4dCBpbiBTZWN0aW9uIDQgdGhhdCBkaXNjdXNzZXMgdGhlIGhhbmRs
aW5nIG9mIGV4dGVuc2lvbiBoZWFkZXJzLiBUaGUgYmlnZ2VzdCBjb25jZXJuIHJhaXNlZCB3
YXMgdGhhdCB0aGUgY3VycmVudCB0ZXh0IGlzIGFtYmlndW91cyBvbiB3aGV0aGVyIGhlYWRl
ciBpbnNlcnRpb24gaXMgYWxsb3dlZCBvbiBpbnRlcm1lZGlhdGUgbm9kZXMgb3Igbm90LiBU
aGVyZSB3ZXJlIHNvbWUgcGVvcGxlIGFyZ3VpbmcgdGhhdCBhbiBleHBsaWNpdCBwcm9oaWJp
dGlvbiBpcyBub3QgbmVjZXNzYXJ5IGFzIHRoZSB0ZXh0IGlzIGFscmVhZHkgY2xlYXIsIHdo
aWxlIG90aGVycyBiZWxpZXZlZCB0aGF0IGV4cGxpY2l0bHkgbGlzdGluZyB0aGUgcHJvaGli
aXRpb25zIHdpbGwgbWluaW1pemUgYW55IG1pc3VuZGVyc3RhbmRpbmdzIGluIHRoZSBmdXR1
cmUuIFRoZXJlIHdhcyBhbHNvIGEgc21hbGwgbnVtYmVyIG9mIHBlb3BsZSB3aG8gd2FudGVk
IHRvIGV4cGxpY2l0bHkgYWxsb3cgaGVhZGVyIGluc2VydGlvbiBhbmQgZGVzY3JpYmUgaG93
IHRvIGRvIGl0LCBidXQgdGhpcyB3YXMgY2xlYXJseSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMg
ZHJhZnQgKGJ1dCBtYXkgYmUgaW4gc2NvcGUgZm9yIGZ1dHVyZSB3b3JrIGluIDZtYW4pLiBP
dmVyYWxsLCBubyBvbmUgYXJndWVkIGFnYWluc3QgdGhlIGZhY3QgdGhhdCB0aGUgaW50ZW50
IG9mIHRoZSB0ZXh0IGluIFJGQzI0NjAgd2FzIHRvIGZvcmJpZCBpbnNlcnRpb24gb2YgZXh0
ZW5zaW9uIGhlYWRlcnMgb24gYW55IG90aGVyIG5vZGUgYnV0IHRoZSBzb3VyY2Ugb2YgdGhl
IHBhY2tldC4gIFRoZSBvbmx5IGFyZ3VtZW50IG0NCmENCg0KZGUgYWdhaW5zdCBhZGRpbmcg
Y2xhcmlmeWluZyB0ZXh0IHdhcyB0aGF0IHRoZSB0ZXh0IHdhcyBhbHJlYWR5IGNsZWFyLiBH
aXZlbiB0aGlzLCBJIGJlbGlldmUgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIGFkZCBleHBsaWNp
dCB0ZXh0IGFib3V0IGhlYWRlciBpbnNlcnRpb24gaW50byB0aGUgZHJhZnQgYmVmb3JlIGl0
IHByb2dyZXNzZXMgZnVydGhlci4gSSBoYXZlIGRpc2N1c3NlZCB0aGlzIHdpdGggdGhlIGVk
aXRvciBhbmQgdGhlIGRvY3VtZW50IHNoZXBoZXJkIGFuZCB3b3VsZCBsaWtlIHRvIHByb3Bv
c2UgdGhlIGZvbGxvd2luZyB0ZXh0IGNoYW5nZS4NCg0KDQpPTEQgKGZyb20gLTA4KToNCg0K
VGhlIGluc2VydGlvbiBvZiBFeHRlbnNpb24gSGVhZGVycyBieSBhbnkgbm9kZSBvdGhlciB0
aGFuIHRoZSBzb3VyY2UNCm9mIHRoZSBwYWNrZXQgY2F1c2VzIHNlcmlvdXMgcHJvYmxlbXMu
ICBUd28gZXhhbXBsZXMgaW5jbHVkZSBicmVha2luZw0KdGhlIGludGVncml0eSBjaGVja3Mg
cHJvdmlkZWQgYnkgdGhlIEF1dGhlbnRpY2F0aW9uIEhlYWRlciBJbnRlZ3JpdHkNCltSRkM0
MzAyXSwgYW5kIGJyZWFraW5nIFBhdGggTVRVIERpc2NvdmVyeSB3aGljaCBjYW4gcmVzdWx0
IGluIElDTVANCmVycm9yIG1lc3NhZ2VzIGJlaW5nIHNlbnQgdG8gdGhlIHNvdXJjZSBvZiB0
aGUgcGFja2V0IHRoYXQgZGlkIG5vdA0KaW5zZXJ0IHRoZSBoZWFkZXIsIHJhdGhlciB0aGFu
IHRoZSBub2RlIHRoYXQgaW5zZXJ0ZWQgdGhlIGhlYWRlci4NCg0KT25lIGFwcHJvYWNoIHRv
IGF2b2lkIHRoZXNlIHByb2JsZW1zIGlzIHRvIGVuY2Fwc3VsYXRlIHRoZSBwYWNrZXQNCnVz
aW5nIGFub3RoZXIgSVB2NiBoZWFkZXIgYW5kIGluY2x1ZGluZyB0aGUgYWRkaXRpb25hbCBl
eHRlbnNpb24NCmhlYWRlciBhZnRlciB0aGUgZmlyc3QgSVB2NiBoZWFkZXIsIGZvciBleGFt
cGxlLCBhcyBkZWZpbmVkIGluDQpbUkZDMjQ3M10NCg0KV2l0aCBvbmUgZXhjZXB0aW9uLCBl
eHRlbnNpb24gaGVhZGVycyBhcmUgbm90IHByb2Nlc3NlZCBieSBhbnkgbm9kZQ0KYWxvbmcg
YSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLCB1bnRpbCB0aGUgcGFja2V0IHJlYWNoZXMgdGhl
IG5vZGUgKG9yDQplYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluIHRoZSBjYXNlIG9mIG11
bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUNCkRlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQg
b2YgdGhlIElQdjYgaGVhZGVyLi4uDQoNCk5FVzoNCg0KV2l0aCBvbmUgZXhjZXB0aW9uLCBl
eHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1pbmVkLCBwcm9jZXNzZWQsDQppbnNlcnRl
ZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBh
dGgsDQp1bnRpbCB0aGUgcGFja2V0IHJlYWNoZXMgdGhlIG5vZGUgKG9yIGVhY2ggb2YgdGhl
IHNldCBvZiBub2RlcywgaW4NCnRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBp
biB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZg0KdGhlIElQdjYgaGVhZGVyLi4u
DQoNCkkgaGF2ZSBzb21lIGNvbmNlcm5zIHdpdGggaG93IHRoYXQgc2VudGVuY2UgQU5EIHRo
ZSBmb2xsb3dpbmcgbm90ZQ0KY29tZXMgdG9nZXRoZXI6DQoNCiIgIFdpdGggb25lIGV4Y2Vw
dGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCwgcHJvY2Vzc2VkLA0K
ICBpbnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRl
bGl2ZXJ5IHBhdGgsDQogIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3Ig
ZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbg0KICB0aGUgY2FzZSBvZiBtdWx0aWNhc3Qp
IGlkZW50aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YNCiAgdGhl
IElQdjYgaGVhZGVyLiAgTm90ZTogSWYgYW4gaW50ZXJtZWRpYXRlIGZvcndhcmRpbmcgbm9k
ZSBleGFtaW5lcw0KICBhbiBleHRlbnNpb24gaGVhZGVyIGZvciBhbnkgcmVhc29uLCBpdCBt
dXN0IGRvIHNvIGluIGFjY29yZGFuY2Ugd2l0aA0KICB0aGUgcHJvdmlzaW9ucyBvZiBbUkZD
NzA0NV0uICAiDQoNCkknbSBhZnJhaWQgdGhhdCB0aGUgbGFjayBvZiB0aGUgbm9ybWF0aXZl
IGxhbmd1YWdlIHN0cmlrZXMgYmFjay4uDQoNCkV4YWN0bHkgdGhlIG9wcG9zaXRlLCBJTUhP
LiBJIHRoaW5rIGl0J3MgbXVjaCBiZXR0ZXIgbGlrZSB0aGlzIHRoYW4gaXQNCndvdWxkIGJl
IHVuZGVyIFJGQzIxMTkgKGFsdGhvdWdoIGluIGZhY3QgdGhhdCBkb2Vzbid0IGNoYW5nZSB0
aGUNCkVuZ2xpc2ggbWVhbmluZyBvZiAnbXVzdCcpLiBUaGUgIk5vdGU6IiBkZXNjcmliZXMg
YSBzaXR1YXRpb24gd2hlcmUNCm1pZGRsZWJveGVzIGFyZSBhY3R1YWxseSBicmVha2luZyB0
aGUgcnVsZS4gV2UgaGFkIHRoYXQgZmlnaHQgYmVmb3JlDQpSRkM3MDQ1Lg0KDQpJbmRlZWQu
IFRoZSBSRkM3MDQ1IGV4Y2VwdGlvbiBhcHBsaWVzIHNwZWNpZmljYWxseSB0byAqZXhhbWlu
aW5nKiBoZWFkZXJzLCB3aXRoIHRoZSBjb21tb24gdXNlIGNhc2UgYmVpbmcgZmlyZXdhbGxp
bmcuDQoNCkNoYW5naW5nIHRoZSBSRkM3MDQ1IGV4Y2VwdGlvbiB0ZXh0IHRvIGNsYXJpZnkg
dGhpcyBpbiAyNDYwYmlzIHdhcyBwcm9wb3NlZCwgYnV0IGl0IHdhc27igJl0IHRha2VuIGZv
cndhcmQuDQoNClRpbQ0KDQoNCiAgICBCcmlhbg0KDQoNCg0KSWYgJ2FyZSBub3QgZXhhbWlu
ZWQiIGlzIHRvIGJlIGludGVycHJldGVkIGFzIFJGQzIxMTkgJ01VU1QgTk9UJywNCnRoZW4g
dGhlIGZvbGxvd2luZyBub3RlIGNvbmZsaWN0cyB3aXRoIHRoYXQgc3RhdGVtZW50LiAnQSBu
b2RlIE1VU1QNCk5PVCBleGFtaW5lIEVIcw0KYnV0IGlmIGl0IGRvZXMgaXQgbXVzdCBkbyBp
dCBhcyBwZXIgUkZDNzA0NScgLSBpdCBpcyBleHRyZW1lbHkgY29udHJvdmVyc2lhbC4NCg0K
SWYgJydhcmUgbm90IGV4YW1pbmVkIiBpcyB0byBiZSByZWFkIGFzIFJGQzIxMTkgJ1NIT1VM
RCBOT1QnIHRoZW4gSQ0KaGF2ZSBhIHZlcnkgZ29vZCBuZXdzIGZvcg0KdGhvc2Ugd2hvIHdv
dWxkIHN0aWxsIGxpa2UgdG8gaW5zZXJ0L2RlbGV0ZSBFSHM6IHRoZXkgY2FuIGRvIGl0ICBh
cw0KbG9uZyBhcyAgdGhleSBoYXZlDQoidmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNp
cmN1bXN0YW5jZXMgd2hlbiB0aGUgcGFydGljdWxhcg0KYmVoYXZpb3IgaXMgYWNjZXB0YWJs
ZSBvciBldmVuIHVzZWZ1bCwgYnV0IHRoZSBmdWxsDQogIGltcGxpY2F0aW9ucyBzaG91bGQg
YmUgdW5kZXJzdG9vZCBhbmQgdGhlIGNhc2UgY2FyZWZ1bGx5IHdlaWdoZWQNCiAgYmVmb3Jl
IGltcGxlbWVudGluZyBhbnkgYmVoYXZpb3IgZGVzY3JpYmVkIHdpdGggdGhpcyBsYWJlbC4i
Lg0KQnV0IGZyb20gdG9kYXkncyBwcmVzZW50YXRpb24gSSd2ZSBnb3QgYW4gaW1wcmVzc2lv
biB0aGF0IHRoZQ0KaW50ZW50aW9uIG9mIHRoaXMgdGV4dCB3YXMgYWN0dWFsbHkgdG8gcHJv
aGliaXQgRUggaW5zZXJ0aW9uDQoodGhlIHNpbGRlcyBzYXkgJ25vIG9uZSBhcmd1ZWQgYWdh
aW5zdCB0aGUgZmFjdCB0aGF0IHRoZSBpbnRlbnQgb2YgdGhlDQp0ZXh0IGluIFJGQzI0NjAN
CndhcyB0byBmb3JiaWQgaW5zZXJ0aW9uIG9mIGV4dGVuc2lvbiBoZWFkZXJzIG9uIGFueSBv
dGhlciBub2RlIGJ1dCB0aGUgc291cmNlDQpvZiB0aGUgcGFja2V0LikuDQoNClNvIHRvIHN1
bW1hcml6ZTogdGhlIHByb3Bvc2VkIHRleHQgZWl0aGVyIGV4cGxpY2l0bHkgcHJvaGliaXRz
IHRoZQ0KZXhhbWluYXRpb24gKGFuZCB0aGVuIGl0IGNvbnRyYWRpY3RzIHRoZSBuZXh0IHNl
bnRlbmNlIGFuZCB3ZSBuZWVkIHRvDQpkbyBzbXRoIHdpdGggdGhlIG5vdGUgYW5kIFJGQzcw
NDUpIE9SIGl0IGFsbG93cyBFSCBpbnNlcnRpb24gLSBpdA0KZGVwZW5kcyBob3cgdGhlIHRl
eHQgaXMgaW50ZXJwcmV0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcg
Z3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3Jn
Pg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KCgpUaGUgaW5mb3JtYXRpb24g
Y29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFs
IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwo
cykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUg
bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo
YXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9m
IHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRl
ZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtp
bmcgYW55IGNvcGllcy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBh
bmQgQmx1ZSBDYXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3Jh
dGlvbnMgYW5kIGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQg
Qmx1ZSBTaGllbGQgQXNzb2NpYXRpb24uCg==

--_000_BN6PR14MB136174D6D442396781347270D7370BN6PR14MB1361namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89
InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu
OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj
aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov
L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9
IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt
ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRl
cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0
IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0K
LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp
di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp
Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z
b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u
YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln
aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp
bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l
OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2
bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlFVRVNUSU9OOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RG9l
cyB0aGUgd29yZCBQUk9DRVNTRUQsIG1lYW4gY2hhbmdlLCBpbXBseWluZyB3cml0ZSBjYXBh
YmlsaXR5Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj5JZiB5ZXMsIGNhbiB0aGF0IGJlIHN0YXRlZD8NCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGlwdjYgW21haWx0bzppcHY2
LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRpbSBDaG93bjxicj4N
CjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1hcmNoIDMxLCAyMDE3IDEwOjM5IEFNPGJyPg0KPGI+
VG86PC9iPiBCcmlhbiBFIENhcnBlbnRlciAmbHQ7YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwu
Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaXB2NkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6
PC9iPiBSZTogSUVURiBMYXN0IENhbGwgY29uY2x1c2lvbiBmb3IgZHJhZnQtaWV0Zi02bWFu
LXJmYzI0NjBiaXMtMDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMzEgTWFyIDIwMTcsIGF0IDAwOjA5
LCBCcmlhbiBFIENhcnBlbnRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVu
dGVyQGdtYWlsLmNvbSI+YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPk9uIDMxLzAzLzIwMTcgMTE6MTMsIEplbiBMaW5rb3ZhIHdyb3RlOjxi
ciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQt
YWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gV2VkLCBN
YXIgMTUsIDIwMTcgYXQgMzo0NyBBTSwgU3VyZXNoIEtyaXNobmFuPGJyPg0KJmx0OzxhIGhy
ZWY9Im1haWx0bzpzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tIj5zdXJlc2gua3Jpc2hu
YW5AZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48
L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5UaGFua3MgdG8gZXZlcnlvbmUgd2hvIGNvbW1lbnRlZCBkdXJpbmcgdGhlIElFVEYg
TGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtNm1hbi1yZmMyNDYwYmlzLTA4LiBUaGUgSUVURiBs
YXN0IGNhbGwgZGlzY3Vzc2lvbiBmb3IgdGhpcyBkcmFmdCB3YXMgbWFpbmx5IGZvY3VzZWQg
YXJvdW5kIHRoZSB0ZXh0DQogaW4gU2VjdGlvbiA0IHRoYXQgZGlzY3Vzc2VzIHRoZSBoYW5k
bGluZyBvZiBleHRlbnNpb24gaGVhZGVycy4gVGhlIGJpZ2dlc3QgY29uY2VybiByYWlzZWQg
d2FzIHRoYXQgdGhlIGN1cnJlbnQgdGV4dCBpcyBhbWJpZ3VvdXMgb24gd2hldGhlciBoZWFk
ZXIgaW5zZXJ0aW9uIGlzIGFsbG93ZWQgb24gaW50ZXJtZWRpYXRlIG5vZGVzIG9yIG5vdC4g
VGhlcmUgd2VyZSBzb21lIHBlb3BsZSBhcmd1aW5nIHRoYXQgYW4gZXhwbGljaXQgcHJvaGli
aXRpb24NCiBpcyBub3QgbmVjZXNzYXJ5IGFzIHRoZSB0ZXh0IGlzIGFscmVhZHkgY2xlYXIs
IHdoaWxlIG90aGVycyBiZWxpZXZlZCB0aGF0IGV4cGxpY2l0bHkgbGlzdGluZyB0aGUgcHJv
aGliaXRpb25zIHdpbGwgbWluaW1pemUgYW55IG1pc3VuZGVyc3RhbmRpbmdzIGluIHRoZSBm
dXR1cmUuIFRoZXJlIHdhcyBhbHNvIGEgc21hbGwgbnVtYmVyIG9mIHBlb3BsZSB3aG8gd2Fu
dGVkIHRvIGV4cGxpY2l0bHkgYWxsb3cgaGVhZGVyIGluc2VydGlvbiBhbmQgZGVzY3JpYmUN
CiBob3cgdG8gZG8gaXQsIGJ1dCB0aGlzIHdhcyBjbGVhcmx5IG91dCBvZiBzY29wZSBmb3Ig
dGhpcyBkcmFmdCAoYnV0IG1heSBiZSBpbiBzY29wZSBmb3IgZnV0dXJlIHdvcmsgaW4gNm1h
bikuIE92ZXJhbGwsIG5vIG9uZSBhcmd1ZWQgYWdhaW5zdCB0aGUgZmFjdCB0aGF0IHRoZSBp
bnRlbnQgb2YgdGhlIHRleHQgaW4gUkZDMjQ2MCB3YXMgdG8gZm9yYmlkIGluc2VydGlvbiBv
ZiBleHRlbnNpb24gaGVhZGVycyBvbiBhbnkgb3RoZXIgbm9kZSBidXQNCiB0aGUgc291cmNl
IG9mIHRoZSBwYWNrZXQuICZuYnNwO1RoZSBvbmx5IGFyZ3VtZW50IG08bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5hPGJyIHN0eWxlPSJmb250LXZhcmlhbnQt
Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1
dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K
PGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5kZSBhZ2FpbnN0IGFkZGluZyBjbGFyaWZ5aW5nIHRl
eHQgd2FzIHRoYXQgdGhlIHRleHQgd2FzIGFscmVhZHkgY2xlYXIuIEdpdmVuIHRoaXMsIEkg
YmVsaWV2ZSB0aGVyZSBpcyBjb25zZW5zdXMgdG8gYWRkIGV4cGxpY2l0IHRleHQgYWJvdXQg
aGVhZGVyIGluc2VydGlvbiBpbnRvIHRoZSBkcmFmdA0KIGJlZm9yZSBpdCBwcm9ncmVzc2Vz
IGZ1cnRoZXIuIEkgaGF2ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIHRoZSBlZGl0b3IgYW5kIHRo
ZSBkb2N1bWVudCBzaGVwaGVyZCBhbmQgd291bGQgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xs
b3dpbmcgdGV4dCBjaGFuZ2UuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpP
TEQgKGZyb20gLTA4KTo8YnI+DQo8YnI+DQpUaGUgaW5zZXJ0aW9uIG9mIEV4dGVuc2lvbiBI
ZWFkZXJzIGJ5IGFueSBub2RlIG90aGVyIHRoYW4gdGhlIHNvdXJjZTxicj4NCm9mIHRoZSBw
YWNrZXQgY2F1c2VzIHNlcmlvdXMgcHJvYmxlbXMuICZuYnNwO1R3byBleGFtcGxlcyBpbmNs
dWRlIGJyZWFraW5nPGJyPg0KdGhlIGludGVncml0eSBjaGVja3MgcHJvdmlkZWQgYnkgdGhl
IEF1dGhlbnRpY2F0aW9uIEhlYWRlciBJbnRlZ3JpdHk8YnI+DQpbUkZDNDMwMl0sIGFuZCBi
cmVha2luZyBQYXRoIE1UVSBEaXNjb3Zlcnkgd2hpY2ggY2FuIHJlc3VsdCBpbiBJQ01QPGJy
Pg0KZXJyb3IgbWVzc2FnZXMgYmVpbmcgc2VudCB0byB0aGUgc291cmNlIG9mIHRoZSBwYWNr
ZXQgdGhhdCBkaWQgbm90PGJyPg0KaW5zZXJ0IHRoZSBoZWFkZXIsIHJhdGhlciB0aGFuIHRo
ZSBub2RlIHRoYXQgaW5zZXJ0ZWQgdGhlIGhlYWRlci48YnI+DQo8YnI+DQpPbmUgYXBwcm9h
Y2ggdG8gYXZvaWQgdGhlc2UgcHJvYmxlbXMgaXMgdG8gZW5jYXBzdWxhdGUgdGhlIHBhY2tl
dDxicj4NCnVzaW5nIGFub3RoZXIgSVB2NiBoZWFkZXIgYW5kIGluY2x1ZGluZyB0aGUgYWRk
aXRpb25hbCBleHRlbnNpb248YnI+DQpoZWFkZXIgYWZ0ZXIgdGhlIGZpcnN0IElQdjYgaGVh
ZGVyLCBmb3IgZXhhbXBsZSwgYXMgZGVmaW5lZCBpbjxicj4NCltSRkMyNDczXTxicj4NCjxi
cj4NCldpdGggb25lIGV4Y2VwdGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBwcm9j
ZXNzZWQgYnkgYW55IG5vZGU8YnI+DQphbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGgs
IHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3I8YnI+DQplYWNoIG9mIHRo
ZSBzZXQgb2Ygbm9kZXMsIGluIHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBp
biB0aGU8YnI+DQpEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mIHRoZSBJUHY2IGhlYWRl
ci4uLjxicj4NCjxicj4NCk5FVzo8YnI+DQo8YnI+DQpXaXRoIG9uZSBleGNlcHRpb24sIGV4
dGVuc2lvbiBoZWFkZXJzIGFyZSBub3QgZXhhbWluZWQsIHByb2Nlc3NlZCw8YnI+DQppbnNl
cnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5
IHBhdGgsPGJyPg0KdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNo
IG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluPGJyPg0KdGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBp
ZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mPGJyPg0KdGhl
IElQdjYgaGVhZGVyLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KSSBoYXZl
IHNvbWUgY29uY2VybnMgd2l0aCBob3cgdGhhdCBzZW50ZW5jZSBBTkQgdGhlIGZvbGxvd2lu
ZyBub3RlPGJyPg0KY29tZXMgdG9nZXRoZXI6PGJyPg0KPGJyPg0KJnF1b3Q7ICZuYnNwO1dp
dGggb25lIGV4Y2VwdGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCwg
cHJvY2Vzc2VkLDxicj4NCiZuYnNwOyZuYnNwO2luc2VydGVkLCBvciBkZWxldGVkIGJ5IGFu
eSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCw8YnI+DQombmJzcDsmbmJz
cDt1bnRpbCB0aGUgcGFja2V0IHJlYWNoZXMgdGhlIG5vZGUgKG9yIGVhY2ggb2YgdGhlIHNl
dCBvZiBub2RlcywgaW48YnI+DQombmJzcDsmbmJzcDt0aGUgY2FzZSBvZiBtdWx0aWNhc3Qp
IGlkZW50aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2Y8YnI+DQom
bmJzcDsmbmJzcDt0aGUgSVB2NiBoZWFkZXIuICZuYnNwO05vdGU6IElmIGFuIGludGVybWVk
aWF0ZSBmb3J3YXJkaW5nIG5vZGUgZXhhbWluZXM8YnI+DQombmJzcDsmbmJzcDthbiBleHRl
bnNpb24gaGVhZGVyIGZvciBhbnkgcmVhc29uLCBpdCBtdXN0IGRvIHNvIGluIGFjY29yZGFu
Y2Ugd2l0aDxicj4NCiZuYnNwOyZuYnNwO3RoZSBwcm92aXNpb25zIG9mIFtSRkM3MDQ1XS4g
Jm5ic3A7JnF1b3Q7PGJyPg0KPGJyPg0KSSdtIGFmcmFpZCB0aGF0IHRoZSBsYWNrIG9mIHRo
ZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugc3RyaWtlcyBiYWNrLi48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj48YnI+DQpFeGFjdGx5IHRoZSBvcHBvc2l0ZSwgSU1ITy4gSSB0aGluayBpdCdz
IG11Y2ggYmV0dGVyIGxpa2UgdGhpcyB0aGFuIGl0PGJyPg0Kd291bGQgYmUgdW5kZXIgUkZD
MjExOSAoYWx0aG91Z2ggaW4gZmFjdCB0aGF0IGRvZXNuJ3QgY2hhbmdlIHRoZTxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpFbmdsaXNo
IG1lYW5pbmcgb2YgJ211c3QnKS4gVGhlICZxdW90O05vdGU6JnF1b3Q7IGRlc2NyaWJlcyBh
IHNpdHVhdGlvbiB3aGVyZTxicj4NCm1pZGRsZWJveGVzIGFyZSBhY3R1YWxseSBicmVha2lu
ZyB0aGUgcnVsZS4gV2UgaGFkIHRoYXQgZmlnaHQgYmVmb3JlPGJyPg0KUkZDNzA0NS48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluZGVlZC4gVGhlIFJGQzcwNDUgZXhjZXB0aW9uIGFw
cGxpZXMgc3BlY2lmaWNhbGx5IHRvICpleGFtaW5pbmcqIGhlYWRlcnMsIHdpdGggdGhlIGNv
bW1vbiB1c2UgY2FzZSBiZWluZyBmaXJld2FsbGluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhbmdpbmcgdGhl
IFJGQzcwNDUgZXhjZXB0aW9uIHRleHQgdG8gY2xhcmlmeSB0aGlzIGluIDI0NjBiaXMgd2Fz
IHByb3Bvc2VkLCBidXQgaXQgd2FzbuKAmXQgdGFrZW4gZm9yd2FyZC48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaW08bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QnJpYW48YnI+DQo8YnI+
DQo8YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0
ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo
OiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWYgJ2FyZSBub3QgZXhhbWluZWQmcXVvdDsgaXMg
dG8gYmUgaW50ZXJwcmV0ZWQgYXMgUkZDMjExOSAnTVVTVCBOT1QnLDxicj4NCnRoZW4gdGhl
IGZvbGxvd2luZyBub3RlIGNvbmZsaWN0cyB3aXRoIHRoYXQgc3RhdGVtZW50LiAnQSBub2Rl
IE1VU1Q8YnI+DQpOT1QgZXhhbWluZSBFSHM8YnI+DQpidXQgaWYgaXQgZG9lcyBpdCBtdXN0
IGRvIGl0IGFzIHBlciBSRkM3MDQ1JyAtIGl0IGlzIGV4dHJlbWVseSBjb250cm92ZXJzaWFs
Ljxicj4NCjxicj4NCklmICcnYXJlIG5vdCBleGFtaW5lZCZxdW90OyBpcyB0byBiZSByZWFk
IGFzIFJGQzIxMTkgJ1NIT1VMRCBOT1QnIHRoZW4gSTxicj4NCmhhdmUgYSB2ZXJ5IGdvb2Qg
bmV3cyBmb3I8YnI+DQp0aG9zZSB3aG8gd291bGQgc3RpbGwgbGlrZSB0byBpbnNlcnQvZGVs
ZXRlIEVIczogdGhleSBjYW4gZG8gaXQgJm5ic3A7YXM8YnI+DQpsb25nIGFzICZuYnNwO3Ro
ZXkgaGF2ZTxicj4NCiZxdW90O3ZhbGlkIHJlYXNvbnMgaW4gcGFydGljdWxhciBjaXJjdW1z
dGFuY2VzIHdoZW4gdGhlIHBhcnRpY3VsYXI8YnI+DQpiZWhhdmlvciBpcyBhY2NlcHRhYmxl
IG9yIGV2ZW4gdXNlZnVsLCBidXQgdGhlIGZ1bGw8YnI+DQombmJzcDsmbmJzcDtpbXBsaWNh
dGlvbnMgc2hvdWxkIGJlIHVuZGVyc3Rvb2QgYW5kIHRoZSBjYXNlIGNhcmVmdWxseSB3ZWln
aGVkPGJyPg0KJm5ic3A7Jm5ic3A7YmVmb3JlIGltcGxlbWVudGluZyBhbnkgYmVoYXZpb3Ig
ZGVzY3JpYmVkIHdpdGggdGhpcyBsYWJlbC4mcXVvdDsuPGJyPg0KQnV0IGZyb20gdG9kYXkn
cyBwcmVzZW50YXRpb24gSSd2ZSBnb3QgYW4gaW1wcmVzc2lvbiB0aGF0IHRoZTxicj4NCmlu
dGVudGlvbiBvZiB0aGlzIHRleHQgd2FzIGFjdHVhbGx5IHRvIHByb2hpYml0IEVIIGluc2Vy
dGlvbjxicj4NCih0aGUgc2lsZGVzIHNheSAnbm8gb25lIGFyZ3VlZCBhZ2FpbnN0IHRoZSBm
YWN0IHRoYXQgdGhlIGludGVudCBvZiB0aGU8YnI+DQp0ZXh0IGluIFJGQzI0NjA8YnI+DQp3
YXMgdG8gZm9yYmlkIGluc2VydGlvbiBvZiBleHRlbnNpb24gaGVhZGVycyBvbiBhbnkgb3Ro
ZXIgbm9kZSBidXQgdGhlIHNvdXJjZTxicj4NCm9mIHRoZSBwYWNrZXQuKS48YnI+DQo8YnI+
DQpTbyB0byBzdW1tYXJpemU6IHRoZSBwcm9wb3NlZCB0ZXh0IGVpdGhlciBleHBsaWNpdGx5
IHByb2hpYml0cyB0aGU8YnI+DQpleGFtaW5hdGlvbiAoYW5kIHRoZW4gaXQgY29udHJhZGlj
dHMgdGhlIG5leHQgc2VudGVuY2UgYW5kIHdlIG5lZWQgdG88YnI+DQpkbyBzbXRoIHdpdGgg
dGhlIG5vdGUgYW5kIFJGQzcwNDUpIE9SIGl0IGFsbG93cyBFSCBpbnNlcnRpb24gLSBpdDxi
cj4NCmRlcGVuZHMgaG93IHRoZSB0ZXh0IGlzIGludGVycHJldGVkLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KSUVURiBJUHY2IHdvcmtpbmcgZ3Jv
dXAgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlw
djZAaWV0Zi5vcmc8L2E+PGJyPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NiI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4NCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQoKCjxCUj4KPGh0bWw+CiA8cD5UaGUgaW5mb3JtYXRpb24g
Y29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFs
IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwo
cykgdG8gd2hvbSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUg
bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo
YXQgYW55IHZpZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9m
IHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyLCBieSBlbGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRl
ZCByZWNlaXB0IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtp
bmcgYW55IGNvcGllcy48L3A+CiA8cD5CbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hp
Z2FuIGFuZCBCbHVlIENhcmUgTmV0d29yayBvZiBNaWNoaWdhbiBhcmUgbm9ucHJvZml0IGNv
cnBvcmF0aW9ucyBhbmQgaW5kZXBlbmRlbnQgbGljZW5zZWVzIG9mIHRoZSBCbHVlIENyb3Nz
IGFuZCBCbHVlIFNoaWVsZCBBc3NvY2lhdGlvbi48L3A+CiAgPC9odG1sPgoK

--_000_BN6PR14MB136174D6D442396781347270D7370BN6PR14MB1361namp_--



From nobody Fri Mar 31 08:09:52 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A047F129412; Fri, 31 Mar 2017 08:09:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ipv6@ietf.org
Subject: I-D Action: draft-ietf-6man-rfc1981bis-05.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.49.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149097297457.4364.18046847029603602675@ietfa.amsl.com>
Date: Fri, 31 Mar 2017 08:09:34 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 15:09:35 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.

        Title           : Path MTU Discovery for IP version 6
        Authors         : Jack McCann <>
                          Stephen E. Deering <>
                          Jeffrey Mogul <>
                          Robert M. Hinden
	Filename        : draft-ietf-6man-rfc1981bis-05.txt
	Pages           : 18
	Date            : 2017-03-31

Abstract:
   This document describes Path MTU Discovery for IP version 6.  It is
   largely derived from RFC 1191, which describes Path MTU Discovery for
   IP version 4.  It obsoletes RFC1981.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-05
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-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 nobody Fri Mar 31 08:21:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0ED129417 for ; Fri, 31 Mar 2017 08:21:17 -0700 (PDT)
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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wQ_eLHKNPaaw for ; Fri, 31 Mar 2017 08:21:15 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC251298B7 for ; Fri, 31 Mar 2017 08:21:04 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id C11DFB80E34; Fri, 31 Mar 2017 08:20:51 -0700 (PDT)
To: kawamucho@mesh.ad.jp, kawashimam@vx.jp.nec.com, suresh.krishnan@ericsson.com, terry.manderson@icann.org, otroan@employees.org,  bob.hinden@gmail.com
Subject: [Technical Errata Reported] RFC5952 (4985)
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: julianedprado@gmail.com, ipv6@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170331152051.C11DFB80E34@rfc-editor.org>
Date: Fri, 31 Mar 2017 08:20:51 -0700 (PDT)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 15:21:17 -0000

The following errata report has been submitted for RFC5952,
"A Recommendation for IPv6 Address Text Representation".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=4985

--------------------------------------
Type: Technical
Reported by: Julian de Prado 

Section: 2.2

Original Text
-------------
In cases where there is more than one field of only zeros, there is a
choice of how many fields can be shortened.

2001:db8:0:0:0::1
2001:db8:0:0::1
2001:db8:0::1
2001:db8::1

Corrected Text
--------------
In cases where there is more than one field of only zeros,there is a
choice of how many fields can be shortened, but must be shortened to 
its maximum capability.

2001:db8:0:0:0::1 is NOT acceptable
2001:db8:0:0::1 is NOT acceptable
2001:db8:0::1 is NOT acceptable
2001:db8::1 is CORRECT


Notes
-----
Applying section 4.2.1

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5952 (draft-ietf-6man-text-addr-representation-07)
--------------------------------------
Title               : A Recommendation for IPv6 Address Text Representation
Publication Date    : August 2010
Author(s)           : S. Kawamura, M. Kawashima
Category            : PROPOSED STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG


From nobody Fri Mar 31 08:27:23 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01EE129417 for ; Fri, 31 Mar 2017 08:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 WhIkQRuJaAVV for ; Fri, 31 Mar 2017 08:27:15 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D92D1294FB for ; Fri, 31 Mar 2017 08:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=616; q=dns/txt; s=iport; t=1490974035; x=1492183635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5HaF/CeK6WBBqkaaSAYrKs0n7GVRR+dcQ+o94dTJQ74=; b=PaNKyQ+itFBr592oBcl93DB5eQgzUSx6Nq3p9fqi8Vt/kNqSmEMePapn b+vhZXaxmXr+Y2K6bPBO7SxZhc0mSvbspeDfbE3tSXoRy1a1N8grZlRag aykimnQkZn6wGm/1IPZxV8bJReVxg9rM7T+NlbvZB529Qb8t+sFCWAU1u 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCgdN5Y/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbI10kVWVUIIOhiICg0Y/GAECAQEBAQEBAWsohRUBAQEBAgE?= =?us-ascii?q?6PwULAgEIGB4QMiUCBA4FigUIsA2KWwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2IU?= =?us-ascii?q?4JqgTyDGIM0gjEBBJxqAZJPgWWPVZNwAR84gQVbFVIBhFSBc3WJWwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.36,252,1486425600"; d="scan'208";a="225062162"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Mar 2017 15:27:14 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2VFREfs016064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 15:27:14 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 10:27:13 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 10:27:13 -0500
From: "Bernie Volz (volz)" 
To: RFC Errata System 
CC: "kawamucho@mesh.ad.jp" , "kawashimam@vx.jp.nec.com" , "suresh.krishnan@ericsson.com" , "terry.manderson@icann.org" , "otroan@employees.org" , "bob.hinden@gmail.com" , "julianedprado@gmail.com" , "ipv6@ietf.org" 
Subject: Re: [Technical Errata Reported] RFC5952 (4985)
Thread-Topic: [Technical Errata Reported] RFC5952 (4985)
Thread-Index: AQHSqjJ+QfrDi5txKEO6wP1JRjxBoaGvEiY9
Date: Fri, 31 Mar 2017 15:27:13 +0000
Message-ID: 
References: <20170331152051.C11DFB80E34@rfc-editor.org>
In-Reply-To: <20170331152051.C11DFB80E34@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 15:27:18 -0000

What does acceptable mean?

Certainly for user input all these forms MUST be acceptable? When output ge=
nerated, the last form should be used.

But you could also argue that in some cases displaying a fixed number of co=
lon fields is useful as it increases readability - for example, displaying =
/64s with the four first colon fields even if 0.

- Bernie (from iPhone)

> On Mar 31, 2017, at 10:21 AM, RFC Errata System  wrote:
>=20
> 2001:db8:0:0:0::1 is NOT acceptable
> 2001:db8:0:0::1 is NOT acceptable
> 2001:db8:0::1 is NOT acceptable
> 2001:db8::1 is CORRECT


From nobody Fri Mar 31 08:32:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E121299AC for ; Fri, 31 Mar 2017 08:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6KzSXyIZ77PF for ; Fri, 31 Mar 2017 08:32:12 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFC212706D for ; Fri, 31 Mar 2017 08:32:09 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id y22so1633306wmh.0 for ; Fri, 31 Mar 2017 08:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:cc:to; bh=Z2K1Nx4g3N6TtVYZUjPp3PoT5TeL90R3Hv3M3D/FT/w=; b=ZHaeuzmuq4pRYXb8s+7v3ZTgntu+wzJW3UEJ6LP6v5ZhrLRzbkEZIThWZDsEXG74VF vS1v0J1AdBnYqJEK3v+VEVF0pfz3sTJ/XW2GkrPHdXjG8azbcvMy63fKakX13UZ4KNbi tYmRe62iADb69XF5QiPBe8WasVRVt4s9uwsqy1pVwzqhU+2MqNhmqak+owdePC0OIp2w oLwdwTeksanVFZ3B3WFtxre7bzv9FWTtTxFVAiZmb56CxkZm7oTGvtIhpDCqEjDyzFbt S6QyKctWWB3lk2JnD5J+alOKx0byulg39euG5jpKoGzuOKFBroOhmJI8fSh96hoyPrky qkNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=Z2K1Nx4g3N6TtVYZUjPp3PoT5TeL90R3Hv3M3D/FT/w=; b=EgB7pKiuLXG5TgNblviXRHDHI7XKTc/Ir3gdRcqkKmoXHTLIcwIygPfF5gJkUZcMxm nQ9zB+nZjloUbPqJJT5e3wFLhOGnysPnkHsRHpgUwWs5lXNSY/1bwSh1RZ0P9YWNFN0z 5BOewnyaOHHBa4Lv/pVmIAH38gn9rPzgUFVn8lzGkzmhzwDzSyvsF5mXF0eBhjSN5Q9N 2BVybs/J2xicIohL8lT35dLshOS4uTku2+OKYn3fYDgBgScoGWQhnosA1wOu0YXPqhzZ JlY4Pf/+0hrIYfnB0Xvycf/4lJ1sx6+bMyqbITp/mwaqXWTGnfhEan0GAUMGi0qr+snS /3uA==
X-Gm-Message-State: AFeK/H2jYQfmTmuQig+0O+Z4aLvjEM4+GjlOhDI0GBFv9NggqrlZf8pmjlNpQGa067+QMQ==
X-Received: by 10.28.95.85 with SMTP id t82mr3470879wmb.107.1490974328176; Fri, 31 Mar 2017 08:32:08 -0700 (PDT)
Received: from t2001067c03700128c1e8207366ca59f2.v6.meeting.ietf.org (t2001067c03700128c1e8207366ca59f2.v6.meeting.ietf.org. [2001:67c:370:128:c1e8:2073:66ca:59f2]) by smtp.gmail.com with ESMTPSA id b82sm3324116wmh.4.2017.03.31.08.32.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 08:32:07 -0700 (PDT)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_74D19CC5-9530-4D54-94A7-69CE3DFBF965"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: 
Message-Id: 
Date: Fri, 31 Mar 2017 10:32:02 -0500
Cc: Bob Hinden 
To: IPv6 List 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 15:32:14 -0000

--Apple-Mail=_74D19CC5-9530-4D54-94A7-69CE3DFBF965
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

I published a new version of rfc1981bis (-05).  Links to the document =
below.

The changes in this version are based on comments in IETF last call =
reviews by Gorry Fairhurst, Joe Touch, Susan Hares, Stewart Bryant, =
Rifaat Shekh-Yusef, and Donald Eastlake.  Many thank to the reviewers as =
I think the document is significantly improved, it is much better =
aligned with current transport practice.

The changes include:

   o  Clarify that the purpose of PMTUD is to reduce the need
      for IPv6 Fragmentation.

   o  Added text to Introduction about effects on PMTUD when
      ICMPv6 messages are blocked.

   o  Clarified in Section 4. that nodes should validate the
      payload of ICMPv6 PTB messages per RFC4443.

   o  Removed text in Section 5.2 about the number of paths to a
      destination.

   o  Changed title of Section 5.4 to "Packetization layer
      actions".

   o  Clarified first paragraph in Section 5.4 to to cover all
      packetization layers, not just TCP.

   o  Clarified text in Section 5.4 to use normal retransmission
      methods.

   o  Add clarification to Note in Section 5.4 about
      retransmissions.

   o  Removed text in Section 5.4 that described 4.2BSD as it is
      now obsolete.

   o  Removed reference to TP4 in Section 5.5.

   o  Updated text in Section 5.5 about NFS including adding a
      current reference to NFS and removing obsolete text.

   o  Revised text in Section 6 to clarify first attack
      response.

   o  Added new text in Section 6 to clarify the effect of
      ICMPv6 filtering on PMTUD.

   o  Aligned terminology for the packetization layer
      terminology.

   o  Editorial changes.

A diff from the previous version can be found at:

   https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-05.txt=


Please review.

This is part of the project to move the core IPv6 specifications to =
Internet Standard.

Thanks,
Bob

> A new version of I-D, draft-ietf-6man-rfc1981bis-05.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-6man-rfc1981bis
> Revision:	05
> Title:		Path MTU Discovery for IP version 6
> Document date:	2017-03-31
> Group:		6man
> Pages:		18
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-05.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-05
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-05
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-05
>=20
> Abstract:
>   This document describes Path MTU Discovery for IP version 6.  It is
>   largely derived from RFC 1191, which describes Path MTU Discovery =
for
>   IP version 4.  It obsoletes RFC1981.



--Apple-Mail=_74D19CC5-9530-4D54-94A7-69CE3DFBF965
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJY3nZzAAoJEK7rdBF357uoyYEH/0gVVG7TCVV3+zK1aBxRDqjq
yOPXD0JZPty/n9ySCQOC/HIvHvOrmOHpcQrqoxRaCcTZ1LpY8IoSOYWsqWnxSgVr
HaMbgaFYb5yQC9ubZJm6S4PZg0p86UAwThEQjuLGLl5zRKVx2rrnhI/vr+GwKOHo
WeFxAXZs276Rxl1TdQi+1LF/Sg0B4+fLavQAbtf/AUzs1Azg6xz947Vw2glGosxv
JpLkK9eLWDhPdOWBzmVtHP9y7Y3uFvhMrV5Ydo7ykVIycru+s57H373mcIXDOQEg
kCqqLwvdXn6OQxlKC8sfNZ5kHrZHfcmzg9Gu8/y2sgvSYyYjlZ9NQr2FIVERpZE=
=oRWF
-----END PGP SIGNATURE-----

--Apple-Mail=_74D19CC5-9530-4D54-94A7-69CE3DFBF965--


From nobody Fri Mar 31 08:32:35 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6EA126DED; Fri, 31 Mar 2017 08:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 NSV42uKaG3es; Fri, 31 Mar 2017 08:32:21 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F6C1299D2; Fri, 31 Mar 2017 08:32:16 -0700 (PDT)
X-AuditID: c618062d-767ff700000029b8-3a-58de8830ac8f
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by  (Symantec Mail Security) with SMTP id 98.A7.10680.0388ED85; Fri, 31 Mar 2017 18:47:45 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Fri, 31 Mar 2017 11:32:14 -0400
From: Suresh Krishnan 
To: Robert Raszuk 
CC: Brian E Carpenter , "Leddy, John" , IETF Discussion , 6man WG , Ole Troan , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv86cghjjmGk6P6rsvHH5Q4qGssVmAgAD+BwCAAAesgIAAIVmAgAAFgwCAAASPgIAAEkGAgABB5oCAAAHpgIAAAteAgAACGICAAAp2gIABEiqAgAAWegA=
Date: Fri, 31 Mar 2017 15:32:13 +0000
Message-ID: <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.12]
Content-Type: multipart/signed; boundary="Apple-Mail=_A461DC2B-1DEF-4AE4-945C-CF3E030DF34B"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUyuXRPiK5hx70Igx8v+SzaLu5jsnj19hqb xbON81ksXp59z2SxdMFyJovJbSvYLJoWNjE7sHtc72xh9jh47COjx85Zd9k9liz5yeSxe+MC pgDWKC6blNSczLLUIn27BK6M76tvsRasd62Y8OQ+ewPjfYcuRk4OCQETiX3PjzJ3MXJxCAls YJQ4uPMMI4SznFHi8ZttjCBVbEBVG3Z+ZgKxRQRUJTpPPALrYBaYwiSx6NI/sISwgIfEpE3X WCCKPCXWbTzMAlIkItDFKPH69nlWkAQLUPfrKQ/AbF4Be4ndf7cxQaxrYJeYePU12DpOgUCJ TX/3ghUxCohJfD+1BmwDs4C4xK0n85kgDheReHjxNBuELSrx8vE/VghbSWLO62vMEPVTGCUW rgyGWCYocXLmE5YJjCKzkIyahaRsFpKyWYwcQPEkiYerEyFKtCWWLXzNDBHWkZi8kBFVGML+ eP4I1ERTiddHP0LVWEvM+HWQDcJWlJjS/ZB9ASP3KkaO0uKCnNx0I4NNjMCIPybBpruD8f50 z0OMAhyMSjy8DxLuRQixJpYVV+YeYlQBan20YfUFRimWvPy8VCURXpkcoDRvSmJlVWpRfnxR aU5q8SFGaQ4WJXHeCecvRAgJpCeWpGanphakFsFkmTg4pRoYq3/rFxybYvn918KLs6deTzD5 cGUl707nZb8LcybqdK6w1f47mb1zY8eqAxJvtjx7vzY4ydC0/eAUpZ9X0jQLev/y8NTPUdkv 3C3lvvd9tse+nNCZ94u8eS3Nb/w+N+ud8zZm14kfi6pPp87Ov/tJK1cqKsf1Q9z9tDl3H4dL Pdp64Z7MZNkUdiWW4oxEQy3mouJEAJJ12X8AAwAA
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 15:32:26 -0000

--Apple-Mail=_A461DC2B-1DEF-4AE4-945C-CF3E030DF34B
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BFFE424B-2FB0-4176-9E61-E493C3568574"


--Apple-Mail=_BFFE424B-2FB0-4176-9E61-E493C3568574
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Robert,

> On Mar 31, 2017, at 9:11 AM, Robert Raszuk  wrote:
>=20
> I do not understand how 2460bis makes it "easier" if proposed change =
to the text directly tries to prohibit what is described in a document =
already long time back accepted as a 6man working group draft.

First of all, adopting something as a working group document only means =
that it is a starting point. Adoption of a document does not mean that =
there is WG agrees with all the text in the document. That is why the =
document goes under WG change control.
Secondly, I have no idea what you are talking about in this specific =
case. What work in=20

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 =


do you think is prohibited by this text? Can please provide a text quote =
from the draft?

Thanks
Suresh


--Apple-Mail=_BFFE424B-2FB0-4176-9E61-E493C3568574
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi Robert,

    On Mar 31, 2017, at 9:11 AM, =
Robert Raszuk <robert@raszuk.net> wrote:

    I do not understand how 2460bis =
makes it "easier" if proposed change to the text directly tries to =
prohibit what is described in a document already long time back accepted =
as a 6man working group draft.

    First of all, adopting something as a working group =
document only means that it is a starting point. Adoption of a document =
does not mean that there is WG agrees with all the text in the document. =
That is why the document goes under WG change =
control.
    Secondly, I have no idea what you are talking about =
in this specific case. What work in 


    do you think is =
prohibited by this text? Can please provide a text quote from the =
draft?

    Thanks
    Suresh

    =

--Apple-Mail=_BFFE424B-2FB0-4176-9E61-E493C3568574--

--Apple-Mail=_A461DC2B-1DEF-4AE4-945C-CF3E030DF34B
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw
ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy
aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5
MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz
aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ
MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C
oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg
ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+
SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI
MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O
nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6
Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG
AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp
ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD
VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5
LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G
yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL
B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU
Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc
4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG
H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn
78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r
WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz
Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO
NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb
Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR
AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3
MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp
ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1
3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE
9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp
usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq
qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um
0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI
4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N
V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta
IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj
NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB
igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy
YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv
bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww
SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50
ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50
ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/
SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H
IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp
Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG
x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj
9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55
JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj
SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk
9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7
RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA
Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC
mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzMxMTUzMjEzWjAjBgkqhkiG9w0B
CQQxFgQUTL1nWk5PSpb4YxqzbBr1uL6fVjgwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF
cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa
99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG
9w0BAQEFAASCAQAlRTEjc+BQZ16I3q7Q0ojPALtrinLw3kpap+WmpWA6UB1jGVlGWUePSTFbyg6a
Na4LlRoMeuCEwee+DBH+PnqzwKbyeBxv2Y1vyY3Y0yckMtAQP7+LeV2UqWn6WDSv2DLuCEcqe6ap
hGO/u5iOaQMSsoUczmrHqzmJfxzAipay9nfbbkeCDsR7jIQvT19Z1ZvdspKCodx6dymX/M4BV0j5
R6iU1nloKqmwKqINUwrLScsjfzfZbhbOsgJKE/dPsHsJnVAa0uS76p4PAA9CSun/ltvzz9wBCwSI
sL2YyfFPy8KKWzOVYqQpS596Nad1wvGWqWC3vBnbXbhuTMGAPJilAAAAAAAA

--Apple-Mail=_A461DC2B-1DEF-4AE4-945C-CF3E030DF34B--


From nobody Fri Mar 31 08:52:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1F91294C0 for ; Fri, 31 Mar 2017 08:52:29 -0700 (PDT)
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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 CRGbxBmGQlMY for ; Fri, 31 Mar 2017 08:52:27 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19569129435 for ; Fri, 31 Mar 2017 08:52:24 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 7C444B81110; Fri, 31 Mar 2017 08:52:11 -0700 (PDT)
To: kawamucho@mesh.ad.jp, kawashimam@vx.jp.nec.com, suresh.krishnan@ericsson.com, terry.manderson@icann.org, otroan@employees.org,  bob.hinden@gmail.com
Subject: [Editorial Errata Reported] RFC5952 (4986)
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: julianedprado@gmail.com, ipv6@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170331155211.7C444B81110@rfc-editor.org>
Date: Fri, 31 Mar 2017 08:52:11 -0700 (PDT)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 15:52:29 -0000

The following errata report has been submitted for RFC5952,
"A Recommendation for IPv6 Address Text Representation".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=4986

--------------------------------------
Type: Editorial
Reported by: Julian de Prado 

Section: 2.2

Original Text
-------------
'A special syntax is available to compress the zeros. The use of
"::" indicates one or more groups of 16 bits of zeros.'


Corrected Text
--------------
'A special syntax is available to compress the zeros. The use of
"::" indicates two or more groups of 16 bits of zeros.'



Notes
-----
"indicates one" should be written as "indicates two"

 for example:
'A special syntax is available to compress the zeros. The use of
"::" indicates two or more groups of 16 bits of zeros.'

2001:db8:aaaa:bbbb:cccc::1

2001:db8:aaaa:bbbb:cccc:0:0:1

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5952 (draft-ietf-6man-text-addr-representation-07)
--------------------------------------
Title               : A Recommendation for IPv6 Address Text Representation
Publication Date    : August 2010
Author(s)           : S. Kawamura, M. Kawashima
Category            : PROPOSED STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG


From nobody Fri Mar 31 09:07:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494EB129474 for ; Fri, 31 Mar 2017 09:07:32 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 tq4bB-ce9Lu1 for ; Fri, 31 Mar 2017 09:07:30 -0700 (PDT)
Received: from mx.go6lab.si (mx.go6lab.si [91.239.96.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AEC124281 for ; Fri, 31 Mar 2017 09:07:29 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 1DC1963E81; Fri, 31 Mar 2017 18:07:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id wWYlYbA9Kzx8; Fri, 31 Mar 2017 18:07:26 +0200 (CEST)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id C3EC863859; Fri, 31 Mar 2017 18:07:26 +0200 (CEST)
Received: from ISOC-BMDKQ4.local (unknown [91.239.97.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 73C6783505; Fri, 31 Mar 2017 18:07:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1490976446; bh=qzVv0PUOPAXHsVNOVRlmXmI7CYs3QMBVCHCwVAxYKHU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=l+CZ5pKU93ToKPFiuWgmcKArNyV9eKdxytR8FeW67n9/Esf69Wl9FJKmDHtax7Hti GamDxwD/GQY0axAz9UuMQBzomKSespzGOaLcujWiOdYBhvSiXJOABXn/J+Byi56KQe vNjmg5dS87nZOGJUkqsLEH08fw28Dce1cdNYn/bA=
Subject: Re: [Editorial Errata Reported] RFC5952 (4986)
To: RFC Errata System , kawamucho@mesh.ad.jp, kawashimam@vx.jp.nec.com, suresh.krishnan@ericsson.com, terry.manderson@icann.org, otroan@employees.org, bob.hinden@gmail.com
References: <20170331155211.7C444B81110@rfc-editor.org>
Cc: julianedprado@gmail.com, ipv6@ietf.org
From: Jan Zorz - Go6 
Message-ID: 
Date: Fri, 31 Mar 2017 18:07:24 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170331155211.7C444B81110@rfc-editor.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 16:07:32 -0000

On 31/03/2017 17:52, RFC Errata System wrote:
> Original Text
> -------------
> 'A special syntax is available to compress the zeros. The use of
> "::" indicates one or more groups of 16 bits of zeros.'
>
>
> Corrected Text
> --------------
> 'A special syntax is available to compress the zeros. The use of
> "::" indicates two or more groups of 16 bits of zeros.'
>
>
>
> Notes
> -----
> "indicates one" should be written as "indicates two"
>
>  for example:
> 'A special syntax is available to compress the zeros. The use of
> "::" indicates two or more groups of 16 bits of zeros.'
>
> 2001:db8:aaaa:bbbb:cccc::1
>
> 2001:db8:aaaa:bbbb:cccc:0:0:1

Hi,

I don't agree with errata entirely.

2001:db8:aaaa:bbbb:cccc:dddd::1 expands to 2001:db8:aaaa:bbbb:cccc:dddd:0:1

So it's one or more groups of 16 bits of zeros.

Cheers, Jan Zorz

>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5952 (draft-ietf-6man-text-addr-representation-07)
> --------------------------------------
> Title               : A Recommendation for IPv6 Address Text Representation
> Publication Date    : August 2010
> Author(s)           : S. Kawamura, M. Kawashima
> Category            : PROPOSED STANDARD
> Source              : IPv6 Maintenance
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


From nobody Fri Mar 31 09:21:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABDF129A32 for ; Fri, 31 Mar 2017 09:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4haYlidA9ert for ; Fri, 31 Mar 2017 09:21:37 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20346129A20 for ; Fri, 31 Mar 2017 09:21:36 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id w43so110348925wrb.0 for ; Fri, 31 Mar 2017 09:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YOEGgNBjhtRsVf51ZtTDCN8Hy05lNVbd0S1X77+Vf2s=; b=VdrO0U1VHd3R6WcHrX2Xf5DVJIJzx1ubGR4qvG59/J3Kvr9qMSCK/rXVG7R38swGqv 3krSJ8D3TbSlX18yHWmVSdDg7t7pMJPEB84nTs2x+ioKJHVrljmbJ7tOZd+VVTNEzV/1 2ZYCoy0ATgriQ1eL0k95j6+MMPID3jbm/zZsED6uOb946bAPIYXPIuP9i/RoKVRtn0Um ylYDesDLg1XqnprAyaJoU6vU+OTTRyUeudz3FG0f3NtmD+kUA6zZ5YPYkUqs5XuLq5Mw twE3RgFM7BVHqdNWyktmr6s8QTUtv2Q+9Kon55wmF/HbsZVds4qHkmogShXG5CZWtnu4 SULA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YOEGgNBjhtRsVf51ZtTDCN8Hy05lNVbd0S1X77+Vf2s=; b=hQtSN5cer+Cb4tA9xhnFjtNoAOgEk7Un1CMtneiexOLfW126UyNVXspCwqDfPP6Jdl gSQq5Bz+6dVMGJYGQGe1tFBdWsvawpcGwOMonj0x/2ykWirlFYQmNvhcAhWljXITusZ6 iCkQqTY5j8t6dkBcugYGOsaxioTxBXjv6ppWC1Z4ZC6vl3r8aDzMJVhSK2yEAJhMTS4t 6jkH6OaPQajty5yIuNfD90jemwxyGv/l7Iz2OXUVUF14QYD+8AJZXaL3lkhhg5ONEzBJ tN9nomA7MsHmGh6TXv9/caTOaPphRJbu9W8g1S/Ynj80jRl1UVtEs5rCmfUviF2/CuP4 BK8A==
X-Gm-Message-State: AFeK/H0yhU8F2+/fA3igYlULXTinDTq+4Tl4cmcn9ZIy3tBUJ2vq2KvfugSjgC2lNVukJA==
X-Received: by 10.223.166.46 with SMTP id k43mr3929455wrc.64.1490977294601; Fri, 31 Mar 2017 09:21:34 -0700 (PDT)
Received: from dhcp-9201.meeting.ietf.org (dhcp-9201.meeting.ietf.org. [31.133.146.1]) by smtp.gmail.com with ESMTPSA id g141sm3468016wmd.10.2017.03.31.09.21.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 09:21:33 -0700 (PDT)
From: Bob Hinden 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_BCBDD121-1B77-4676-B342-EF3C01C446A3"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [Editorial Errata Reported] RFC5952 (4986)
Date: Fri, 31 Mar 2017 11:21:28 -0500
In-Reply-To: <20170331155211.7C444B81110@rfc-editor.org>
Cc: Bob Hinden , kawamucho@mesh.ad.jp, kawashimam@vx.jp.nec.com, Suresh Krishnan , Terry Manderson , =?utf-8?Q?Ole_Tr=C3=B8an?= , julianedprado@gmail.com, IPv6 List 
To: RFC Errata System 
References: <20170331155211.7C444B81110@rfc-editor.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 16:21:39 -0000

--Apple-Mail=_BCBDD121-1B77-4676-B342-EF3C01C446A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

> On Mar 31, 2017, at 10:52 AM, RFC Errata System =
 wrote:
>=20
> The following errata report has been submitted for RFC5952,
> "A Recommendation for IPv6 Address Text Representation".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D5952&eid=3D4986
>=20
> --------------------------------------
> Type: Editorial
> Reported by: Julian de Prado 
>=20
> Section: 2.2
>=20
> Original Text
> -------------
> 'A special syntax is available to compress the zeros. The use of
> "::" indicates one or more groups of 16 bits of zeros.'
>=20
>=20
> Corrected Text
> --------------
> 'A special syntax is available to compress the zeros. The use of
> "::" indicates two or more groups of 16 bits of zeros.'
>=20
>=20

That is not correct.  RFC4291, where the =E2=80=9C::=E2=80=9D syntax is =
defined, says in Section 2.2:

   2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates one or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress leading or trailing zeros in an address.

Bob


>=20
> Notes
> -----
> "indicates one" should be written as "indicates two"
>=20
> for example:
> 'A special syntax is available to compress the zeros. The use of
> "::" indicates two or more groups of 16 bits of zeros.'
>=20
> 2001:db8:aaaa:bbbb:cccc::1
>=20
> 2001:db8:aaaa:bbbb:cccc:0:0:1
>=20
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>=20
> --------------------------------------
> RFC5952 (draft-ietf-6man-text-addr-representation-07)
> --------------------------------------
> Title               : A Recommendation for IPv6 Address Text =
Representation
> Publication Date    : August 2010
> Author(s)           : S. Kawamura, M. Kawashima
> Category            : PROPOSED STANDARD
> Source              : IPv6 Maintenance
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG


--Apple-Mail=_BCBDD121-1B77-4676-B342-EF3C01C446A3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJY3oIJAAoJEK7rdBF357uo0cgH/RMq4DlGvGsxXwDPtm1TmF/J
0IZfeAZ1f1P7f72wNPqyeZOQJViECCY1bqzgfHhGF0mb4RG25O/yxF6YhRnZoRkn
c8adDGw0g4XI8GtYyQLJx2DiuP69P0EMIB/hZ74T0x2aJXAJ6N/c8L7+zJUHVRAf
ECdbMDVq7emoP8817lyh81gSBh/alDuDja4wJ/72980ZAIrDdvrktxDCO5PkcnfS
pKaCdVhY2B3wVAF4wHMFqodL4F8I1BxRtaAmUING+JH25EzOS/Isd46CqItewwfY
VXu0Y8nO0FxTYrdmfNy2VyZsW/hV6zOnXqOO+9HR+uTDnBKIPbndhuJs4fFVUfo=
=EY43
-----END PGP SIGNATURE-----

--Apple-Mail=_BCBDD121-1B77-4676-B342-EF3C01C446A3--


From nobody Fri Mar 31 09:29:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452A712922E for ; Fri, 31 Mar 2017 09:29:00 -0700 (PDT)
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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
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 ih1vSGYsfUJ8 for ; Fri, 31 Mar 2017 09:28:58 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C280B128BE1 for ; Fri, 31 Mar 2017 09:28:54 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id CDEB17A772 for ; Fri, 31 Mar 2017 12:28:52 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=Bi8 lURgJUVFet/QQwsKuMLEIRGQ=; b=H0Ibpq06PDTOL5Z2peiCmG0SJRUUnIfGsjx HtvjJNvSSAlQkT8tjZCLBssUzmd3pWd6KrCDjnELhTmI78QoajNtO0eidjp2/7oe uhHQP12bCIKQf/yQGtnwXE2a3qClKXASmvaV3R+njNcghPezOkz4UtRLliR/Hxma a1mxnEjo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= fIqTsbO/KYwhd7l4ZRdwotHPJjmQPEjWDdhknA3qeJq+LuHiDnidZJnpAIkpuiif zzTIB77RJJwKRgb0sQhHRnbTcha2All43smrV7J+c00GHXXjnrpyTK20T/rzuP6t ibZ0/+yaeZDxRNh76Q3/1NUQrDZWGcPw/Bsn4qhRQQw=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C6B1A7A771 for ; Fri, 31 Mar 2017 12:28:52 -0400 (EDT)
Received: from mail-qt0-f172.google.com (unknown [209.85.216.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 57CE47A76E for ; Fri, 31 Mar 2017 12:28:52 -0400 (EDT)
Received: by mail-qt0-f172.google.com with SMTP id x35so69623066qtc.2 for ; Fri, 31 Mar 2017 09:28:52 -0700 (PDT)
X-Gm-Message-State: AFeK/H0XluWCkougjLbawxlB0VUuLFhkWICb8vh4Zr1k9mMYcSGtJF6qporkVGX2/uDXZ0+BmWyNGbrHTXTQIw==
X-Received: by 10.237.42.21 with SMTP id c21mr3572341qtd.11.1490977731809; Fri, 31 Mar 2017 09:28:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.18.75 with HTTP; Fri, 31 Mar 2017 09:28:31 -0700 (PDT)
From: "C. M. Heard" 
Date: Fri, 31 Mar 2017 09:28:31 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: 
To: Bob Hinden , 6man WG 
Cc: Suresh Krishnan 
Content-Type: text/plain; charset=UTF-8
X-Pobox-Relay-ID: 20907B3C-162F-11E7-834A-97B1B46B9B0B-06080547!pb-smtp1.pobox.com
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 16:29:00 -0000

I support the change to the Introduction proposed below by Brian Carpenter.

In addition, I raised an issue during last call that may have been
missed because I didn't keep the original subject line. Please see
https://www.ietf.org/mail-archive/web/ipv6/current/msg26129.html,
where I suggested that the NOTE in Section 4 be changed as follows:

OLD:
   NOTE: While [RFC2460] required that all nodes must examine and
   process the Hop-by-Hop Options header, it is now expected that nodes
   along a packet's delivery path only examine and process the Hop-by-
   Hop Options header if explicitly configured to do so.

NEW:
   NOTE: While [RFC2460] required that all nodes must examine and
   process the Hop-by-Hop Options header, it is now expected that nodes
   along a packet's delivery path, other than the source and destination
   nodes, will examine and process the Hop-by-Hop Options header only if
   explicitly configured to do so.

The existing text seems to say that it is expected that hosts, as well as
intermediate systems, will examine HbH options only if explicitly configured
to do so, and I don't think that was the intent -- the issues that  forwarding
nodes have with HbH options don't really apply to hosts. If the intent was
indeed for the NOTE to apply to source and destination nodes, it might be
useful to emphasize that e.g. by changing "other than" to "including" in the
proposed new text.

Thank & regards,

Mike Heard

On Fri, 31 Mar 2017 03:13:53 +1300, Brian E Carpenter wrote:
> Proposed text change near the end of the Introduction:
>
> OLD:
>    This document specifies the basic IPv6 header and the initially-
>    defined IPv6 extension headers and options.
>
> NEW:
>    This document specifies the basic IPv6 header and the initially-
>    defined IPv6 extension headers and options required for interoperable
>    communication between any two nodes on the Internet.
>
> Regards
>    Brian
>
> On 31/03/2017 02:35, Bob Hinden wrote:
>> Hi,
>>
>> I published the -09 version of 6man working group draft of rfc2460bis.  Links below.
>>
>> The changes in this draft are:
>>
>>       Based on results of IETF last call, changed text in Section 4
>>       to add clarification that extension headers are not examined,
>>       processed, inserted, or deleted by any node along a packet's
>>       delivery path.
>>
>>       Changed reference from draft-ietf-6man-rfc4291bis to RFC4291
>>       because the bis draft won't be advanced as the same time.
>>
>>       Revised "Changes since RFC2460" Section to have a summary of
>>       changes since RFC2460 and a separate subsection with a change
>>       history of each Internet Draft.  This subsection will be
>>       removed when the RFC is published.
>>
>>       Editorial changes.
>>
>> A diff from the -08 version can be found at:
>>
>>    https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09
>>
>> Please review the changes.
>>
>> This is part of the project to move the core IPv6 specifications to Internet Standard.
>>
>> Thanks,
>> Bob
>>
>>> A new version of I-D, draft-ietf-6man-rfc2460bis-09.txt
>>> has been successfully submitted by Robert M. Hinden and posted to the
>>> IETF repository.
>>>
>>> Name: draft-ietf-6man-rfc2460bis
>>> Revision: 09
>>> Title: Internet Protocol, Version 6 (IPv6) Specification
>>> Document date: 2017-03-30
>>> Group: 6man
>>> Pages: 41
>>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-09.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
>>> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-09
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-09
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09
>>>
>>> Abstract:
>>>   This document specifies version 6 of the Internet Protocol (IPv6).
>>>   It obsoletes RFC2460
>>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6 at ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>


From nobody Fri Mar 31 10:01:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A9B12952D; Fri, 31 Mar 2017 10:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sS-g-53bFbVE; Fri, 31 Mar 2017 10:01:21 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211921296F3; Fri, 31 Mar 2017 10:01:19 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id b140so43552657iof.1; Fri, 31 Mar 2017 10:01:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9qjhjtCeTYXuHOp5Wo3BLOJDBEPWwB3KoS9zdKWxDO0=; b=KKwUfPosKyxTyEuetMwCnTaZsAXgrYMKsyy8YLwtuvu1r4mvpo6t68cLjBlAjDFWDr 9CfJRz3s+oRN6y8i4TjEBn7f43AwD05cxWk693ZymX+ZWthaE+9vCn3/RUNSoLTOxwxQ iBpcNb/4WXBmYuoNrP+9myY+U8ELAiqjsicOEzgDc7lDYJI07TuIQGhiiQobKLxaf8EE iuKBpSFu6AHvZ5KZwuyX73qMp/olFCgf3fJ7LhBeQHkhspyr9Vv85Bxbx+4sY7q4i0Dy HK5y8IrpyksfveyU7R73vtm4bWXPruuei1v4vBSgJSr3VPGhq2GT3pa0sPjgLWOgJrs0 GEZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9qjhjtCeTYXuHOp5Wo3BLOJDBEPWwB3KoS9zdKWxDO0=; b=lSU1uIIiDfd6v1b+w1V8junsB8TzQ+M1qB0v66hkyzwGVcDfbaKag1V1UjSEvNzIa5 8KAf8M/r3ZeHhUk4ymdiYG5u9s7mC4n0PDJDP4x+0FEBMLGWGcDNHhnuIw14m7bWwioc j985pdiVXaYz+2ZemwL7UTI96hu+gwbYH2hHTDrHne7OfveyIIFZDNw2IFcrg0veYhvq jRnVayxotYkqqm7n4R0ATy5iZmQQ1whH+YGfOsPFziv7NVzJX4EGj4aj7xWdPBwWHG/z Io8Lffbd3z6IyqMJRtAb5T5GYY8KjoQGxqwClSKXEZIDadTckh4T9BriOGIm3pE3/lWW xZ9g==
X-Gm-Message-State: AFeK/H3YxafR3O8o70uJFbCe2MsEi3WC12umHYd0khHDqlKncLoMQCdlya+exxzAdDNlfVMhfsYdWV955wicIA==
X-Received: by 10.107.7.29 with SMTP id 29mr4357994ioh.57.1490979678464; Fri, 31 Mar 2017 10:01:18 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 10:01:17 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 10:01:17 -0700 (PDT)
In-Reply-To: <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>  <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com>
From: Robert Raszuk 
Date: Fri, 31 Mar 2017 12:01:17 -0500
X-Google-Sender-Auth: E6x5kIRftUWjxojt1TDqHM_CxjE
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Suresh Krishnan 
Cc: "Leddy, John" , otroan@employees.org,  IETF Discussion , 6man WG ,  Brian E Carpenter ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113ea6f01a39d7054c09c2ad
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 17:01:23 -0000

--001a113ea6f01a39d7054c09c2ad
Content-Type: text/plain; charset=UTF-8

Hi Suresh,

As you requested one of many quotes from the draft which your clarification
to 2460bis directly contradicts with:

This include either:

      A host originating an IPv6 packet.

      *An SR domain ingress router encapsulating a received IPv6 packet
      into an outer IPv6 header followed by an SRH.*


Cheers,
R.

On Mar 31, 2017 10:32, "Suresh Krishnan" 
wrote:

> Hi Robert,
>
> On Mar 31, 2017, at 9:11 AM, Robert Raszuk  wrote:
>
> I do not understand how 2460bis makes it "easier" if proposed change to
> the text directly tries to prohibit what is described in a document already
> long time back accepted as a 6man working group draft.
>
>
> First of all, adopting something as a working group document only means
> that it is a starting point. Adoption of a document does not mean that
> there is WG agrees with all the text in the document. That is why the
> document goes under WG change control.
> Secondly, I have no idea what you are talking about in this specific case.
> What work in
>
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06
>
> do you think is prohibited by this text? Can please provide a text quote
> from the draft?
>
> Thanks
> Suresh
>
>

--001a113ea6f01a39d7054c09c2ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Hi Suresh,

    A=
s you requested one of many quotes from the draft which your clarification =
to 2460bis directly contradicts with:

    This include either:

      A host originating an IPv6 packet.

      An SR domain ingress router encapsulating a received IPv6 packet
      into an outer IPv6 header followed by an SRH.


    Cheers,
    R.

    On Mar 31, 20=
17 10:32, "Suresh Krishnan" <suresh.krishnan@ericsson.com> wrote:
    =
Hi Robert,

    On Mar 31, 2017, at =
9:11 AM, Robert Raszuk <robert@raszuk.net> wrote:

    I do not understand =
how 2460bis makes it "easier" if proposed change to the text dire=
ctly tries to prohibit what is described in a document already long time ba=
ck accepted as a 6man working group draft.
    First of all, adopting something as a working group document only me=
ans that it is a starting point. Adoption of a document does not mean that =
there is WG agrees with all the text in the document. That is why the docum=
ent goes under WG change control.
    Secondly, I have no idea what y=
ou are talking about in this specific case. What work in=C2=A0

    do =
you think is prohibited by this text? Can please provide a text quote from =
the draft?

    Thanks
    Suresh

    

--001a113ea6f01a39d7054c09c2ad--


From nobody Fri Mar 31 10:46:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5F412988C; Fri, 31 Mar 2017 10:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 X87Yz6StGMgj; Fri, 31 Mar 2017 10:46:48 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200EC12948F; Fri, 31 Mar 2017 10:46:48 -0700 (PDT)
X-AuditID: c6180641-417ff700000058cf-50-58de4facf229
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by  (Symantec Mail Security) with SMTP id B5.7C.22735.DAF4ED85; Fri, 31 Mar 2017 14:46:39 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0339.000; Fri, 31 Mar 2017 13:46:44 -0400
From: Suresh Krishnan 
To: Robert Raszuk 
CC: "Leddy, John" , Ole Troan ,  IETF Discussion , 6man WG , Brian E Carpenter , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv86cghjjmGk6P6rsvHH5Q4qGssVmAgAD+BwCAAAesgIAAIVmAgAAFgwCAAASPgIAAEkGAgABB5oCAAAHpgIAAAteAgAACGICAAAp2gIABEiqAgAAWegCAABjkgIAADLGA
Date: Fri, 31 Mar 2017 17:46:43 +0000
Message-ID: <3A7C2C05-8513-4248-82F3-15CC9C75B69E@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>  <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.12]
Content-Type: multipart/signed; boundary="Apple-Mail=_7E69E3EA-DE0B-4FD6-8576-37651C4090B8"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUyuXSPn+56/3sRBovP8Vq0XdzHZPHq7TU2 i2cb57NYvDz7nsli6YLlTBaT21awWTQtbGJ2YPe43tnC7HHw2EdGj52z7rJ7LFnyk8lj98YF TAGsUVw2Kak5mWWpRfp2CVwZK18/ZC+Y4lCx+dBulgbGVTZdjJwcEgImEufX7mHsYuTiEBLY wCgx+dA5VghnOaPE6n+rWECq2ICqNuz8zARiiwioSnSeeMQMYjMLTGKS+PHYBMQWFvCQmLTp GgtEjafEuo2HWUAGiQhMY5TYNu8dK0iCBaj588nl7CA2r4C9xIxf96FW/2WXWDD9KVgRp0Cg xPmZk8AmMQqISXw/tYYJYpu4xK0n85kg7haReHjxNBuELSrx8vE/VghbSWLO62vMIEOZBaYw Svy+cpwFYpugxMmZT1gmMIrMQjJrFrK6WUjqIIqSJJp27meFsLUlli18zTyLkQPI1pGYvJAR Iiwvsf3tHGaYko/njzBB2KYSr49+hKqxBnr0IBuErSgxpfsh+wJG7lWMHKXFBTm56UaGmxiB UX9Mgs1xB+PeXs9DjAIcjEo8vAs07kUIsSaWFVfmHmJUAWp9tGH1BUYplrz8vFQlEV6ZHKA0 b0piZVVqUX58UWlOavEhRmkOFiVx3nflFyKEBNITS1KzU1MLUotgskwcnFINjJN/ObF/XHBA oUbro7lPQcKer3eqPZ6bcF5RZ+rVVr3A9kXjrHKT/fbn/roND9lOMD9XOhXzwav5C5NGaPnh oNVau5r31knZJKlJXXnlMGNWldOfHI/Ss+v9Cqvm3uqO7Ga3muIZfd/tZeazQq+S/OfZLgwd uYFNEQu3i94QZNU7VbH+Vz+fEktxRqKhFnNRcSIAdxVxkAIDAAA=
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 17:46:50 -0000

--Apple-Mail=_7E69E3EA-DE0B-4FD6-8576-37651C4090B8
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4E95FC54-F505-4B9C-8079-4C3CB7615A7E"


--Apple-Mail=_4E95FC54-F505-4B9C-8079-4C3CB7615A7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Robert,

> On Mar 31, 2017, at 12:01 PM, Robert Raszuk  wrote:
>=20
> Hi Suresh,
>=20
> As you requested one of many quotes from the draft which your =
clarification to 2460bis directly contradicts with:
>=20
> This include either:
>=20
>       A host originating an IPv6 packet.
>=20
>       An SR domain ingress router encapsulating a received IPv6 packet
>       into an outer IPv6 header followed by an SRH.

Excellent. Thanks for pointing out the exact text. I can confirm that =
this text  *is compliant* with the RFC2460bis text.

Thanks
Suresh


--Apple-Mail=_4E95FC54-F505-4B9C-8079-4C3CB7615A7E
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Hi Robert,

    On Mar 31, 2017, at 12:01 PM, Robert Raszuk <robert@raszuk.net> wrote:

    Hi Suresh,

    As you requested one of many quotes from the draft which your clarification to 2460bis directly contradicts with:

    This include either:

      A host originating an IPv6 packet.

      An SR domain ingress router encapsulating a received IPv6 packet
      into an outer IPv6 header followed by an SRH.


    Excellent. Thanks for pointing out the exact text. I can confirm that this text  *is compliant* with the RFC2460bis text.

    Thanks
    Suresh

    
--Apple-Mail=_4E95FC54-F505-4B9C-8079-4C3CB7615A7E--

--Apple-Mail=_7E69E3EA-DE0B-4FD6-8576-37651C4090B8
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw
ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy
aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5
MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz
aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ
MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C
oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg
ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+
SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI
MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O
nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6
Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG
AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp
ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD
VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5
LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G
yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL
B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU
Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc
4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG
H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn
78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r
WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz
Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO
NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb
Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR
AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3
MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp
ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1
3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE
9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp
usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq
qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um
0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI
4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N
V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta
IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj
NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB
igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy
YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv
bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww
SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50
ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50
ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/
SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H
IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp
Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG
x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj
9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55
JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj
SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk
9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7
RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA
Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC
mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzMxMTc0NjQ0WjAjBgkqhkiG9w0B
CQQxFgQUfRYyTIpQymzjqyLgkDSx8UcDZwcwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF
cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa
99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG
9w0BAQEFAASCAQBZHJjFD9n3Sx+ZwQZMJZ3CbAM33VLFI4DYpzL+SGJ+aVlG6MVxQJucv1NFKTir
wZ0PJdcaA5QIPOIL+Krm5tWWSXu0qh8j0BY1Bap5tKyBFHwKPHaDONkm0xZfbDadoHKk4wjuNRDt
6EM4WAglbjB0UFGFuDPoZPar9ijb9heO+kAy0fm99QI3lHEt7Q+IR4cVeqz8m+8Vzpyh1XKkVcIu
8NcwlNU4eWaauWQ8L7cGigwPoWU+fAMrBi1Dtv9bDA8cjbItMkGnxlJ1R89TrgDak8FRLgsHTBYw
4H8XHrcKfkRb01AMzabsfGJy3RJSleeBSPR6ng7XUl4QmO0ZL8hiAAAAAAAA

--Apple-Mail=_7E69E3EA-DE0B-4FD6-8576-37651C4090B8--


From nobody Fri Mar 31 10:56:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB143129568; Fri, 31 Mar 2017 10:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BGkheQfMFoED; Fri, 31 Mar 2017 10:56:27 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E0E126D74; Fri, 31 Mar 2017 10:56:26 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id z13so44480616iof.2; Fri, 31 Mar 2017 10:56:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fzKR1e2OsCNy4Ek48qoBUx9x52XLH44zrToeEo6mpbg=; b=Px2BJ/b/v0NJUvPEavbgQrbQ1qyAno9Ym8t2ucQKleKCcN+09k3hyaE4LhDPXnwx1A nT9daFow9q83+JahLYZBBfXPB3aKGWLP1BVMvB7Gj7358bhuBVYMqJl8hQiFJojHRaPH TOkwabAo+sUompJawmFrP8/7MiHRMedxDysEPRlhsuNsFiP0pKfEfLlkyTXGZv1jl/2z ytY3UyMLp8OMoPkvwHi/yxeo2KK3jtigYi6ykbp5Daw7sRzIT5OUOr3aePUKvAgYB5B8 r8lDx+bdJkjafn3tUiIRjfI6KfdiojLm3HDU4mufrYbK051V7IJu4NXB7yuldA5iFDhk M6lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fzKR1e2OsCNy4Ek48qoBUx9x52XLH44zrToeEo6mpbg=; b=Ax5vudfZnbtzjAZA3f+vL0Ij4GDfxC0AZ+nqa4BArdx3jGGTpfB4/ud96Krhj4snD5 1DCqNEOBfH9e/ge2aFKwH4vQFehTcLW2KYfmQmTAfUd8C7pZYJgOscM+uvDRD08o16wn rYWZu2th2lEXpaLDRjP5wDNDtR9wDeAAwlss9fBkbxOOuvIcT6n9xot2YZHpXqspagpu iDqRASj3nfBye85SotsZ8DZjQeutTpEPze0CgbiG8pmJRIfzHxfjqKBFmIn8cjeKbeou bm9yauhx6xrLPkjeiVm90YHr252KmEUPhdoXThDY95QUf6fZxC4YXcYf/xaZjM+cABDa HItg==
X-Gm-Message-State: AFeK/H3ROiZZt0ut4zf9gYF08gcAx7MGqzGvG0purrjzlGJkTmpYF05KkmnVqLvIKWTlKvvkQtihLwNu4RMkfw==
X-Received: by 10.107.10.21 with SMTP id u21mr5001960ioi.139.1490982985839; Fri, 31 Mar 2017 10:56:25 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 10:56:24 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 10:56:24 -0700 (PDT)
In-Reply-To: <3A7C2C05-8513-4248-82F3-15CC9C75B69E@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>  <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com>  <3A7C2C05-8513-4248-82F3-15CC9C75B69E@ericsson.com>
From: Robert Raszuk 
Date: Fri, 31 Mar 2017 12:56:24 -0500
X-Google-Sender-Auth: otEm0LLn0BekkjZ_rRWP5Pu6ZoI
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Suresh Krishnan 
Cc: "Leddy, John" , otroan@employees.org,  IETF Discussion , Brian E Carpenter , 6man WG ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113ed7663cbc4f054c0a8752
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 17:56:29 -0000

--001a113ed7663cbc4f054c0a8752
Content-Type: text/plain; charset=UTF-8

Even if we treat encapsulation in new IPv6 header as only an option ?

Thx
R.



On Mar 31, 2017 12:46, "Suresh Krishnan" 
wrote:

> Hi Robert,
>
> On Mar 31, 2017, at 12:01 PM, Robert Raszuk  wrote:
>
> Hi Suresh,
>
> As you requested one of many quotes from the draft which your
> clarification to 2460bis directly contradicts with:
>
> This include either:
>
>       A host originating an IPv6 packet.
>
>       *An SR domain ingress router encapsulating a received IPv6 packet
>       into an outer IPv6 header followed by an SRH.*
>
>
> Excellent. Thanks for pointing out the exact text. I can confirm that this
> text  *is compliant* with the RFC2460bis text.
>
> Thanks
> Suresh
>
>

--001a113ed7663cbc4f054c0a8752
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Even if we treat encapsulation in new IPv6 header as only=
 an option ?

    Thx
    R.



    On Mar 3=
1, 2017 12:46, "Suresh Krishnan" <suresh.krishnan@ericsson.com> wrote:
    Hi Robert,

    On Mar 31, 2017=
, at 12:01 PM, Robert Raszuk <robert@raszuk.net> wrote:

    Hi Suresh,
    As you requested one of many quot=
es from the draft which your clarification to 2460bis directly contradicts =
with:

    This include either:

      A host originating an IPv6 packet.

      An SR domain ingress router encapsulating a received IPv6 packet
      into an outer IPv6 header followed by an SRH.


    Excellent. Thanks for p=
ointing out the exact text. I can confirm that this text =C2=A0*is complian=
t* with the RFC2460bis text.

    Thanks
    Sure=
sh

    

--001a113ed7663cbc4f054c0a8752--


From nobody Fri Mar 31 11:08:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B32128DF6; Fri, 31 Mar 2017 11:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ydEAKCW9-ufE; Fri, 31 Mar 2017 11:08:30 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C84912943A; Fri, 31 Mar 2017 11:08:30 -0700 (PDT)
X-AuditID: c6180641-417ff700000058cf-92-58de54c20303
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by  (Symantec Mail Security) with SMTP id E9.3D.22735.2C45ED85; Fri, 31 Mar 2017 15:08:21 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Fri, 31 Mar 2017 14:08:25 -0400
From: Suresh Krishnan 
To: Robert Raszuk 
CC: "Leddy, John" , Ole Troan ,  IETF Discussion , Brian E Carpenter , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv86cghjjmGk6P6rsvHH5Q4qGssVmAgAD+BwCAAAesgIAAIVmAgAAFgwCAAASPgIAAEkGAgABB5oCAAAHpgIAAAteAgAACGICAAAp2gIABEiqAgAAWegCAABjkgIAADLGAgAACtQCAAANRAA==
Date: Fri, 31 Mar 2017 18:08:22 +0000
Message-ID: <0206BF42-1C7C-44F2-8F18-DC9ABB6DA746@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>  <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com>  <3A7C2C05-8513-4248-82F3-15CC9C75B69E@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: multipart/signed; boundary="Apple-Mail=_DA10ED56-F762-4E5F-B1F8-2CD5587EED8F"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUyuXRPgu7RkHsRBvenGlm0XdzHZPHq7TU2 i2cb57NYvDz7nsli6YLlTBaT21awWTQtbGJ2YPe43tnC7HHw2EdGj52z7rJ7LFnyk8lj98YF TAGsUVw2Kak5mWWpRfp2CVwZr6+1sxV8iqj4e/IaWwPjjcAuRg4OCQETiRmL/bsYuTiEBDYw ShzY2ssO4SxnlNiw+jiQw8nBBlS0YednJhBbREBVovPEI2aQImaBKUwSu5s2gxUJC3hITNp0 jQWiyFNi3cbDLCBFIgLLGCUaHneCFbEAdf+9fBnM5hWwl9g/5TIjxLpfHBIt1yawgiQ4BQIl 1p24xghiMwqISXw/tQZsNbOAuMStJ/PBbAkBEYmHF0+zQdiiEi8f/2OFsJUkPv6ezw51HqPE +mtrWCC2CUqcnPmEZQKjyCwks2Yhq5uFpA6iKEni+cP/rBC2tsSyha+ZIWxNif3dy1kwxTUk Or9NhKo3lXh99CMjhG0tMePXQTYIW1FiSvdD9gWM3KsYOUqLC3Jy040MNzEC4/6YBJvjDsa9 vZ6HGAU4GJV4eBdo3IsQYk0sK67MPcSoAtT6aMPqC4xSLHn5ealKIrwyOUBp3pTEyqrUovz4 otKc1OJDjNIcLErivO/KL0QICaQnlqRmp6YWpBbBZJk4OKUaGNX/XXtUv+Y+V4RV77TV9wQY u/yMHIpCVhfVKxaF5fCar7Ux2rZ28iEHWZ/qS0HitsdSv5l2LJ/p5MDwfl/iVOW/exdscXmx bp7S88PrdhxqWZSzNmw1l9SECdc//SluPCHMfiNmoYv9SrWwp15RbRu4J+334j4rsGX9x4BZ ufzPmOOfFD4V9VViKc5INNRiLipOBAA+jqD/AwMAAA==
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 18:08:32 -0000

--Apple-Mail=_DA10ED56-F762-4E5F-B1F8-2CD5587EED8F
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_55ABD291-59C1-4DA4-B953-48E2B1BBE40E"


--Apple-Mail=_55ABD291-59C1-4DA4-B953-48E2B1BBE40E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Robert,

> On Mar 31, 2017, at 12:56 PM, Robert Raszuk  wrote:
>=20
> Even if we treat encapsulation in new IPv6 header as only an option ?

There are two options listed in the draft with the =E2=80=9Ceither=E2=80=9D=
 clause quoted below. Both of them are compliant. In fact, in my not so =
careful reading, I do not see any text in =
draft-ietf-6man-segment-routing-header-06 =
 =
that would be contrary to this text in RFC2460bis.

Thanks
Suresh

P.S.: I am assuming you are using the word option to mean a choice and =
not an IPv6 option. If not, please clarify.

>=20
> Thx
> R.
>=20
>=20
>=20
> On Mar 31, 2017 12:46, "Suresh Krishnan" > wrote:
> Hi Robert,
>=20
>> On Mar 31, 2017, at 12:01 PM, Robert Raszuk > wrote:
>>=20
>> Hi Suresh,
>>=20
>> As you requested one of many quotes from the draft which your =
clarification to 2460bis directly contradicts with:
>>=20
>> This include either:
>>=20
>>       A host originating an IPv6 packet.
>>=20
>>       An SR domain ingress router encapsulating a received IPv6 =
packet
>>       into an outer IPv6 header followed by an SRH.
>=20
> Excellent. Thanks for pointing out the exact text. I can confirm that =
this text  *is compliant* with the RFC2460bis text.
>=20
> Thanks
> Suresh
>=20


--Apple-Mail=_55ABD291-59C1-4DA4-B953-48E2B1BBE40E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi Robert,

    On Mar 31, 2017, at 12:56 PM, =
Robert Raszuk <robert@raszuk.net> wrote:

    Even if we treat encapsulation =
in new IPv6 header as only an option ?

    There are two options listed in the draft with the =
=E2=80=9Ceither=E2=80=9D clause quoted below. Both of them are =
compliant. In fact, in my not so careful reading, I do not see any text =
in draft-ietf-6man-segment-routing-header-06 that would =
be contrary to this text in RFC2460bis.

    Thanks
    Suresh

    P.S.: I am assuming you are using the word option =
to mean a choice and not an IPv6 option. If not, please =
clarify.


    Thx
    R.


    On Mar 31, 2017 12:46, "Suresh =
Krishnan" <suresh.krishnan@ericsson.com> wrote:
    Hi =
Robert,

    On Mar 31, 2017, at 12:01 PM, =
Robert Raszuk <robert@raszuk.net> wrote:

    Hi Suresh,

    As you =
requested one of many quotes from the draft which your clarification to =
2460bis directly contradicts with:

    This include either:

      A host originating an IPv6 packet.

      An SR domain ingress router encapsulating a received =
IPv6 packet
      into an outer IPv6 header followed by an SRH.


    Excellent. Thanks for pointing out the exact text. I =
can confirm that this text  *is compliant* with the RFC2460bis =
text.

    Thanks
    Suresh

    


    =

--Apple-Mail=_55ABD291-59C1-4DA4-B953-48E2B1BBE40E--

--Apple-Mail=_DA10ED56-F762-4E5F-B1F8-2CD5587EED8F
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw
ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy
aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5
MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz
aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ
MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C
oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg
ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+
SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI
MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O
nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6
Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG
AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp
ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD
VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5
LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G
yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL
B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU
Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc
4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG
H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn
78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r
WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz
Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO
NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb
Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR
AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3
MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp
ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1
3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE
9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp
usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq
qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um
0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI
4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N
V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta
IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj
NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB
igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy
YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv
bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww
SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50
ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50
ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/
SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H
IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp
Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG
x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj
9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55
JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj
SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk
9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7
RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA
Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC
mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzMxMTgwODE3WjAjBgkqhkiG9w0B
CQQxFgQUOC6mk3JxnBMSP0zoSn2R8b4J3fgwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF
cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa
99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG
9w0BAQEFAASCAQCB6O5sMcRBsqkJ77SDK7L6h1MhXev0SJ/U/WfyB4T067mE9rp3s3E88W2YH/T/
NEXD4Ab7svg9dZiUF8p4vltzaVRV6daeZCzeiMZxmgZZGry8+Vg3BYd/zUp9SphtZiK6oxSeVzIi
cfIh3pMT1g1xV7NAPIxT4zxAFKqtI2Be7tNrDm8QU6Sr6VLpSXro84CxufYhkPRLElnOqsNVJqk2
5AmsfZbdAOAXA9zI8sUscr1GuSj91chRI1wQ90WgOScBVY+HMDtIgMqnQATPJWtkL/Ggc6PAWpnj
BB4X34h844zZONPQrijefe0j8lYFuzwlXtKbaJd/3LUgaAWb5sUwAAAAAAAA

--Apple-Mail=_DA10ED56-F762-4E5F-B1F8-2CD5587EED8F--


From nobody Fri Mar 31 11:14:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8D11200C5; Fri, 31 Mar 2017 11:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WKicYDbec0_4; Fri, 31 Mar 2017 11:14:10 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999021299AC; Fri, 31 Mar 2017 11:14:08 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id y18so17723617itc.0; Fri, 31 Mar 2017 11:14:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=e9GDzSw9LZoVDZXq/8fJf4VqjAyzisgpM/tRNpfbeaM=; b=GqcPww3ayYLw7uQFm4cH4r2TIvV7bNs+gut8W3LKPBFqYyvIakJFmhdlX2fuizg0Hp DwaSoXbikT42bccZ9OcP78mRtvaIG3usRZYKgRvYWNzwXlioRaVI193RryVHztk61tSO QkNpkWj03Lf8oMZJx4cMbDYdwwkPOw4KM6/8hOQAHP+Y4CQAqBnKQsyUhnRrSE01rHHE gNQiErw1o7c6/PngL2zbjyb6VQECI/X8bFz10tT2O+M46EustMi7QO3nV2XkBmaxDOzN 0K+kiHaPSOM8TQDHYsX6urxwXfrfFJ/OMOS4TEfDeczlKF6OIxOoLbzvUSdiYkTOm5Ag C5Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=e9GDzSw9LZoVDZXq/8fJf4VqjAyzisgpM/tRNpfbeaM=; b=qsBlFB3F4xKJgs1buAaviIf6x0k9iCWKPrBxmmi4Cvgo5WUlK6HmEaiW4HdmNJZYC9 fOGdmixQZNSaBUS0Rk7kLLxlFdBtWpl1Mj0/9ZRXdkKyqUiI9bCKnFyPQrG4UDLeglKj WNk4xTYpsumM6jpIMjO37FWcGekIBF6J3R3qmbKBzN1W519CA82MccukX1yjJnl2KxE0 X8KoQsO/x1z04mI7SyHwtHX1vEATcIfKzvSxejz6HjM1yVC/iG5RcLxg56tEbssg2KNP JkbFbBucl2o+PFcgYhEfOM29iVhZKnku5qKNwSMSuU9/xGxM9QZ+aHQLqeZRnZux5q1s ZoGw==
X-Gm-Message-State: AFeK/H2E1NHyCj5HAbtSKMGpjcJAW96BmSQE6pzUirjCfRHU/IZPMCK96432Xessap+5r+uXmRn02O7TusJ4aQ==
X-Received: by 10.36.46.81 with SMTP id i78mr5421651ita.39.1490984047915; Fri, 31 Mar 2017 11:14:07 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 11:14:06 -0700 (PDT)
Received: by 10.79.90.71 with HTTP; Fri, 31 Mar 2017 11:14:06 -0700 (PDT)
In-Reply-To: <0206BF42-1C7C-44F2-8F18-DC9ABB6DA746@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>  <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com>  <3A7C2C05-8513-4248-82F3-15CC9C75B69E@ericsson.com>  <0206BF42-1C7C-44F2-8F18-DC9ABB6DA746@ericsson.com>
From: Robert Raszuk 
Date: Fri, 31 Mar 2017 13:14:06 -0500
X-Google-Sender-Auth: 3hXVJHe969Fm_-3tR3x3yxa5hmg
Message-ID: 
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Suresh Krishnan 
Cc: "Leddy, John" , otroan@employees.org,  IETF Discussion , 6man WG ,  Brian E Carpenter ,  "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114a93ce8abcfc054c0ac60a
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 18:14:12 -0000

--001a114a93ce8abcfc054c0ac60a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Suresh,

The fact that encapsulation in new v6 header is optional to me is clearly
stated in section 4.1 of that document:

 By default, a local SID bound to the End function does not allow
      the decapsulation of an outer header.  As a consequence, an End
      SID cannot be the last SID of an SRH and cannot be the DA of a
      packet without SRH.

   o  If the decapsulation is desired, then another function must be
      bound to the SID (e.g., End.DX6 defined in
      [I-D.filsfils-spring-srv6-network-programming
]).
This prevents
      any unintentional decapsulation by the segment endpoint node.  The
      details of the advertisement of a SID in the control plane are
      outside the scope of this document (e.g.,
      [I-D.previdi-idr-segment-routing-te-policy
],
      [I-D.dawra-bgp-srv6-vpn
]
and [I-D.bashandy-isis-srv6-extensions
].


On Mar 31, 2017 13:08, "Suresh Krishnan" 
wrote:

> Hi Robert,
>
> On Mar 31, 2017, at 12:56 PM, Robert Raszuk  wrote:
>
> Even if we treat encapsulation in new IPv6 header as only an option ?
>
>
> There are two options listed in the draft with the =E2=80=9Ceither=E2=80=
=9D clause quoted
> below. Both of them are compliant. In fact, in my not so careful reading,=
 I
> do not see any text in draft-ietf-6man-segment-routing-header-06
>  t=
hat
> would be contrary to this text in RFC2460bis.
>
> Thanks
> Suresh
>
> P.S.: I am assuming you are using the word option to mean a choice and no=
t
> an IPv6 option. If not, please clarify.
>
>
> Thx
> R.
>
>
>
> On Mar 31, 2017 12:46, "Suresh Krishnan" 
> wrote:
>
>> Hi Robert,
>>
>> On Mar 31, 2017, at 12:01 PM, Robert Raszuk  wrote:
>>
>> Hi Suresh,
>>
>> As you requested one of many quotes from the draft which your
>> clarification to 2460bis directly contradicts with:
>>
>> This include either:
>>
>>       A host originating an IPv6 packet.
>>
>>       *An SR domain ingress router encapsulating a received IPv6 packet
>>       into an outer IPv6 header followed by an SRH.*
>>
>>
>> Excellent. Thanks for pointing out the exact text. I can confirm that
>> this text  *is compliant* with the RFC2460bis text.
>>
>> Thanks
>> Suresh
>>
>>
>

--001a114a93ce8abcfc054c0ac60a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Hi Suresh,

    T=
he fact that encapsulation in new v6 header is optional to me is clearly st=
ated in section 4.1 of that document:

     By default, a local SID bound to the End function does not allow
      the decapsulation of an outer header.  As a consequence, an End
      SID cannot be the last SID of an SRH and cannot be the DA of a
      packet without SRH.

   o  If the decapsulation is desired, then another function must be
      bound to the SID (e.g., End.DX6 defined in
      [I-D.filsfils=
-spring-srv6-network-programming]).  This prevents
      any unintentional decapsulation by the segment endpoint node.  The
      details of the advertisement of a SID in the control plane are
      outside the scope of this document (e.g.,
      [I-D.previdi-idr=
-segment-routing-te-policy],
      [I-D.dawra-bgp-srv6-vpn] and [<=
a href=3D"https://tools.ietf.org/html/draft-ietf-6man-segment-routing-heade=
r-06#ref-I-D.bashandy-isis-srv6-extensions">I-D.bashandy-isis-srv6-extensio=
ns].

    On Mar 31, 2017 13:08, "Suresh Krishnan" <suresh.krishnan@ericsson.com> w=
rote:
    Hi Robert,

    On Mar 31, 2017, at 12:56 PM, Robert Raszuk <robert@raszuk.net> wrote:

    Even if we treat encapsulation in new IPv6 header as only an option ?

    There are two options listed in the dra=
ft with the =E2=80=9Ceither=E2=80=9D clause quoted below. Both of them are =
compliant. In fact, in my not so careful reading, I do not see any text in=
=C2=A0dra=
ft-ietf-6man-segment-routing-header-06=C2=A0that would be contrary=
 to this text in RFC2460bis.

    Thanks
    Sure=
sh

    P.S.: I am assuming you are using the word opti=
on to mean a choice and not an IPv6 option. If not, please clarify.

    <=
br>
    Thx
    R.



    On Mar 31, 2017 12:46, "Suresh Kri=
shnan" <suresh.krishnan@ericsson.com> wrote:
    =

    Hi Rober=
t,

    On Mar 31, 2017, at 12:01 PM=
, Robert Raszuk <=
robert@raszuk.net> wrote:

    Hi Sur=
esh,

    As you requested one of m=
any quotes from the draft which your clarification to 2460bis directly cont=
radicts with:

    This include eith=
er:

      A host originating an IPv6 packet.

      An SR domain ingress router encapsulating a received IPv6 packet
      into an outer IPv6 header followed by an SRH.


    Excellent. Thanks for p=
ointing out the exact text. I can confirm that this text =C2=A0*is complian=
t* with the RFC2460bis text.

    Thanks
    Sure=
sh

    


    

--001a114a93ce8abcfc054c0ac60a--


From nobody Fri Mar 31 11:18:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D82126DFB; Fri, 31 Mar 2017 11:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fqvI5mmhVYLH; Fri, 31 Mar 2017 11:18:46 -0700 (PDT)
Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C02120725; Fri, 31 Mar 2017 11:18:46 -0700 (PDT)
Received: by mail-it0-x244.google.com with SMTP id e75so2797131itd.1; Fri, 31 Mar 2017 11:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OXx02gTkEjtTOC68+xl7oUQBokNg7HenrItSxIx7BZo=; b=NNlR6F+CtcP9eaa+IQeoQKcIrGenqbIIANKS1h78REdZW2QyWmP5kRh9Vg/NdSWx0W B6e2V/Lgdy/qLu4EaSz7S07gr41/Oqj56iJmnuTv7xL4EgZTsnoWvjBElMMK3AyaAuQH ZUkkCvlgmKeTsY5X7/+NpO0kczXUnttNJmPZ0zYFUyJF7gTnFZUQLr8rjgdlI4viV1Ec PKIMguS+TSdjRcDwPwMDUtg3FDFeUz/ES8FhCfn/uOSt/QVEKIWYoK43IyKH3RABSgYS ufGHVDoObFZnv6kVHTZmqVaQt0RBMSrSAXxq5weVUiOQOOq/LjAHszTZG3gwyVJ+LwnO Mdow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=OXx02gTkEjtTOC68+xl7oUQBokNg7HenrItSxIx7BZo=; b=RsxbjydjBA7wJ7Db08rGZdaCgUfJSI3Eijfs/qRdu31TRkUy0RfZeS1YPbVKt3M6fQ Z4l3T8AsJ7MP0aP6mQCmIJNyKD2rMF/T/GWP723Yb7vRFuXSBl0Ca+BMySEEu8s3KmLl 44whVMg2l668V9G1j5XUstJsxtMUKqOS2f7hEZ4n6H3/z4qbqjsaYbA6ithkIAlzTqtQ HGnotffKOPh3AsdIlC/IY9U5dRPIeW6bXklNzEuYME51zfj+WL93tAwzLx7eJmpIp42z Tgk9ik0fwLBcN2vH/8JMpTabmduhsKqV+IDxX8EpwxZpSup7soqDXyaQgt8SUJ6WvnvO KL5w==
X-Gm-Message-State: AFeK/H1l/6zgWl+m/XGgAKN8poyU40GTfWFAEDMlUi/jIBj1ZiYCBf8J5vWYkVM4/DJRIw==
X-Received: by 10.36.0.198 with SMTP id 189mr5503452ita.82.1490984325587; Fri, 31 Mar 2017 11:18:45 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n73sm3538071ioe.10.2017.03.31.11.18.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 11:18:44 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Robert Raszuk , Suresh Krishnan 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>  <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com>  <3A7C2C05-8513-4248-82F3-15CC9C75B69E@ericsson.com> 
Cc: "Leddy, John" , otroan@employees.org, IETF Discussion , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Sat, 1 Apr 2017 07:18:54 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 18:18:48 -0000

Robert,

Actually this was thoroughly discussed (mainly with Stefano I think)
and these texts in draft-ietf-6man-segment-routing-header-06 were
carefully designed to be compatible with both RFC2460 and RFC2460bis:

Section 2.3.1:
>  The outer header with the SRH is no different from any other
>  tunneling encapsulation mechanism and allows a network operator to
>  implement traffic engineering mechanisms so to efficiently steer
>  traffic across his infrastructure.
 
Section 5.1:
>  A Source SR Node can be any node originating an IPv6 packet with its
>  IPv6 and Segment Routing Headers.  This include either:
> 
>     A host originating an IPv6 packet.
> 
>     An SR domain ingress router encapsulating a received IPv6 packet
>     into an outer IPv6 header followed by an SRH.

I suppose we need expert review of the routing header itself, but
for me there is simply no issue about compatibility with 2460(bis).

(draft-voyer-6man-extension-header-insertion is a quite different
conversation and we should not confuse the two. That would be FUD.)

Regards
   Brian

On 01/04/2017 06:56, Robert Raszuk wrote:
> Even if we treat encapsulation in new IPv6 header as only an option ?
> 
> Thx
> R.
> 
> 
> 
> On Mar 31, 2017 12:46, "Suresh Krishnan" 
> wrote:
> 
>> Hi Robert,
>>
>> On Mar 31, 2017, at 12:01 PM, Robert Raszuk  wrote:
>>
>> Hi Suresh,
>>
>> As you requested one of many quotes from the draft which your
>> clarification to 2460bis directly contradicts with:
>>
>> This include either:
>>
>>       A host originating an IPv6 packet.
>>
>>       *An SR domain ingress router encapsulating a received IPv6 packet
>>       into an outer IPv6 header followed by an SRH.*
>>
>>
>> Excellent. Thanks for pointing out the exact text. I can confirm that this
>> text  *is compliant* with the RFC2460bis text.
>>
>> Thanks
>> Suresh
>>
>>
> 


From nobody Fri Mar 31 11:35:37 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7281212945F; Fri, 31 Mar 2017 11:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 T5f5Zj8AJ7G2; Fri, 31 Mar 2017 11:35:27 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F2B126B71; Fri, 31 Mar 2017 11:35:26 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id f103so6687429ioi.2; Fri, 31 Mar 2017 11:35:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sDMdb0NZ2SurtAK9PGMUIE16I+bMTPjorljEyyDoT9c=; b=Bg5in8An6ADxA5yMfR0/hkpq53mRZiAnyTaDjJnLSOERCrv8B+WSDz6TGOYpXBtD6f EG2EkNZxzwA+/T3wPTIene+jLuQdmMIRUDOjVpXcFO9mLeTtid/APRCSpTAey75QWKJq l71DyVuV5yX6ky/Mb6OMIf8Wax6OFK35HKUNA7K3cCfFan4TdnX07ViNyXx0wbI7SOM3 +PZGc2Q/JrQfmckDBwc345vC1bk65Iptt1aNYeq+Wnl3LUVeEZ0N8VkpgiBJU4szLeaG 4mcS+InbtcFVCGuzry6abH2rZXZYm1qPyQuiK1uzJFb8ZZ32SR7KoyaSxx68VU8ObukD ve9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=sDMdb0NZ2SurtAK9PGMUIE16I+bMTPjorljEyyDoT9c=; b=LqYvTRmcfZqhoUeQnz57YmvCl4oUUnmxnv04/vl7aB16t6HlT6Lc8StpoV0EorDJv1 kYPyJGD2IcomW+utw4QGgv5E8NiSd0Th4MpsegDozh1R1JTekdpcdTQ10T/4mvwNXYrm i1md+7m72IoKUlcexfuiMMtnzvE/X+CI0sFILDaKQx7tYLctvc9skCiqPh0AV/8IJZLj uCWL2a7BkO7rCs3Cw+1XX6A6Bjg6zRDlesjEMNRJ7qgL3htck4J5BcxqLHgTezoylKRd MU5fj5y2YCgxJWby2Fa8qA23Sx8z+vPRafBtbUG7UPc9YtfYtOJx1yNGcHZ1zM7cydhI P/5w==
X-Gm-Message-State: AFeK/H2ofx3GmXTPCqD06jLToXURgnKzMha8mq3CgzSsvnyq97TcS4O9u/bga0zeyCb/zA==
X-Received: by 10.107.1.16 with SMTP id 16mr5311052iob.44.1490985326260; Fri, 31 Mar 2017 11:35:26 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k63sm3556143ioi.19.2017.03.31.11.35.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 11:35:25 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Robert Raszuk , Suresh Krishnan 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>    <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org>    <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com>  <6C78BE2C-58B6-4A3A-B42A-C8A46D68B730@ericsson.com>  <3A7C2C05-8513-4248-82F3-15CC9C75B69E@ericsson.com>  <0206BF42-1C7C-44F2-8F18-DC9ABB6DA746@ericsson.com> 
Cc: "Leddy, John" , otroan@employees.org, IETF Discussion , 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <1eb66a47-9bcc-ea5b-ae6a-35243aa99e87@gmail.com>
Date: Sat, 1 Apr 2017 07:35:34 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 18:35:29 -0000

On 01/04/2017 07:14, Robert Raszuk wrote:
> Hi Suresh,
>=20
> The fact that encapsulation in new v6 header is optional to me is clear=
ly
> stated in section 4.1 of that document:
>=20
>  By default, a local SID bound to the End function does not allow
>       the decapsulation of an outer header.  As a consequence, an End
>       SID cannot be the last SID of an SRH and cannot be the DA of a
>       packet without SRH.
>=20
>    o  If the decapsulation is desired, then another function must be
>       bound to the SID=20

Sure, any tunnel needs a decapsulator as well as an encapsulator. That's
not news, so what is the problem here? I assume you'd decapsulate in
the last hop router. I don't claim to understand segment routing, so
I can't actually understand the above text. But the text elsewhere
is clear enough that either the original source or the encapsulator
builds the routing header, and that's all we need to know for
2460(bis) compatibility. So why are we still discussing?

    Brian

> (e.g., End.DX6 defined in
>       [I-D.filsfils-spring-srv6-network-programming
> ]).
> This prevents
>       any unintentional decapsulation by the segment endpoint node.  Th=
e
>       details of the advertisement of a SID in the control plane are
>       outside the scope of this document (e.g.,
>       [I-D.previdi-idr-segment-routing-te-policy
> ],
>       [I-D.dawra-bgp-srv6-vpn
> ]
> and [I-D.bashandy-isis-srv6-extensions
> ].
>=20
>=20
> On Mar 31, 2017 13:08, "Suresh Krishnan" =

> wrote:
>=20
>> Hi Robert,
>>
>> On Mar 31, 2017, at 12:56 PM, Robert Raszuk  wrote:=

>>
>> Even if we treat encapsulation in new IPv6 header as only an option ?
>>
>>
>> There are two options listed in the draft with the =E2=80=9Ceither=E2=80=
=9D clause quoted
>> below. Both of them are compliant. In fact, in my not so careful readi=
ng, I
>> do not see any text in draft-ietf-6man-segment-routing-header-06
>>  that
>> would be contrary to this text in RFC2460bis.
>>
>> Thanks
>> Suresh
>>
>> P.S.: I am assuming you are using the word option to mean a choice and=
 not
>> an IPv6 option. If not, please clarify.
>>
>>
>> Thx
>> R.
>>
>>
>>
>> On Mar 31, 2017 12:46, "Suresh Krishnan" 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> On Mar 31, 2017, at 12:01 PM, Robert Raszuk  wrote=
:
>>>
>>> Hi Suresh,
>>>
>>> As you requested one of many quotes from the draft which your
>>> clarification to 2460bis directly contradicts with:
>>>
>>> This include either:
>>>
>>>       A host originating an IPv6 packet.
>>>
>>>       *An SR domain ingress router encapsulating a received IPv6 pack=
et
>>>       into an outer IPv6 header followed by an SRH.*
>>>
>>>
>>> Excellent. Thanks for pointing out the exact text. I can confirm that=

>>> this text  *is compliant* with the RFC2460bis text.
>>>
>>> Thanks
>>> Suresh
>>>
>>>
>>
>=20


From nobody Fri Mar 31 11:42:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EAA1270A0 for ; Fri, 31 Mar 2017 11:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 osQAmj4SGuN7 for ; Fri, 31 Mar 2017 11:42:51 -0700 (PDT)
Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC31712952F for ; Fri, 31 Mar 2017 11:42:49 -0700 (PDT)
Received: by mail-io0-x243.google.com with SMTP id n76so6707705ioe.1 for ; Fri, 31 Mar 2017 11:42:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GdOkAz50X59a/LIN4Z0AII2S1kG2KwzbrWEE9y9MdnQ=; b=e18NUyAhnoeCbEzXmRmcdmDp3X81eRAFmX/NNDLpthqd+vpSgIROm8E7CAEjyeec0Y QVxDpeoWObRoFMFRRMFLq3XAu3jtGhLupNW9+t0JBd6OPfKpaEBtSynbGgjBo3aRAAQR GNs3Xh+ApmrpH3t/mV2PStsA50Df1VQviSjPOlVV4x3CkzC+X5iR4PjzhKupvPek+yrV oEeOu+zMkujioCA2WvlvvRIHPvx+oRxAbNrxwj1s8WXsBEVm5YJzUnkvI6hslS6KOdAl fnn/viuJDv6abgBLOFzSISS1BYM3qtpYDrKuO+ItB4JxcdlGrVKI1Iq+V2qUQ0OnPWeX 20ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GdOkAz50X59a/LIN4Z0AII2S1kG2KwzbrWEE9y9MdnQ=; b=hZflwlZSteI3gTYSxpGCxkwLXcIhi71ybppGXGwWUoVHsgG1GQ2wmDlzXUZm+XMPxv biyeiSo0t62mBTIpEMlph0fMbiGK/EdTkKaEgx5lEKlN+di8kJPmpVXPltyxVCq45KG3 Tmk/RE/5khjRL5e8FTDoa+adByLB4xJ2M+bvyNS5GQNVp/fxXYqXmpcrhqWiJRRufjYE dSaUW/rGVF2xJAB2LT3fS1Fnz82zQVjY5HR3nj0DlUFTtYQTRXcfg2G04N0cTxX76DE9 iSScs/l2kd1zTQJggykOuRyHVS0uySjhIshk4LfkfxY290gT1Hi3NoJJwIwJarXymKsU on/Q==
X-Gm-Message-State: AFeK/H0/c6W/cyoTgOEaPY6qXyHQLhIfUaCJ0R/1Z4ULxLWUidDm2FDyg/v24SxAjDrysw==
X-Received: by 10.107.128.169 with SMTP id k41mr5182788ioi.59.1490985768901; Fri, 31 Mar 2017 11:42:48 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l129sm3912509ite.1.2017.03.31.11.42.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 11:42:48 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: "Ackermann, Michael" , Tim Chown 
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>    
Cc: "ipv6@ietf.org" 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Sat, 1 Apr 2017 07:42:58 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 18:42:56 -0000

On 01/04/2017 04:04, Ackermann, Michael wrote:
> QUESTION:
> Does the word PROCESSED, mean change, implying write capability?
> If yes, can that be stated?

I believe we went around that some time back and settled on 'processed'
as covering both calculating and modifying. I'm not enthusiastic
to wordsmith this yet again, personally, IMHO, YMMV. We've already
had to wordsmith the 'examined'.

    Brian
>=20
>=20
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tim Chown
> Sent: Friday, March 31, 2017 10:39 AM
> To: Brian E Carpenter 
> Cc: ipv6@ietf.org
> Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-0=
8
>=20
> On 31 Mar 2017, at 00:09, Brian E Carpenter > wrote:
>=20
> On 31/03/2017 11:13, Jen Linkova wrote:
>=20
> On Wed, Mar 15, 2017 at 3:47 AM, Suresh Krishnan
> > wro=
te:
>=20
> Thanks to everyone who commented during the IETF Last Call of draft-iet=
f-6man-rfc2460bis-08. The IETF last call discussion for this draft was ma=
inly focused around the text in Section 4 that discusses the handling of =
extension headers. The biggest concern raised was that the current text i=
s ambiguous on whether header insertion is allowed on intermediate nodes =
or not. There were some people arguing that an explicit prohibition is no=
t necessary as the text is already clear, while others believed that expl=
icitly listing the prohibitions will minimize any misunderstandings in th=
e future. There was also a small number of people who wanted to explicitl=
y allow header insertion and describe how to do it, but this was clearly =
out of scope for this draft (but may be in scope for future work in 6man)=
=2E Overall, no one argued against the fact that the intent of the text i=
n RFC2460 was to forbid insertion of extension headers on any other node =
but the source of the packet.  The only argument m
> a
>=20
> de against adding clarifying text was that the text was already clear. =
Given this, I believe there is consensus to add explicit text about heade=
r insertion into the draft before it progresses further. I have discussed=
 this with the editor and the document shepherd and would like to propose=
 the following text change.
>=20
>=20
> OLD (from -08):
>=20
> The insertion of Extension Headers by any node other than the source
> of the packet causes serious problems.  Two examples include breaking
> the integrity checks provided by the Authentication Header Integrity
> [RFC4302], and breaking Path MTU Discovery which can result in ICMP
> error messages being sent to the source of the packet that did not
> insert the header, rather than the node that inserted the header.
>=20
> One approach to avoid these problems is to encapsulate the packet
> using another IPv6 header and including the additional extension
> header after the first IPv6 header, for example, as defined in
> [RFC2473]
>=20
> With one exception, extension headers are not processed by any node
> along a packet's delivery path, until the packet reaches the node (or
> each of the set of nodes, in the case of multicast) identified in the
> Destination Address field of the IPv6 header...
>=20
> NEW:
>=20
> With one exception, extension headers are not examined, processed,
> inserted, or deleted by any node along a packet's delivery path,
> until the packet reaches the node (or each of the set of nodes, in
> the case of multicast) identified in the Destination Address field of
> the IPv6 header...
>=20
> I have some concerns with how that sentence AND the following note
> comes together:
>=20
> "  With one exception, extension headers are not examined, processed,
>   inserted, or deleted by any node along a packet's delivery path,
>   until the packet reaches the node (or each of the set of nodes, in
>   the case of multicast) identified in the Destination Address field of=

>   the IPv6 header.  Note: If an intermediate forwarding node examines
>   an extension header for any reason, it must do so in accordance with
>   the provisions of [RFC7045].  "
>=20
> I'm afraid that the lack of the normative language strikes back..
>=20
> Exactly the opposite, IMHO. I think it's much better like this than it
> would be under RFC2119 (although in fact that doesn't change the
> English meaning of 'must'). The "Note:" describes a situation where
> middleboxes are actually breaking the rule. We had that fight before
> RFC7045.
>=20
> Indeed. The RFC7045 exception applies specifically to *examining* heade=
rs, with the common use case being firewalling.
>=20
> Changing the RFC7045 exception text to clarify this in 2460bis was prop=
osed, but it wasn=E2=80=99t taken forward.
>=20
> Tim
>=20
>=20
>     Brian
>=20
>=20
>=20
> If 'are not examined" is to be interpreted as RFC2119 'MUST NOT',
> then the following note conflicts with that statement. 'A node MUST
> NOT examine EHs
> but if it does it must do it as per RFC7045' - it is extremely controve=
rsial.
>=20
> If ''are not examined" is to be read as RFC2119 'SHOULD NOT' then I
> have a very good news for
> those who would still like to insert/delete EHs: they can do it  as
> long as  they have
> "valid reasons in particular circumstances when the particular
> behavior is acceptable or even useful, but the full
>   implications should be understood and the case carefully weighed
>   before implementing any behavior described with this label.".
> But from today's presentation I've got an impression that the
> intention of this text was actually to prohibit EH insertion
> (the sildes say 'no one argued against the fact that the intent of the
> text in RFC2460
> was to forbid insertion of extension headers on any other node but the =
source
> of the packet.).
>=20
> So to summarize: the proposed text either explicitly prohibits the
> examination (and then it contradicts the next sentence and we need to
> do smth with the note and RFC7045) OR it allows EH insertion - it
> depends how the text is interpreted.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20
>=20
>=20
> The information contained in this communication is highly confidential =
and is intended solely for the use of the individual(s) to whom this comm=
unication is directed. If you are not the intended recipient, you are her=
eby notified that any viewing, copying, disclosure or distribution of thi=
s information is prohibited. Please notify the sender, by electronic mail=
 or telephone, of any unintended receipt and delete the original message =
without making any copies.
> =20
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan a=
re nonprofit corporations and independent licensees of the Blue Cross and=
 Blue Shield Association.
>=20


From nobody Fri Mar 31 12:27:37 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017031294AA; Fri, 31 Mar 2017 12:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 O5u6H-Uf7PoH; Fri, 31 Mar 2017 12:27:33 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A5A1294F3; Fri, 31 Mar 2017 12:27:29 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3vvs2l6QVDz271q; Fri, 31 Mar 2017 21:27:27 +0200 (CEST)
X-purgate-ID: 152705::1490988447-00002B31-CC3EDB7B/0/0
X-purgate-size: 579
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3vvs2l18NczGpLg; Fri, 31 Mar 2017 21:27:27 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 214C51A667; Fri, 31 Mar 2017 21:27:27 +0200 (CEST)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
In-Reply-To: 
To: Robert Raszuk 
Date: Fri, 31 Mar 2017 21:27:27 +0200 (CEST)
CC: "Ackermann, Michael" ,  "Leddy, John" , 6man WG ,  IETF Discussion , "draft-ietf-6man-rfc2460bis.all@ietf.org" 
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170331192727.214C51A667@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Mar 2017 19:27:36 -0000

Robert Raszuk wrote:
> 
> 
> SRv6 is a first serious consideration why number of enterprise networks
> would benefit from and could consider IPv6 rollout.

Are you "back from the future" and accidentally confusing dreams with
what is currently available?  ;-)


https://www.theregister.co.uk/2017/01/19/windows_10_bug_undercuts_ipv6_rollout/

  "The horrible irony of Microsoft waiting on its own team to fix
   a networking bug aside, the post goes some way to highlighting
   why it is that IPv6 is still not widely available: because it's a mess."


-Martin