From nobody Fri Dec 1 11:40: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 D4AB8126CB6; Fri, 1 Dec 2017 11:40:13 -0800 (PST) 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.199, 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 L0w27bhgeFjR; Fri, 1 Dec 2017 11:40:12 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 C0D82124D85; Fri, 1 Dec 2017 11:40:11 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id n138so5416159wmg.2; Fri, 01 Dec 2017 11:40:11 -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=CZNcYBnHjUNqhJ16Wv5i5Ht3BVwHQSmLy4s5G8RKJZE=; b=rphvdPm6KCIv+Wh4f7Iuy4pUE9dv5UjCMEdCsXKMG6/S+q1vfGv7z8+QDkSMszBt0o VpQrvi2ppkLDSqI/pd2ubAF3Yxqy3rGPoEYx/P3wulSQXfVzM5ehuq211UMYSKUXuSZH v9F2TyEkoW9H/Ck32BHoldYS8yR4poExSYyNivenot9DB3+poiGlHe7Z+rvHX+k3fzzG xWNXOnI7WmPZ15IHy28LSbP360d5sV27aUTI4eOKpGpGq46B2EzgAu6XtYuYOFn5dO16 mYU6m3Yqa37bPOdkOTHw1GmnxX7lGCLuM5PM9aKRgbneshfCwO88mkjfpOIYacXbrncq 8Vzg== 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=CZNcYBnHjUNqhJ16Wv5i5Ht3BVwHQSmLy4s5G8RKJZE=; b=CsKZ0dAiczwVkXPGdf6JNZWXRojhkI8pY+srTM2hGlup6/nrylNVuwxqf+TIi+bLNS jqZ+F9SM+C6uVWH6ny+7nKOAnSLYUaofUsu1bO99O4Il7Pu/l2EQmlV/YeL2QCA32uX5 LzE5D6TGo0powbqBcE130vLrBm3gdaE9OZxxcx/TmnU6qoVpPom24ylLFWi3Cm8WFfgG ufwlzcsEgZXz1eqR/dwTxzpzZxxgL5xOTTSTh2WipU4PCzh6/P3yL2ILzKC6xM+Clqlh KxLBj+LLTyl3eEmG4r+CbATx9E8cUdxydcyVjowFLyEQomDiT3hBU0TyAj2dDAdxoKGd ZTyw== X-Gm-Message-State: AKGB3mLmkSeGkZ6ErQgoQwJqYP8FbGgiLj0xRbWUgCfN41+nDuKnIUMV +N/IyjZV1ybVKJs62VUBaP0jy3+oYIeEXIbeNN4= X-Google-Smtp-Source: AGs4zMbnng6ksoTiazsP9/TCDiyH/tTehVwNLM02ulK2EgBwsMisMzczRXgYd7kqiUTOCsxxNHtEXmJkEyzbf/uDPHI= X-Received: by 10.28.211.15 with SMTP id k15mr2220829wmg.33.1512157210066; Fri, 01 Dec 2017 11:40:10 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.185.107 with HTTP; Fri, 1 Dec 2017 11:40:09 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 1 Dec 2017 11:40:09 -0800 X-Google-Sender-Auth: AvyXXtNnLxFJ76r_mjJa7_KpVeQ Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Tom Herbert Cc: Brian E Carpenter , Fernando Gont , draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG , Robert Raszuk 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, 01 Dec 2017 19:40:14 -0000 At Thu, 30 Nov 2017 17:03:08 -0800, Tom Herbert wrote: > > What I'm seeing in this thread are rational arguments for and against > > the proposal. I agree about the logical fallacy in the abstract of the > > current draft, but that's fixable with a few seconds use of the cursor > > and Delete key. I'd like to see the rational arguments in the next version > > of the draft. > > > It's not just the abstact that promote the logical fallacy, it occurs > elsewhere in the draft. For instance: > > "Obviously, this FRR service increases the size of the packet during > its journey within domain D. This is well-known to operators. > Well-known mitigation techniques have been deployed for more than 15 > years" > > This seems like a pretty useless statement in a protocol > specification. Either the mitigations should be articulated here or > the applicable RFCs describing them should be referenced. +1, or, I would not necessarily say it's a "fallacy" but the current form of draft is unnecessarily defensive and provocative, while it doesn't sufficiently provide *technical* answer to questions that was raised for the proposal, most notably "why not just encapsulation". I'm happy to help the proposal move forward (although whether I finally support it depends on technical details), but right now the tone and technical substance of the draft don't suggest I can constructively contribute to the discussion. As Brian put it, I basically "stopped reading the draft" once I knew it didn't contain much useful information and didn't even bother to point it out at this ML. I suspect there are some others who had the same impression and took the same (in)action. Hopefully the next version will be improved substantially, incorporating the points discussed in this thread, then I'll be happy to review it more closely. -- JINMEI, Tatuya From nobody Fri Dec 1 14:08: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 246A41293D8; Fri, 1 Dec 2017 14:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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 Hu03vAe8N6pD; Fri, 1 Dec 2017 14:08:24 -0800 (PST) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c: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 7093912922E; Fri, 1 Dec 2017 14:08:24 -0800 (PST) Received: by mail-vk0-x243.google.com with SMTP id 138so6423447vko.13; Fri, 01 Dec 2017 14:08:24 -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=MT3QILLA69KlqJvQraM7K7rMsy6aWUYCLfxMNbSqEM8=; b=GqjaXuaJ5rEZiWPW74O4+JDuJtl+krntsSiBFwjbMszYepMCoQCU2BX1+Dyk6OD3fx qWFWr52DKdOoPL/OB1i3ytz601oHPOHuNP18eNgHKLh8/fkDXC05urmn/aorS+wvs/iF E1VBgR3+LMWlSN3A5ztQ1ojFtB8yds/wJgdaZl+EoWTuAba1IZ/E33MeNe95W0GHCzwF q7xvrbGQnJ8BGtSDFYN5TxOHOrgQd+HLdu8RrzXeW3LWB1ORsKFhPqJrbmaoa6rxdPKW DDpMck4prxAGMk0TTsWiCYsS2/1Npg8i27cai/NBwyApkwfV7oyrQTcQL5116mKDJznE iLRQ== 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=MT3QILLA69KlqJvQraM7K7rMsy6aWUYCLfxMNbSqEM8=; b=m2n1B+DNnU0m5DE1U1Og9+QqSE/IHbYpvQO7+j4+JZa+B/uP1gLdwcRWbb7oI4tAry nK+aA+SM2PkuLBxWCmFeLpx99J0lA4a3DN2SBMZXQsAiH6+DrNNvBmLnTTqoNG74+Lci u/Jbjf9+u/8lRVdQ2P5KIKgY1X2XKQT/PpkIa+EEDcsiwg01sZWfXNT3Ibnwo3ABim5E 3oISP39RdWAgdem8RO+P/5Rfc01aKZzz+ArnD4s7HS88/fLXZMbVTPJlytrcRx3KwkRV W8LzIEDPFNAlvaVYArfKUNhudWK41IPSqPvcdq8vxLzZ8A/QJBd2ytxvBOuMu+KtXx38 Eqaw== X-Gm-Message-State: AKGB3mJcV9Ko3HVev7qyOi8uVlJpwXhS5l84KC4him/jheiLzeTIyXS/ FBAjzpLDWHu/enm/NXDkZZcHY6Ke2G3l44XCsiI= X-Google-Smtp-Source: AGs4zMbEYJy7hddw2NRivMGSXRa+5tKGGcuuAPVNAdLkxtCiWVqYpMTt2aq9c5rq1y/kqvYWKWABTGnwE5oxXmQkID8= X-Received: by 10.31.135.197 with SMTP id j188mr5522170vkd.34.1512166103322; Fri, 01 Dec 2017 14:08:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.56.218 with HTTP; Fri, 1 Dec 2017 14:07:52 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> From: Mark Smith Date: Sat, 2 Dec 2017 09:07:52 +1100 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Brian E Carpenter Cc: Robert Raszuk , Fernando Gont , draft-voyer-6man-extension-header-insertion@ietf.org, 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, 01 Dec 2017 22:08:26 -0000 Hi Brian, On 1 December 2017 at 11:15, Brian E Carpenter wrote: > On 01/12/2017 10:27, Mark Smith wrote: >> On 1 Dec. 2017 6:35 am, "Robert Raszuk" wrote: >> > > What I'm seeing in this thread are rational arguments for and against > the proposal. I agree about the logical fallacy in the abstract of the > current draft, but that's fixable with a few seconds use of the cursor > and Delete key. I'd like to see the rational arguments in the next version > of the draft. > While they may have perhaps been lost in the discussion before, they were asked for in the previous discussions of the -00 draft. I asked numerous times (at least 3 from memory), what is wrong with exclusively using tunnelling for this. I think eventually Robert said because of the tunnelling overhead. The trouble with this argument is that this draft doesn't exclusively propose extension header insertion, it also describes using tunnelling. The only distinction between which method to use is whether the packet originates within the SR domain ("Source Domain and Packet Journey") or originates externally to it ("Transit through a Source Domain"). So tunnelling overhead is apparently quite acceptable as long packets happen to come from outside the SR domain. I can't see anything that explains why packets that originate internally can't or must not be tunnelled. So the example SR domains in the draft, which is presumably the same domain, support both insertion and tunnelling to achieve the same and single goal of adding SRH information to a packet. Seems unnecessarily complex to support two methods that achieve the same functional outcome. More prone to vendor bugs, harder to troubleshoot, more things to learn and then forget if not used often. More broadly, I assume the reason to try to use IPv6 for this, rather than either sticking just with MPLS or inventing something new, is to leverage IPv6's existence, widely available implementations and pretty close to current and definite future commoditisation. Leveraging what already exists for the cost and time benefit may mean making some compromises to gain from commoditisation. RFC8200 IPv6 forwarding and IPv6-in-IPv6 tunnelling are commodity, because they're methods as old as RFCs 1883 and 2473, and are widely implemented and deployed. Extension Header insertion is not, and therefore using it is de-commodifying IPv6. The commodity benefits of IPv6 disappear if fundamental changes are or need to be made to IPv6's operation. EH insertion is a fundamental change. I think the objection to tunnelling is really be because the IPv6 SRH header is too large, because of the use of 128 bit IPv6 addresses as segment identifiers. "Scrounging" bits somewhere else to try to minimise overhead is avoiding solving the problem where it is caused. The TRILL people had this problem, as they considered 7 octet IS-IS IDs to be too large to include in the TRILL header. They solved it be using 16 bit "nicknames". "3.7. RBridge Nicknames Nicknames are 16-bit dynamically assigned quantities that act as abbreviations for RBridges' IS-IS IDs to achieve a more compact encoding ..." https://tools.ietf.org/html/rfc6325#section-3 Regards, Mark. From nobody Fri Dec 1 16:50: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 526A8126C25; Fri, 1 Dec 2017 16:50:32 -0800 (PST) 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 HcTGN5x6vmGb; Fri, 1 Dec 2017 16:50:30 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 D6A6A126C26; Fri, 1 Dec 2017 16:50:29 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id e10so9129863uah.10; Fri, 01 Dec 2017 16:50:29 -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=OrCihBXELXXOpEob6QiYJb59Aqh6fg7XmRSjv/zlKc8=; b=gvFiIZ7jLOQwY8cZIZWsdCDz6TeB8J6lV6VOnNhx8MJ4vRAPO+RcHvEbJ+q3zSAveH SbtYy7QAo25o6P1CWKQdLZ+zkodD4PWAF6zeCLMfzKjYl4NtT5ixMJutQIBoFDyAwOVP sGERDjLCxEJv3gWDOG+zHgMx/uadf+WE5N7I4db6+01O7RRfVTsm7pR6mKesJncWXYr6 FYOrtHBxHC04KzLcAlg6lkMZWd1/7wRUgFq3KC+QL9ZDAEm9Pp8UowZMEbNQWIKuoVDP qDNe+UwObHqqnGUq9rMbXcyUtCL4fooU4LqQgebCK8tEzutJch3WDR/4F238IVd0HZDb XkkQ== 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=OrCihBXELXXOpEob6QiYJb59Aqh6fg7XmRSjv/zlKc8=; b=P04dCXVavYnIJibRzfkcnoEUTMnIBQ1hlNX6BFyPZzZ2Jwwx+SSuV6S/0hd3L0p1oC Le50ePJDQ/GEHi7opVqbJi/R438cC6JpHTOgtSGavRRkPR41rqCYhF4WupzERhUVUuPh RD9bXcRW0BhogVojxENx7JjwowcnAPnL10qJHFjHY9OI0Tog1P50JlWJpc7hOVxkvwZF hZDrIr0R0GzYuTSru0g0gfqvYaO4UnwPGgAvVK0KephYD9WRjWUj5v5ZFEfsVfH3kPxa 4hVYsvc1wBb4n0GixDXBJxbv0C7g/oEmE1huoOelmb6APApfwgQ1l6YOqT2T3FhRktr0 oGtA== X-Gm-Message-State: AKGB3mKngDZcfO3/3mruZK5oCEHyGlDh2+9kZ1jLd4A5lZaSu3nD+fF1 njzxxKVrVyFdei8Ynm3EOYvvMfYF1Z9+VGBN7go= X-Google-Smtp-Source: AGs4zMaJNlLLqF3XQeoSSbXT4UrJGcvuJrOzCvqLzvsT35b1ImriqL4skAinrukOtHppBeOqvNAllrw2HQuZ4ZozPUY= X-Received: by 10.176.78.17 with SMTP id g17mr6099898uah.169.1512175828482; Fri, 01 Dec 2017 16:50:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.129 with HTTP; Fri, 1 Dec 2017 16:49:57 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> From: Mark Smith Date: Sat, 2 Dec 2017 11:49:57 +1100 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Robert Raszuk Cc: Tom Herbert , Fernando Gont , draft-voyer-6man-extension-header-insertion@ietf.org, 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: Sat, 02 Dec 2017 00:50:32 -0000 On 1 December 2017 at 09:07, Robert Raszuk wrote: > Tom, > > The biggest advantage of SRv6 in contrast to SR-MPLS is that the SRH (one or > more) are not modified through the SR applicability of the packets. > I'd have thought the biggest advantage and actual motivation for using IPv6 for this was to leverage IPv6's near and definite future commodity. MPLS required forklift upgrades to networks, if you use IPv6 per RFC8200 (and its predecessors), the majority of existing IPv6 networking devices will work and can continue to be used without change. and only those that are doing something special need to be changed. > So node which understands SRv6 can generate ICMP to both src of the packet > (poor host) as well as ingress node in SR domain (as it is explicitly listed > in Ingress Node TLV of first SRH). Node which does not understand SRv6 will > likely only send it to original src .. but this is a feature not a bug. This > is how traceroute works. No, it is not the same as traceroute operation. Traceroute works on the assumption that the packet headers in the ICMP response payload match those of the packet that triggered the ICMP message. That is how the host running traceroute knows which traceroute process to send the API error message to that then generates the traceroute hop output. If the traceroute source host sends IP/UDP or IP/ICMP to trigger the ICMP messages for tracerouting, yet receives in the ICMP payload "IP/SRH/UDP" or "IP/SRH/ICMP", and doesn't understand the SRH header or isn't enabled to understand the SRH header and read past it (which is probably going to be all end-user hosts), how can the receiving host know which traceroute process to send the API error to? Traceroute won't report the hop because it won't receive the sockets API error message that reports it. It isn't just traceroute that relies on this, it is all of ICMP. EH insertion violates that assumption, which is why EH insertion can or may cause many unexpected ICMP protocol and operational failures. PMTUD is one of the main examples. > > If you do encap how will host now see all the nodes on the way traceroute or > tracepath ? They don't see link-layer hops today. An IPv6-in-IPv6 tunnel is using IPv6 as a link-layer. That's the point of an IPv6-in-IPv6 tunnel - to make an IPv6 network appear as a single link-layer hop. > Do you think that hosts admins will be happy to be blinded by > 6man ? > Host admins aren't the actual audience for traceroute, network operators troubleshooting networks are. We're well familiar with troubleshooting virtual links that may or may not hide the actual physical topology and infrastructure, because we configure and operate it. Ideally host admins should never need to run traceroute because the network is designed and being operated well enough that paths that hosts use over it are predictable and testable within the network. > Btw I am not the one who ever claimed applicability to "controlled networks" > or "wall gardens" so don't try to use that one with me :)). For me the much > bigger question is what should go into data plane and what is better to go > in control plane. We may end up with both and let customers/operators > choose. But hand waving that doing innovation in data plane is scary is not > the approach I would endorse. > I'll ignore the further logical fallacy appeals. However, I'll address a point about innovation. Innovation commonly occurs within existing constraints, to avoid needing to "boil the ocean". All those innovative electric and self driving cars and trucks we're hearing about daily? They don't require that we rip up and replace all the roads, the street signs or traffic lights, or widen the lanes. They're compatible with our existing road infrastructure, which is one of the significant values of them as an innovation. The required costs and resources to adopt them are far lower because of the compatibility with the existing infrastructure. If they required changing both the vehicle and the infrastructure they ride on or in, they wouldn't be called cars, and would cost far more money to develop and deploy (and would be called "Hyperloop" for example), and need to carry far greater numbers of people at once to justify the expense. They wouldn't be individual or small group transport vehicles, and wouldn't be within financial reach of most individuals. Compatibility is one of the 5 factors that influence the adoption of an innovation. There's a summary of all 5 in this presentation starting at slide 8 - http://www.users.on.net/~markachy/The_Rapid_Rise_of_the_MMHH.pdf > We would be still doing token ring or FDDI .... > Another attempt to use emotional appeal rather than technical argument. Please stop trying to use that method to argue your point, it doesn't work. Regards, Mark. > Cheers, > R. > > > On Thu, Nov 30, 2017 at 10:54 PM, Tom Herbert wrote: >> >> On Thu, Nov 30, 2017 at 1:25 PM, Robert Raszuk wrote: >> > Tom, >> > >> > Imagine the case where packets are subject to go via service chains. I >> > can >> > steer the packet to the router which has service nodes connected to it >> > but >> > original src address may be used to decide which service given packet is >> > subject to take. >> > >> > Sure I can impose an SR function and map it up front such that the >> > router >> > above would never need to inspect src address, but why to construct such >> > architecture which only allows limited set of network programming as >> > opposed >> > to offer the choice on how to setup things by network operators ? >> > >> Robert, >> >> Because the architecture, or at least protocol, is not correct. >> >> Suppose a device inserts an EH into a packet that downstream causes >> the packet to be dropped and generates an ICMP error which goes back >> to the source. What is a source host supposed do with this? It might >> be able to determine that it didn't send the EH, and if it's lucky it >> might even be able to parse the offending EH and maybe even sees the >> problem that caused the error. But then what? How does the host tell >> the network to stop mucking with its packets so that they no longer >> get dropped and the source host doesn't get blamed? >> >> ICMP handling is just one of several issues that needs to be >> addressed. If the only answer is that these aren't concerns because >> the protocol is only deployed in controlled networks, then I claim >> that's nothing more than hand waving which is not robust and doesn't >> scale. >> >> Tom > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Dec 1 23: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 1445B1276AF; Fri, 1 Dec 2017 23:15:25 -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 RYWc0ZwhUkVL; Fri, 1 Dec 2017 23:15:21 -0800 (PST) Received: from smtp.uniroma2.it (mysmtp.uniroma2.it [160.80.6.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 68A68120713; Fri, 1 Dec 2017 23:15:19 -0800 (PST) Received: from smtpauth.uniroma2.it (smtpauth.uniroma2.it [160.80.6.47]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id vB27F8a8015113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 2 Dec 2017 08:15:14 +0100 Received: from [192.168.1.127] (93-41-116-249.ip81.fastwebnet.it [93.41.116.249]) (authenticated bits=0) by smtpauth.uniroma2.it (8.14.3/8.14.3/Debian-9.4) with ESMTP id vB27F41B007835 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 2 Dec 2017 08:15:05 +0100 Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Mark Smith Cc: draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> From: Stefano Salsano Message-ID: <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> Date: Sat, 2 Dec 2017 08:15:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: it-IT Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2015 X-Virus-Status: Clean 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, 02 Dec 2017 07:15:25 -0000 Il 2017-12-01 23:07, Mark Smith ha scritto: > > I asked numerous times (at least 3 from memory), what is wrong with > exclusively using tunnelling for this. I think eventually Robert said > because of the tunnelling overhead. > > The trouble with this argument is that this draft doesn't exclusively > propose extension header insertion, it also describes using > tunnelling. The only distinction between which method to use is > whether the packet originates within the SR domain ("Source Domain and > Packet Journey") or originates externally to it ("Transit through a > Source Domain"). So tunnelling overhead is apparently quite acceptable > as long packets happen to come from outside the SR domain. I can't see > anything that explains why packets that originate internally can't or > must not be tunnelled. Hi Mark, with the first tunneling operation you create a new packet that originates in your SR domain. We definitely want it, so the further SR insertion will only be applied to such packets (and hosts outside the domain will not receive unexpected ICMP...) and we believe that it is worth paying the tunneling overhead here. We think that for further operations that require adding of SRH information to such packets originating in your SR domain, the SR insertion is more efficient than tunnelling into a new packet. This is both from the point of view of the packet size (and increase of packet headers size) and from the point of view of the cost of packet manipulation operations. There can be scenarios in which you have more than one such operation to be applied to the packet, let us assume two. If you go for tunnelling you have the first encapsulation, then two more IPv6-in-IPv6 encapsulation in the same packet, for a total of 3 encapsulations. If you go for tunneling + SR insertion you only have the first encapsulation and then "simple" mangling of SRH header. ciao Stefano > > So the example SR domains in the draft, which is presumably the same > domain, support both insertion and tunnelling to achieve the same and > single goal of adding SRH information to a packet. Seems unnecessarily > complex to support two methods that achieve the same functional > outcome. More prone to vendor bugs, harder to troubleshoot, more > things to learn and then forget if not used often. > > More broadly, I assume the reason to try to use IPv6 for this, rather > than either sticking just with MPLS or inventing something new, is to > leverage IPv6's existence, widely available implementations and pretty > close to current and definite future commoditisation. Leveraging what > already exists for the cost and time benefit may mean making some > compromises to gain from commoditisation. > > RFC8200 IPv6 forwarding and IPv6-in-IPv6 tunnelling are commodity, > because they're methods as old as RFCs 1883 and 2473, and are widely > implemented and deployed. Extension Header insertion is not, and > therefore using it is de-commodifying IPv6. The commodity benefits of > IPv6 disappear if fundamental changes are or need to be made to IPv6's > operation. EH insertion is a fundamental change. > > I think the objection to tunnelling is really be because the IPv6 SRH > header is too large, because of the use of 128 bit IPv6 addresses as > segment identifiers. "Scrounging" bits somewhere else to try to > minimise overhead is avoiding solving the problem where it is caused. > > The TRILL people had this problem, as they considered 7 octet IS-IS > IDs to be too large to include in the TRILL header. They solved it be > using 16 bit "nicknames". > > > "3.7. RBridge Nicknames > > Nicknames are 16-bit dynamically assigned quantities that act as > abbreviations for RBridges' IS-IS IDs to achieve a more compact > encoding ..." > > https://tools.ietf.org/html/rfc6325#section-3 > > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- ******************************************************************* Stefano Salsano Professore Associato Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Cell. : +39 320 4307310 Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* From nobody Sat Dec 2 10:05: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 0C065127ABE for ; Sat, 2 Dec 2017 10:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 VwWrp0-f3Czm for ; Sat, 2 Dec 2017 10:05:53 -0800 (PST) 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 C64801200FC for ; Sat, 2 Dec 2017 10:05:52 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id u10so16791528qtg.2 for ; Sat, 02 Dec 2017 10:05:52 -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; bh=ZMG2dmHmYvJcDzJrLGVf9jqeyIr54WuXYfwXD+Tbb0M=; b=uxfyhx25yqwCWaD48NhNZOO4e1tk8a/5BGdxy5WFoyS865gduem3rlinZRe2Fuv+X5 2UGTpWz0V064kfNoO7srClj1ReOmAtLDoovgxZxwT50tfp2slr/H9rCic/jkQi1f4NDP 37VRM2USlioXu3dnquq55TapbzxtTw8oyOPLEYFeII97IqbEZ6vvTasBaA8jl13HNOU3 GQ6KacwupVxtAR1aGyBfGCIJ6KhkAj4sGaNwAJED3NwtqRJfk7obKN2LvPzNL3eGpSou /8f5/6+a3BWT7ZJfDQHFjKiOOOwqF67ZWXFwwZmcpnaQQr1044XLp9Gc//UGisdrjG8n mQ9A== 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=ZMG2dmHmYvJcDzJrLGVf9jqeyIr54WuXYfwXD+Tbb0M=; b=W6Wv8Orz/OnR2JIBBVpDFearhYwBojhCWavDAEl7kYkyy2m6s+yzRMhEIHK9DAjRKd J8gBxPYgt5S1SexNEXMr0jxB6HPq+JUBHqrNOqL6CQK1KWk+EwvOkw+/nJc7XQWTqDKZ ufO7SQNj9ToDKnAB0d+eLFKBJeVDT8r+DQcCMh0xRENHItytSgzmKvl5JQIQu7S809JG vj6wX7ckXxFng6+Aj5MD6R8LRcnaNCuuoaJyR/o0a1RXhx3xX27oj1d+FoXwqgDP5uC8 SwSIeQCfNkRvDZTf4Z8516+ekbDiyA2iSnpEc3Gn1QNfGG3r0/vKx37UThyXUqCC8rbb l+gA== X-Gm-Message-State: AKGB3mJVmuE4gKdL3nix+o6oXy9pOXRj7sCXH4vvD8dYSNuKw3WEXz/E ua+OLM6hzr+vItsmGdpV7VjanSvrWOkHLDIgxJMthQ== X-Google-Smtp-Source: AGs4zMYwT7Wh2U7rinZb4YrFYL1U3S2Pq/6MSdMgpBJlajyZZ3pu6G/mMZ7x3DIKd2fuO8bBJRZLwAh2DU8QCKLYp8g= X-Received: by 10.200.3.158 with SMTP id t30mr14188869qtg.149.1512237951822; Sat, 02 Dec 2017 10:05:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.121 with HTTP; Sat, 2 Dec 2017 10:05:51 -0800 (PST) In-Reply-To: <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Tom Herbert Date: Sat, 2 Dec 2017 10:05:51 -0800 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Stefano Salsano Cc: Mark Smith , draft-voyer-6man-extension-header-insertion@ietf.org, 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: Sat, 02 Dec 2017 18:05:55 -0000 On Fri, Dec 1, 2017 at 11:15 PM, Stefano Salsano wrote: > Il 2017-12-01 23:07, Mark Smith ha scritto: > > >> >> >> I asked numerous times (at least 3 from memory), what is wrong with >> exclusively using tunnelling for this. I think eventually Robert said >> because of the tunnelling overhead. >> >> The trouble with this argument is that this draft doesn't exclusively >> propose extension header insertion, it also describes using >> tunnelling. The only distinction between which method to use is >> whether the packet originates within the SR domain ("Source Domain and >> Packet Journey") or originates externally to it ("Transit through a >> Source Domain"). So tunnelling overhead is apparently quite acceptable >> as long packets happen to come from outside the SR domain. I can't see >> anything that explains why packets that originate internally can't or >> must not be tunnelled. > > > Hi Mark, > > with the first tunneling operation you create a new packet that originates > in your SR domain. > > We definitely want it, so the further SR insertion will only be applied to > such packets (and hosts outside the domain will not receive unexpected > ICMP...) and we believe that it is worth paying the tunneling overhead here. > Stefano, The problem is that almost all hosts are outside of the SR domain, even ones attached to the local network. If hosts were within the SR domain they could just source packets with the right extension headers or encapsulation. But that is not common, especially in a public network. So it seems likely nearly all packets would end up being encpasulated anyway (i.e. the packet flow in section 3 will be common). If packets are tunneled when they enter the domain then that should provide sufficient isolation so that the encapsulating node can use whatever extension headers it wants (e.g. tunneling should ensure that source hosts won't receive unexpected ICMP). But then that's not EH insertion, that is sourcing a packet with EH in compliance with RFC8200. The only argument for EH insertion then would be if some intermediate node in the domain inserted something; this at least only affects packets sourced within the domain so information is less likely to leak out of the domain. However, in that case why not do the segment routing at the ingress node of the domain in conjuction with the encapsulation and avoid the complexities needed to make EH insertion work correctly? > We think that for further operations that require adding of SRH information > to such packets originating in your SR domain, the SR insertion is more > efficient than tunnelling into a new packet. > > This is both from the point of view of the packet size (and increase of > packet headers size) and from the point of view of the cost of packet > manipulation operations. > Packet manipulation operations where? At an intermediate node processing is more likely to take a performance hit because of the presence of extension headers regardles of whether they were inserted directly or in an encapsulation, An assumption that more bits in the packet always reduces efficiency would be incorrect. For instance, we have shown on real hardware that GRE/UDP/IP is more efficient than GRE/IP. This is because network devices have optimized for processing UDP/IP as opposed to GRE/IP so the benefits of additional eight bytes UDP header outweighs the cost. A performance analysis based on empirical data should be in the draft if efficiency of packet manipulation is a primary motivation. > There can be scenarios in which you have more than one such operation to be > applied to the packet, let us assume two. If you go for tunnelling you have > the first encapsulation, then two more IPv6-in-IPv6 encapsulation in the > same packet, for a total of 3 encapsulations. If you go for tunneling + SR > insertion you only have the first encapsulation and then "simple" mangling > of SRH header. > I understand how nested encapsulation could work to cross multiple domains, I don't see how this would be done with SR insertion. Maybe the intent is that packets will have a stack of routing headers? Please elaborate this use case in the draft. Tom From nobody Sat Dec 2 11: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 5A07E126B6E; Sat, 2 Dec 2017 11:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 v5N3IMO8pleA; Sat, 2 Dec 2017 11:01:28 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 B3D5A128CD5; Sat, 2 Dec 2017 11:01:27 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id y21so13205255wrc.1; Sat, 02 Dec 2017 11:01: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=dMp/dN0cxHG3KSdHhG+lCRRQgnNiCHoaqMH1VfV06Ts=; b=hddqMOqsKCZjwYQRAF+gs0grRkj7bxOTuDsWLGiR0AI8zGtZsgPgPSliHBMJARv0sh cysVgg7WZ5HTkuYGwr8/s4Mozr3YGKbyEV25cWlciSVHoY+j5YY2+0lob4NsrJ/hngPH j+UQeTAthWdYTd2PLqv/GOJ2my4XyQjAPKaI9FZfohb3bTgth4MIML73MeFKsqpwReI0 DW74duS4lEuEMGARzp5nKuiqbg3sDAK2XHhPhhefye2iohftuVtUAqNC1/+i98/7slQ5 GBESY8sTFL+P2FeMh6FqOtha7+bhDnZKal5u+gWpdYqpvjJKobkoRgyH0gxy++S+tPQu 8MLg== 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=dMp/dN0cxHG3KSdHhG+lCRRQgnNiCHoaqMH1VfV06Ts=; b=h8N9rW0dwF9zoStBIOSujvIVa7m9G0tlW8p7CLhFf+5xYiWVmCb9i+T7IYxXf7OuZV JexHqBKll2ZCxtQdaB07pIusRBw48dT2M9CcYqKNXHlTf5BIwE0lPg6pc2/BHpxdc7gX znpTCCU3gZLM2eB8G5bsQmB2tuId4szuLFUH+K6Pe1I+lWD3ABDgBsaHvaL1t450FWAu xBmmA0VSulouEFUsrNt2rVqn//ZxcH46ZXgLiRij7D8YtXZGfQio3WlH6Y7PrQkHiqza dDRTz8LLbvhLLx6NtvbDK7JEHh5nOpWAh54SDy19Lyusb7lyb66PcuZaoexhaDXRY3Fw m/iQ== X-Gm-Message-State: AJaThX7AFibZ6SvHPRm9ggC35KQUBMfQwIgnErQJN+pRHWX6EvofUT6c SFqniDqpuLs4XmjjSqi/X4yJ+LhjLFO48i+DO8A= X-Google-Smtp-Source: AGs4zMaOUWi4OCjsvI5dlDYnzUBWjBZFpii2DpKzOy+iQCOY085T5ck7hb3UK8ky62+Fg2VkH4x28vN/pQZwwru72h0= X-Received: by 10.223.157.206 with SMTP id q14mr8123650wre.223.1512241286007; Sat, 02 Dec 2017 11:01:26 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Sat, 2 Dec 2017 11:01:25 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Robert Raszuk Date: Sat, 2 Dec 2017 20:01:25 +0100 X-Google-Sender-Auth: FgF2H6qb3bK5kikWEEes4JLlodo Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Tom Herbert Cc: Stefano Salsano , Mark Smith , draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG Content-Type: multipart/alternative; boundary="f403043990d4aad427055f601cfd" 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, 02 Dec 2017 19:01:29 -0000 --f403043990d4aad427055f601cfd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BTom,=E2=80=8B > However, in that case why not do the > segment routing at the ingress node of the domain in conjuction with > the encapsulation and avoid the complexities needed to make EH > insertion work correctly? > =E2=80=8BBecause in this particular case what is being done is a *local rep= air*. =E2=80=8B Local means that packets are redirected at the node which first notices the failure (usually adjacent to the link or node failure) which is maximum order of 10s of ms. Yes FIBs/data plane of those nodes are programmed ahead of failures with backup rewrites too. There is no time to propagate such information in the control plane to ingress such that new/adjusted SRH is imposed to achieve comparable repair results. That is happening in parallel to packets already being under local protection, but takes 100s of ms or even seconds for all control plane to converge. That is what we call fast connectivity restoration vs protocol convergence. Completely different things. So yes there are networks which only use control plane convergence OSPF/ISIS or even BGP and do nothing to protect packets locally when failure occurs but those are very bad examples of network design or choice of vendors which can not perform local repairs. Thx, R. --f403043990d4aad427055f601cfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2=80=8BTom,=E2=80=8B
=C2=A0
However, in that case why not do the
segment routing at the ingress node of the domain in conjuction with
the encapsulation and avoid the complexities needed to make EH
insertion work correctly?

=E2=80=8BBecause in this particular case what is being done is a *loc= al repair*. =E2=80=8B Local means that packets are redirected at the node w= hich first notices the failure (usually adjacent to the link or node failur= e) which is maximum order of 10s of ms. Yes FIBs/data plane of those nodes = are programmed ahead of failures with backup rewrites too.=C2=A0

There is no time to propagate su= ch information in the control plane to ingress such that new/adjusted SRH i= s imposed to achieve comparable repair results. That is happening in parall= el to packets already being under local protection, but takes 100s of ms or= even seconds for all control plane to converge.=C2=A0

That is what we call fast connectivity res= toration vs protocol convergence. Completely different things.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
So yes there are networks wh= ich only use control plane convergence OSPF/ISIS or even BGP and do nothing= to protect packets locally when failure occurs but those are very bad exam= ples of network design or choice of vendors which can not perform local rep= airs.=C2=A0

Thx,R.

--f403043990d4aad427055f601cfd-- From nobody Sat Dec 2 11: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 6D8EA124BFA for ; Sat, 2 Dec 2017 11:11:50 -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 tzXtnZYAOMv1 for ; Sat, 2 Dec 2017 11:11:49 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 0F680120727 for ; Sat, 2 Dec 2017 11:11:49 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id f12so5882382pgo.5 for ; Sat, 02 Dec 2017 11:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=abhr3wlBo1h9WuQy255rTMCV+7Eauq3CtLidlWQelW0=; b=uKCse4sq6sU0fQaeq6y5hn1jfg2RhvXg6JShYrtcTGHB8bDG/PBIjfoqBHYP+5yRxO FpO5ZJb0TtkOwSO+kgoK5Be3jAwvXwtLjlIp/HBftaSBzu32rj/1cR8ofhKmZiMzmuGA Jq3pCQJOcLtbqjah2jZ7Oc3EkjzU5mUk+YiGEActP71v9YDrsZQTvfNhuZXu8+TF7Rc1 Tn6tFRiVwM/SpU5D1bOOlETG0RVhBkhq4hA5uJeuMbcr/fxwveAOpQuP+1C+6vZmmUoe v7DsrnzdhO5qG921k3Nm/khBcNmNqD5izdPgioVW01fyJjmZwOvgdcLvSG6Y5SywUGPK LO4A== 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:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=abhr3wlBo1h9WuQy255rTMCV+7Eauq3CtLidlWQelW0=; b=eUyl/aph9tatn/gfYRIgWxSjmGP55YSzdzeYzk1c4mY4X9TExt1NSftPe3inC3OX7O K/oII/uMouVNycmT4v1DhEk1tLcpqKqHjFppv0hGbTNZvoKUttUWDPZAntuTex0v9bxl EBUNyfmcj3eIRP5H56/5nYoqNKLC/uftQ4JvRVvfQUJPwLTXGH0LNaLnxZrhMXRLvNrZ TBggv0jRBJjkTW2/zstBr9f+Tz47YY8Lr/QlT+rP7fyDd9sV8IoRGFwNx0YUfya2JDeV wkdrN2btKav5ldGd+sGKqA6ckRrUZjhkrC9kG/TB5KoR89Ki5X1y88vjtSUYvy7yoXW9 Rplg== X-Gm-Message-State: AJaThX7gQyLQrhr8vc/ylIcq7MlXKboSeDBrvEt4nA8KwkRaUvvK/hVN kbEnZB5oiuZscUfOM5PueLCOPA== X-Google-Smtp-Source: AGs4zMa3MFodxber0mEgTMft1k9zztaIX7cBwuk5laZL4CKXyd18SxZ2aSWOV8DrrXS9KYfwS3NYcg== X-Received: by 10.98.252.7 with SMTP id e7mr14359229pfh.12.1512241908352; Sat, 02 Dec 2017 11:11:48 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w184sm15107019pgb.36.2017.12.02.11.11.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Dec 2017 11:11:47 -0800 (PST) Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Stefano Salsano References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Brian E Carpenter Organization: University of Auckland Cc: ipv6@ietf.org Message-ID: Date: Sun, 3 Dec 2017 08:11:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: Sat, 02 Dec 2017 19:11:50 -0000 Stefano, On 02/12/2017 20:15, Stefano Salsano wrote: ... > We think that for further operations that require adding of SRH > information to such packets originating in your SR domain, the SR > insertion is more efficient than tunnelling into a new packet. > > This is both from the point of view of the packet size (and increase of > packet headers size) and from the point of view of the cost of packet > manipulation operations. This surprises me. I've had discussions with hardware designers (FPGA in particular, I think) who seriously hate the IPv6 extension header design on the grounds of the complexity and cost of manipulating the header chain at line speed. I can imagine that with a specifcally designed network processor, this might be less of an issue, but is the market big enough to support such an NP design? In any case it seems that the main issue is the need for linked-list operations to handle a header chain, and that is simpler if the new packet is compared to since there is no need to walk, break, and re-link the old header chain. These days, sticking an extra 40 bytes on the front seems unimportant compared with the linked list operations. Brian From nobody Sat Dec 2 11:23: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 5699E12778E for ; Sat, 2 Dec 2017 11:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 w3igRNHsm6RY for ; Sat, 2 Dec 2017 11:23:12 -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 6C4CF1271DF for ; Sat, 2 Dec 2017 11:23:12 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id c13so17123596qke.2 for ; Sat, 02 Dec 2017 11:23:12 -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; bh=Y2f4L5LBn0eQJEfeUXgXpjAv6fIRK3tT2d/lsV7PrXc=; b=DBDlJqMu45nAxiGztmge2Xc3r83YOYBCFFqCMaG8RBcG2R32ExAlkoHN6ssURopGqr +yt5K/gg3TCE8twI/3eUiAsUcGErx1Q8sAum3k7G4aSwecYg8NZ2ig8HZInjbOYryC9u OVLk0o58kZLbvbaLseWgGdxf2rYkJfQvsz+l1FHuYG7OMrGVBZShMSmpG5jCJ++T+grq bFanCHfudtUtk1TftZrhQwzWgPHq9NkhJKhZjAdecVWFE7S0cW2Yr8xRyn/kcVdjVK4u J/cNsFZY0zFU09rmUQwkkR4rHoeF1qaWzVariyh9SLSer7dsTOJHQOyZJQh2kpdzGTUp LyEA== 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=Y2f4L5LBn0eQJEfeUXgXpjAv6fIRK3tT2d/lsV7PrXc=; b=ZTFTV6MUFYerXYbSSZJcaBZFqit7Z39FYjHjmpYjNG46hKVvVsy8mowrJVLo6n8ZkH yM5Kor6N3ur5pTTDwYWNN6oHficVx5+1kSpuRHvf6OqPpCzrX0S/ij62itJgPbVlPacv 8dqm/qYsdXTooFXRP32/nnliQHBmV9cr3/KhTi2qklmWKzejAjrTF9rxbTIT48tkDEdP pTalTNNhcFFr6gCHFxhj3KnWtpxLBPnu/Or/S0wpxo8AtJmyULXWRnX9xL2CJGKSlTAn 75uDM+XvkFa7Kj7HPsHuPLlvg9hMgMi/RLE+nFygRB/OMJMuE9LveC38KuKLeEMEgIfM 9VRA== X-Gm-Message-State: AKGB3mIH6S6BDGBmPcLHjbEUKtY6fKU0K4W0BGKZws/ZtDX2odHabvn6 bWNQSL/XYVXqJxQ9+/IVOKZ8kL20TiaU62zAlGNwqQ== X-Google-Smtp-Source: AGs4zMaPK+IB4Jl2mNEB03uEaEPcyJH8mBIjrQxi4Thcf0tTpHlGtQLR7wUGk2Jah7ydm6g/sXqvfAexbHpd5QAXDYU= X-Received: by 10.55.23.195 with SMTP id 64mr13831308qkx.262.1512242591422; Sat, 02 Dec 2017 11:23:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.121 with HTTP; Sat, 2 Dec 2017 11:23:10 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Tom Herbert Date: Sat, 2 Dec 2017 11:23:10 -0800 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Robert Raszuk Cc: Stefano Salsano , Mark Smith , draft-voyer-6man-extension-header-insertion@ietf.org, 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: Sat, 02 Dec 2017 19:23:15 -0000 On Sat, Dec 2, 2017 at 11:01 AM, Robert Raszuk wrote: > Tom, > >> >> However, in that case why not do the >> segment routing at the ingress node of the domain in conjuction with >> the encapsulation and avoid the complexities needed to make EH >> insertion work correctly? > > > Because in this particular case what is being done is a *local repair*. > Local means that packets are redirected at the node which first notices the > failure (usually adjacent to the link or node failure) which is maximum > order of 10s of ms. Yes FIBs/data plane of those nodes are programmed ahead > of failures with backup rewrites too. > > There is no time to propagate such information in the control plane to > ingress such that new/adjusted SRH is imposed to achieve comparable repair > results. That is happening in parallel to packets already being under local > protection, but takes 100s of ms or even seconds for all control plane to > converge. > > That is what we call fast connectivity restoration vs protocol convergence. > Completely different things. > > So yes there are networks which only use control plane convergence OSPF/ISIS > or even BGP and do nothing to protect packets locally when failure occurs > but those are very bad examples of network design or choice of vendors which > can not perform local repairs. > Thanks for the detail Robert. Has there been any thought into using the flow label to switch the packet over alternate paths? That might be a zero overhead solution :-) Tom From nobody Sat Dec 2 11:30: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 098AD128B27 for ; Sat, 2 Dec 2017 11:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 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, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 NnT2-wEh2Ipn for ; Sat, 2 Dec 2017 11:30:21 -0800 (PST) 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 94EF51271DF for ; Sat, 2 Dec 2017 11:30:21 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 045EEB559A for ; Sat, 2 Dec 2017 14:30:20 -0500 (EST) 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=VNT nfj382wJNh/FlnkJM3TTS/rE=; b=njMXYYaGU+2AuxBnYLN+1EHe96wMCnCiBp1 h2q/REuJFlBSJpJU/KMzxbKhcxLRudD2f2awPjy4j/vKDKzGuEWKugngdrkgyDeB sBjmIRNIX3kqYNq4zUUTX/9C8SWlnIo+JSqLAWCg/rGHHVnALgQ2U5W4rmVnLTqr odr4bRDI= 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= f4Hgv8ceck4N3JfexE19w67/qY0yKFu44tGkQy91O/GdB/hrKbAZrD6JdltriU+L rJs96G950gHO7K3us2MvBEMp5tOXGYfDk/jwItxOxtCttg8l4K8hts8cfr6SbElu Ew0kusVS/MFl+2GWciErOzLmnQSA4FaW761tXoICYRo= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F01EBB5599 for ; Sat, 2 Dec 2017 14:30:19 -0500 (EST) Received: from mail-qk0-f174.google.com (unknown [209.85.220.174]) (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 7D5D4B5595 for ; Sat, 2 Dec 2017 14:30:19 -0500 (EST) Received: by mail-qk0-f174.google.com with SMTP id u184so17109231qkd.6 for ; Sat, 02 Dec 2017 11:30:19 -0800 (PST) X-Gm-Message-State: AKGB3mLcQarPDI5Q3+08JMvlbXtipsU/GkN0dA3oxzponb/s3zbRVa8v 4PSM6TwjUzUYzxLnpg3RPE+m3ca6jqJRKMILdwE= X-Google-Smtp-Source: AGs4zMay/8axuHndSoYdjrcvfPfu/BLRn3gYiDnm0Fl6asL+9AWiMWFbKsYPrr0y77x+egNkbsnseylPPTACpyRlxXI= X-Received: by 10.55.153.3 with SMTP id b3mr14187825qke.230.1512243018982; Sat, 02 Dec 2017 11:30:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.86.239 with HTTP; Sat, 2 Dec 2017 11:29:58 -0800 (PST) From: "C. M. Heard" Date: Sat, 2 Dec 2017 11:29:58 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: 6man Content-Type: multipart/alternative; boundary="94eb2c07d556f5ed10055f60838e" X-Pobox-Relay-ID: 3B6FCC26-D797-11E7-A4FD-575F0C78B957-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: Sat, 02 Dec 2017 19:30:24 -0000 --94eb2c07d556f5ed10055f60838e Content-Type: text/plain; charset="UTF-8" On Sat, 2 Dec 2017 08:15:04 +0100, Stefano Salsano wrote: > with the first tunneling operation you create a new packet that originates > in your SR domain. > > We definitely want it, so the further SR insertion will only be applied to > such packets (and hosts outside the domain will not receive unexpected > ICMP...) and we believe that it is worth paying the tunneling overhead here. > > We think that for further operations that require adding of SRH information > to such packets originating in your SR domain, the SR insertion is more > efficient than tunnelling into a new packet. > > This is both from the point of view of the packet size (and increase of > packet headers size) and from the point of view of the cost of packet > manipulation operations. Thank you for a direct and clear explanation of why SR header insertion is seen to be advantageous, and when. Performing encapsulation at domain boundaries should ensure that ICMP messages caused by SR headers don't go to nodes that are not part of the domain. > There can be scenarios in which you have more than one such operation to be > applied to the packet, let us assume two. If you go for tunnelling you have > the first encapsulation, then two more IPv6-in-IPv6 encapsulation in the > same packet, for a total of 3 encapsulations. If you go for tunneling + SR > insertion you only have the first encapsulation and then "simple" mangling > of SRH header. One of the questions that occurs to me is what happens if conditions arise at a node within the SR domain that mandate the insertion of an SR header when one is already present. This could occur in the fast reroute scenario of https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02 - section-3 where node 2 has inserted a SR header owing to loss of the link 2-to-3, assuming that we have a somewhat richer topology such as the one shown bel ow: (--- Source Domain ---) ( ) A---( 1-----2-----3-----9 )---B ( | | ) ( 4-----5 ) ( | | ) ( 6-----7 ) (---------------------) If node 4 detects failure of link 4-to-5, would that trigger insertion of a second SRH? If so, that would violate the recommendations in https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07 - section-3.2 . This situation would not arise if encapsulation were used instead of header insertion. One possible answer for this scenario might simply be that it is OK to have multiple SR headers within one packet. RFC 8200 mandates strictly sequential processing of extension headers and also mandates that if a routing header is expired (i.e., has Segments Left equal to zero) then the receiving node must proceed to the next header. So if the SRH inserted by node 4 appears before the one inserted by node 2, then everything should work, assuming that if a node processes an unexpired routing header it just forwards the packet and does not proceed to the next header. RFC 8200 does not say this explicitly, but it is implied by the header ordering recommendations in Section 4.1. Note that this answer would require a change to the SRH draft. What I am really trying to get at is not to advocate for one position or another, but rather to encourage the proponents of header insertion to consider, and document, corner cases such as these. That will help assure everyone on both sides of the debate that things have been thought through. Mike Heard --94eb2c07d556f5ed10055f60838e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, 2 Dec 2017 08:15:04 +0100, Stefano Salsano wrote:
> with the first tunneling operation you create a new packet that origin= ates
> in your SR domain.
>
> We definitely want it, so the further SR insertion will only be applie= d to
> such packets (and hosts outside the domain will not receive unexpected=
> ICMP...) and we believe that it is worth paying the tunneling overhead here.
>
> We think that for further operations that require adding of SRH information
> to such packets originating in your SR domain, the SR insertion is mor= e
> efficient than tunnelling into a new packet.
>
> This is both from the point of view of the packet size (and increase o= f
> packet headers size) and from the point of view of the cost of packet<= br> > manipulation operations.

Thank you = for a direct and clear explanation of why SR header insertion is
seen to be advantageous, and when. Performing encapsulation at domain
boundaries should ensure that ICMP messages caused by SR headers don't = go
to nodes that are not part of the domain.


<= span style=3D"font-size:10pt;font-family:'Courier New'">> There can be scenarios in which you have more than one such operation to be=
> applied to the packet, let us assume two. If you go for tunnelling you have
> the first encapsulation, then two more IPv6-in-IPv6 encapsulation in t= he
> same packet, for a total of 3 encapsulations. If you go for tunneling = + SR
> insertion you only have the first encapsulation and then "simple" mangling
> of SRH header.


<= span style=3D"font-size:10pt;font-family:'Courier New';color:rgb(34= ,34,34)">One of the questions that occurs to me is what happens if conditions arise
at a node within the SR domain that mandate the insertion of an SR header when one is already present. This could occur in the fast reroute scenario = of
https://tools.ietf.org/html/draft-voyer-6man-extens= ion-header-insertion-02 - section-3
where node 2 has inserted a SR header owing to loss of the link 2-to-3,
assuming that we have a somewhat richer topology such as the one shown bel<= /span>ow:


= 
        (--- Source D=
omain ---)
        (                     )
    A---( 1-----2-----3-----9 )---B
        (       |     |       )
        (       4-----5       )

        (       |     |       )

        (       6-----7    =
   )

        (---------------------)

If node 4 = detects failure=C2=A0of link 4-to-5, would that trigger insertion
of a second SRH? If so, that would violate the recommendations in<= br> https://tools.ietf.org/html/draft-ietf-= 6man-segment-routing-header-07 - section-3.2.<= br> This situation would not arise if encapsulation were used instead of header
insertion.

One possible answer for this scenario might simply be that it is OK to have
multiple SR headers within one packet. RFC 8200 mandates strictly sequentia= l
processing of extension headers and also mandates that if a routing header = is
expired (i.e., has Segments Left equal to zero) then the receiving node must
proceed to the next header. So if the SRH inserted by node 4 appears before
the one inserted by node 2, then everything should work, assuming that if a
node processes an unexpired routing header it just forwards the packet and
does not proceed to the next header. RFC 8200 does not say= this explicitly,=
but it is implied by the header ordering recommendations in Section 4.1.
Note that this answer would require a change to the SRH draft.

Wha= t I am really trying to get at is not to advocate for one position or
another, but rather to encourage the proponents of header insertion = to
consider, and document, corner cases such as these. That will help assure
everyone on both sides of the debate that things have been thought through.

Mike Heard

--94eb2c07d556f5ed10055f60838e-- From nobody Sat Dec 2 11:32: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 EA263126D85; Sat, 2 Dec 2017 11:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 CszJ4bCnWSnL; Sat, 2 Dec 2017 11:31:58 -0800 (PST) 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 56E0A128B51; Sat, 2 Dec 2017 11:31:57 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id v105so13254097wrc.3; Sat, 02 Dec 2017 11:31:57 -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=LUD4T93dieoqw2h034BDmh2nAJCfjHJr4wpAIRrubbc=; b=JEBNznQXJ51aUtBEx2wA4mPUjlkOUlMYyKJKJAG5Xau5h/BR5YxUttw3WbBxvvuPkk ixFADG9c6vqnyQxk7iU6IQmh08dxczNswC/16Ov36OhMAjuRoOOPGQgBA2kyxHuRwLAJ L0Pg2I8ogXt70U5pE7DAcwRTGIsnFgt8t+XbRO1kdKD6G6brwB4A34kE9h9L/vFeMNqD QLl9Tz61+bl6txJ8ycWpuAuiQ70/Aptf6JvUdvTK0ysDjkQiIWDCePk17A/gwz1tsJPH AM4mR+gFfqqZDZQmQZp3cNmigUu3Iu04XhEwoZrdn18yPNhSA1zPZAkMV4fSM6wZNRzv Ok/A== 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=LUD4T93dieoqw2h034BDmh2nAJCfjHJr4wpAIRrubbc=; b=Gvkne4pdF9wILzHYSb6HvAlKZPJdKAdD7XJB+mIF+y8OXJeuaxYu7Wi7aQ4kIadrwo +/89TVauQWoY+tzzn23f9xNRTB4P+1TuoOChDdGGD9CJC3hzPDuBNN6BGq7NpSEcB98A o7nP0BPegYdkRSWtkU0hHNXQwvlEhl1unuT5aKEy/v/S3yH5kqoarMycXnRn/R9JW0MZ exXjWxpWtobSQbo4jrgG6oeFX01fmz40+9s/kstlxaLSOlZ6a46UThYUDVVym+67JDBS CQz8dAgfJoLMPmuD/+3i36gmvuQS32djOvQgzxDPt2BXCUvftIVZdG+CvqPXYWsmgn9J O2Hw== X-Gm-Message-State: AJaThX5Rrxz0ebzdII0nnwVDa39Dz1snHLIL+RGMHCqtIyI5Ps13Msnk cM3pyWXeYw2EslpSha39o20sZ+MXds8kt8/k8WM= X-Google-Smtp-Source: AGs4zMYBbA6JbAoiiVd6VmtKMe6jIP/LQIMEc+AEMm+xmHPSiAOIthvF5qCNc7RRrbsnxyjUqN3GowjxkT1iN++ZR9c= X-Received: by 10.223.193.141 with SMTP id x13mr8409878wre.239.1512243115645; Sat, 02 Dec 2017 11:31:55 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Sat, 2 Dec 2017 11:31:54 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Robert Raszuk Date: Sat, 2 Dec 2017 20:31:54 +0100 X-Google-Sender-Auth: 2tMvQl4rZEhn-selYqwoghNKfDM Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Tom Herbert Cc: Stefano Salsano , Mark Smith , draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG Content-Type: multipart/alternative; boundary="089e08235958b8df99055f608909" 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, 02 Dec 2017 19:32:00 -0000 --089e08235958b8df99055f608909 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, > =E2=80=8B=E2=80=8B Thanks for the detail Robert. Has there been any thought into using > the flow label to switch the packet over alternate paths? That might > be a zero overhead solution :-) The issue is not at the node doing the actual repair switching ... the issue is at the other nodes which must forward the packet to achieve loop free native forwarding. So if we use flow label for forwarding now each IPv6 router needs to do three lookups ... flow label + SRH + dst address or even 4 if you include src-dst forwarding. In many cases of IP networks there is actually no need to apply anything to the packet. That's how LFA works. Here we are just talking about some topologies where you must augment given topology with directed forwarding to avoid loops. That is what TI-LFA delivers. Cheers, R. On Sat, Dec 2, 2017 at 8:23 PM, Tom Herbert wrote: > On Sat, Dec 2, 2017 at 11:01 AM, Robert Raszuk wrote: > > Tom, > > > >> > >> However, in that case why not do the > >> segment routing at the ingress node of the domain in conjuction with > >> the encapsulation and avoid the complexities needed to make EH > >> insertion work correctly? > > > > > > Because in this particular case what is being done is a *local repair*. > > Local means that packets are redirected at the node which first notices > the > > failure (usually adjacent to the link or node failure) which is maximum > > order of 10s of ms. Yes FIBs/data plane of those nodes are programmed > ahead > > of failures with backup rewrites too. > > > > There is no time to propagate such information in the control plane to > > ingress such that new/adjusted SRH is imposed to achieve comparable > repair > > results. That is happening in parallel to packets already being under > local > > protection, but takes 100s of ms or even seconds for all control plane = to > > converge. > > > > That is what we call fast connectivity restoration vs protocol > convergence. > > Completely different things. > > > > So yes there are networks which only use control plane convergence > OSPF/ISIS > > or even BGP and do nothing to protect packets locally when failure occu= rs > > but those are very bad examples of network design or choice of vendors > which > > can not perform local repairs. > > > =E2=80=8B=E2=80=8B > Thanks for the detail Robert. Has there been any thought into using > the flow label to switch the packet over alternate paths? That might > be a zero overhead solution :-) > > Tom > --089e08235958b8df99055f608909 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

> =E2=80=8B=E2=80=8B
= Thanks for the detail Robert. Has there been any thought into using<= br style=3D"font-family:arial,sans-serif">> the flow label to switch the packet over alternate paths? = That might
> be a zero overhead solution :-)
The issue is not at the node doing the actual repair switching ... the i= ssue is at the other nodes which must forward the packet to achieve loop fr= ee native forwarding.=C2=A0

So if we use flow label for forwarding = now each IPv6 router needs to do three lookups ... flow label + SRH + dst a= ddress or even 4 if you include src-dst forwarding.=C2=A0

In many ca= ses of IP networks there is actually no need to apply anything to the packe= t. That's how LFA works. Here we are just talking about some topologies= where you must augment given topology with directed forwarding to avoid lo= ops. That is what TI-LFA delivers.=C2=A0

Cheers,
R.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
<= /div>

On Sat, Dec = 2, 2017 at 8:23 PM, Tom Herbert <tom@herbertland.com> wrot= e:
On Sat, Dec 2, 2017 at 11:01 AM, Robert Raszuk <robert@raszuk.net> wrote:
> Tom,
>
>>
>> However, in that case why not do the
>> segment routing at the ingress node of the domain in conjuction wi= th
>> the encapsulation and avoid the complexities needed to make EH
>> insertion work correctly?
>
>
> Because in this particular case what is being done is a *local repair*= .
> Local means that packets are redirected at the node which first notice= s the
> failure (usually adjacent to the link or node failure) which is maximu= m
> order of 10s of ms. Yes FIBs/data plane of those nodes are programmed = ahead
> of failures with backup rewrites too.
>
> There is no time to propagate such information in the control plane to=
> ingress such that new/adjusted SRH is imposed to achieve comparable re= pair
> results. That is happening in parallel to packets already being under = local
> protection, but takes 100s of ms or even seconds for all control plane= to
> converge.
>
> That is what we call fast connectivity restoration vs protocol converg= ence.
> Completely different things.
>
> So yes there are networks which only use control plane convergence OSP= F/ISIS
> or even BGP and do nothing to protect packets locally when failure occ= urs
> but those are very bad examples of network design or choice of vendors= which
> can not perform local repairs.
>
=E2=80=8B=E2=80=8B
Thanks for= the detail Robert. Has there been any thought into using
the flow label to switch the packet over alternate paths? That might
be a zero overhead solution :-)

Tom

--089e08235958b8df99055f608909-- From nobody Sat Dec 2 11:47: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 19065128D44 for ; Sat, 2 Dec 2017 11:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 js6vnM7zbdWV for ; Sat, 2 Dec 2017 11:47:38 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 60E9D128CDC for ; Sat, 2 Dec 2017 11:47:38 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id g10so16902231qtj.12 for ; Sat, 02 Dec 2017 11:47: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; bh=AD4026ibZG9lQM1Ceo0+KD41DJfIKHXj+XNibg6D800=; b=SiQawUZVeFOZ4X4UF7kB6Zz2R6yMMYHnK56Gg77SIpZv3nnb+VOp/MdXxC9SFXqgRz fow8wloeTd3N5m9SDqlc/RKmxyQ+/288kYSliKKWp5gLjGD8a15Q7CPWKK9GX0pZ/bjN AgXnEw9CfTt1sHClE/nhMa3qcs91NhznQA/sUuCcBd8SxXRXfj96nsujIGR3KCxl2ZVu +ebZiGMkoBlI9MGuhEG4d3Q2fACg7/FoOw1uwErcarZ58ZH8e7stfOP/7HydF062OR/8 O8cBKToS2XYIDKFPaIpzb7foRBCDXyrsMnQTX/pDHfAcANSW2UIjUAaRY30tH5xOyMcq oz3Q== 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=AD4026ibZG9lQM1Ceo0+KD41DJfIKHXj+XNibg6D800=; b=U4ERqQhIogstExjDcCf9fl5TnR9af7xCCpJxtOdgdXc2EtU+8x+pMjMiCb1hnjQ4A3 hwYMFWnMFVTagFx7Ixr/mbJmZgzD/yeWT0E6q3rVlF0XkvUxeaOdJGuvdyvQFKJV1eXd 3qeJ5S8sdUxPVfj9uhMv9uvZlpFTlrKahIkUREMlU4ibL3ea/1Di4HWjObO9B6NIVknH nehhBpa+WAIN4SBYzfTxqG8XIz/N28clfy66vvaECupbRqLJk0vWGotYvcLdArYuRnT0 2xGGjUMYl7EHSmRtZJFK8LdL7arcsuD+2F1h37ue7R1YPjiCf+9Bgqnqx60z4fX3+OH/ Udvw== X-Gm-Message-State: AKGB3mLyHtMoHkEwvcsGRilN/8Vo9di2vtCNJKZYBNSl+vzHg1Hkam+Y 55AG2axXXCuYY0C0jZyvdmH4Zibv+zU90tau/vSXjg== X-Google-Smtp-Source: AGs4zMbs7BmpaoyqM12o7r7sKmlr36sG3A1HZhkQj+K+fdDzhzaz3SJYrCis4hjr7mFZIFttwbwXGM72aXO4Wmhwe4U= X-Received: by 10.237.54.165 with SMTP id f34mr7668910qtb.187.1512244057412; Sat, 02 Dec 2017 11:47:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.121 with HTTP; Sat, 2 Dec 2017 11:47:36 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Tom Herbert Date: Sat, 2 Dec 2017 11:47:36 -0800 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Robert Raszuk Cc: Stefano Salsano , Mark Smith , draft-voyer-6man-extension-header-insertion@ietf.org, 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: Sat, 02 Dec 2017 19:47:40 -0000 On Sat, Dec 2, 2017 at 11:31 AM, Robert Raszuk wrote: > Hi Tom, > >> > Thanks for the detail Robert. Has there been any thought into using >> the flow label to switch the packet over alternate paths? That might >> be a zero overhead solution :-) > > The issue is not at the node doing the actual repair switching ... the issue > is at the other nodes which must forward the packet to achieve loop free > native forwarding. > Right, the idea is that at each node the input flow label and dst map to an output flow label. All the flow label tables are constructed to provide give loop free forwarding and multipath selection. Routers in a domain need to participate (so a controlled domain is required), but this does not change the on-the-wire format of packets. IIRC a single depth label like this was proposed in some of the encapsulation protocols for this same purpose. > So if we use flow label for forwarding now each IPv6 router needs to do > three lookups ... flow label + SRH + dst address or even 4 if you include > src-dst forwarding. > SRH would be unneeded in this solution. Lookups would just be dst+flow label. Encapsulation at ingress is probably still needed if nothing else to be able to restore the flow label at domain egress. Tom From nobody Sat Dec 2 11:53: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 A98C2127866; Sat, 2 Dec 2017 11:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 KYAzQJSUaU7p; Sat, 2 Dec 2017 11:53:31 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 E2C82127058; Sat, 2 Dec 2017 11:53:30 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id f206so2117020wmf.5; Sat, 02 Dec 2017 11:53:30 -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=w9jiqnNE5Yjj1iMDFci837ILZQ0KQ61PAg6p0HQCrW8=; b=c7UbY2/Hk7ycnTO+PvPhEG2YktjwdJC0bjRR7UyFfU2M4PmJ/uwlCrSIRkzHou8h5b bzYVihqWkZtcZBpmYgT/O/tQQUyveQUfPe6v9xSGHttrV9YFFZ3d/IsjbF0/W5hCNICQ Gi7jE89qHkEafF0FcCGtrjYJt0W8aMkgv5E81PbL5QvId0CER/bt2Vnsp/UW3jv0Cm6K v9UzwnL0Z6ZvZnrg5yrJup6tAcAnyOe4QgOyEcwzcaKbCRnh18VLMtqTehlWTpvkYdxM ezamico/gE/IIVmigvRfDeytgA+nlwWYohLhjVhnp7ukgew1lQfjRsY57kE+nICQYlRR 1Mfg== 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=w9jiqnNE5Yjj1iMDFci837ILZQ0KQ61PAg6p0HQCrW8=; b=jAgXyDMqP5T3JKIgHp1ieNccAtq6XGBxEPFtfXXbHugM9EOXPIKBgxxYGXQq2NkOJ7 ozlNk6pojmnXgdOM/fPGHBAZTBLpPPECD/SuUHPnAjzJvmdEcPL1rrDm8s+h9DIFzfj+ 1zTfhLQuLm2NhmNqQDeYRuTw+P6RssaoVVGKCBuvcaEJUQmKNCFUMQNLfJZLTFv2T3F2 DOtrbKqeIXBdX6OjnzQs5n82rZznAckkqMEu+MlwW6PHIQBGCTnVz96uyqtedEl9P9Z9 5Bw2JA5Ofs83t9JDo4EJ8sPZgyM7nLai8vXY6BDAzp7XPKUvY2QmlzpEmH1VEsWiub4w j9sQ== X-Gm-Message-State: AKGB3mLo9xZW8sDVtQKO2pksc4DYcwq5wb9EEZBNDPxCbGuHq8b1z+4/ e71upm217IIs29wXmEfs/ZXAVPg0PZjZ4sVmk7o= X-Google-Smtp-Source: AGs4zMa7qPer9vAZwJlw9r0gvn3J82M5rZ5K93Itw6aMqBQv6p3ng2doHgiqDn8FwZOxSvgeeEpL8QA5lgZ0OCDDUg8= X-Received: by 10.28.46.67 with SMTP id u64mr3879022wmu.64.1512244409269; Sat, 02 Dec 2017 11:53:29 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Sat, 2 Dec 2017 11:53:28 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Robert Raszuk Date: Sat, 2 Dec 2017 20:53:28 +0100 X-Google-Sender-Auth: 19s8T1Mru4iIt3WYuez9qh3Bg9s Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Tom Herbert Cc: Stefano Salsano , Mark Smith , draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG Content-Type: multipart/alternative; boundary="001a11424216d405f8055f60d676" 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, 02 Dec 2017 19:53:33 -0000 --001a11424216d405f8055f60d676 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Right, the idea is that at each node the input flow label and dst map > to an output flow label. All the flow label tables are constructed to > provide give loop free forwarding and multipath selection. =E2=80=8BThat's essentially SR-MPLS :) =E2=80=8B SRH would be unneeded in this solution. =E2=80=8BTrue - but I was just counting in general node's forwarding capabi= lites=E2=80=8B. =E2=80=8BI think the less moving parts we standardize the better :) Best, R.=E2=80=8B --001a11424216d405f8055f60d676 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, the idea is that at each node the input f= low label and dst map
to an output flow label. All the flow label tables are constructed to
provide give loop free forwarding and multipath selection.
=E2=80=8BThat's essentially SR-MPLS= :) =E2=80=8B

SRH would be un= needed in this solution.

=E2=80=8BTrue - but I was just counting in general node's forwarding = capabilites=E2=80=8B.=C2=A0

=E2=80=8BI think the less moving parts we standar= dize the better :)

Bes= t,
R.=E2=80=8B

--001a11424216d405f8055f60d676-- From nobody Sat Dec 2 12:26: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 74EEF127058 for ; Sat, 2 Dec 2017 12:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 99LUp1k1cHeH for ; Sat, 2 Dec 2017 12:26:17 -0800 (PST) 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 DECBD120726 for ; Sat, 2 Dec 2017 12:26:16 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id b10so9297334qti.11 for ; Sat, 02 Dec 2017 12:26:16 -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; bh=qDvpg0P/uxX0GTMpZMGfxCKRQfsXYAGoQPhAOqUL49I=; b=PTWsteqdKB/iQHxF30N0xa0tQgPaRSIbJNiCpxZlZCECOMzXl7vyjcLe7qLCsaklDW h3ZwQWVhL2QR6i8J+NQThTFoe3pCPsFF4EGSSinNnbggHTzmwgmG+J1yLW4D9OlEaQqC 2JZfduxj1WkgX6FXC1PzqCBhqe4NUfdDwyOewWoBdlmY6uUnpCgvcQzYpPZ8aW4vaaK8 UFumG04WLaByJfdBnGfZonNuB32mahoOIMtvCePWk7AzfXXbxZOUzbcrdrNUE/xjLev3 YoEXnnsPwgFZ75/SG4TM/1BUKbmTvD8/6QuWCniw5xiuc5T+XBhsPnVwsqVMzoVM94a4 wkHA== 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=qDvpg0P/uxX0GTMpZMGfxCKRQfsXYAGoQPhAOqUL49I=; b=V0T0CIhDnvybpHUrE6/hs2qz+AwVOShbVdP+Brv4rMvd4LPK1kSMfQz2bkwgrgGO8b cJVzzPP/jdtLzrAZRL+vIuGfGl89JvoU2lElE1N5dGWGLIEY6lpj1r1H7N0PayzESZky tmHYGPHMkj6XxZ782dc0PO12+fth/0QwSY93AGF1BHKhpEgtmvqUiBbcXsV/fVvdFewD GfeJDY9bjGf6/sCJSm63ZxQxyKYST27Q9tgn4OPTbhiJs5ouUi6FFfIJTfLi0R8eHfIs +kGt+MJrBHNA69zgrsSZ1nXSeIqy4ITZFDO3y5NH/mfsfVa0BLugLe04dk5BvltJviwM 6ezQ== X-Gm-Message-State: AKGB3mIt7Q9Oyz0w4jvj3sAbs6aIBfLTQtfMNFIOXiCrDicsvN4VxAJv xoG3rt1/C8mnU8yY+ZF/zk/c/c4NvNKcHKTBM8mjjw== X-Google-Smtp-Source: AGs4zMZkrE87xZgcIHK9eqHMmwwgRtgcE4TxG4nhMC2uXsqUuTJVVhGRouMf7jo9/Sngwu+uAOLg6rcrhMwNIKg1t1I= X-Received: by 10.237.54.165 with SMTP id f34mr7782045qtb.187.1512246376005; Sat, 02 Dec 2017 12:26:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.121 with HTTP; Sat, 2 Dec 2017 12:26:15 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Tom Herbert Date: Sat, 2 Dec 2017 12:26:15 -0800 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Robert Raszuk Cc: Stefano Salsano , Mark Smith , draft-voyer-6man-extension-header-insertion@ietf.org, 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: Sat, 02 Dec 2017 20:26:18 -0000 On Sat, Dec 2, 2017 at 11:53 AM, Robert Raszuk wrote: >> Right, the idea is that at each node the input flow label and dst map >> to an output flow label. All the flow label tables are constructed to >> provide give loop free forwarding and multipath selection. > > > That's essentially SR-MPLS :) > >> SRH would be unneeded in this solution. > > > True - but I was just counting in general node's forwarding capabilites. > Do you expect segment routing to be in a general node's forwarding capabilities? All the past history seems to indicate that vendors don't want to do extension header processing in any fast path. > I think the less moving parts we standardize the better :) > Or more generally, the less moving parts we use the better :-) Tom From nobody Sat Dec 2 12:35: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 B41781200F1; Sat, 2 Dec 2017 12:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 9dfgmDIzeO8c; Sat, 2 Dec 2017 12:35:39 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 5BAB3126DED; Sat, 2 Dec 2017 12:35:38 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id g53so13390742wra.2; Sat, 02 Dec 2017 12:35:38 -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=If99pa545Xi6vA8A7JjIqJqjB0Cb/A+x4MfH44HkCVc=; b=BbHxHm8ilGbq8Msnh/fEwhSCbu0+YzoW+H/aAFb+9/VU4FxB0t++0eJ8AEOFogFzvW voCE0pzKcBg+1goFVkjUs6yg5KUPXgAVyd+2Vgcv5rAjcK1juz8kukTDJ+k8AtUhFL1g ctKAyv4J6+Iy6TUOOhhw3ZtkHwfeLxmPMUi9AgDkjJZ+tP1RHTgUwPyrhxygSza7ZmFc YuXg++Y66YXeVojZei760Lh+JPerk49B7mF9nWb4srsd5ZgPTnn1OSXYrxvMQFXTVJss GBdLE2Snb4EAn8dN39ZWzRaEzcMv6IXLzCo+tegyU1KjWmj+o7H8h0ksYcgHBb5yDHTl dxaQ== 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=If99pa545Xi6vA8A7JjIqJqjB0Cb/A+x4MfH44HkCVc=; b=swIg/M8dsMTQczfuBakvxYidjGz/ok0UzwH+hBDTREY2HVr/4F329aLbzAmJxHEjI8 PtviLkaAT/HGKVkuWoffXHkyBLOsYI+QFMIUfg7NcV7JITKvSiNBJJYy9Qb/QW77Krfe g+Dsr6qkSg25u7dlNVkDj/HjQ/vzANKUU1RhDYnAasRsoU7cFLELxQgZt3npR5kaVluq w/WPuyQxGNUED3tNACbZ9ZZ9Ywt+o7CbGejln2P3/f/Ep4dEdmSD8QbWrTH0yvnUA6lC CLqcQoSVOFLcIu0+DSaApEYe8+8wUu6GxZQTf9TEbC0ABTnObyddfRqYbYRrQp3Vv1LA BmLA== X-Gm-Message-State: AJaThX59BypePZl1zx3xUVrEt5TDVqsqVayOl2eaY4UZq/21Hg2kj06r 1Cua5Zsbi4pws15uSuCKXowUn8u7uKoMpQDJtd8= X-Google-Smtp-Source: AGs4zMamPXtfoAG02pA1HBhAlTK3pT+eOraEcbkvwkcz8VQVX4NZds5WopHBmk3tg5v0Gfv3fY64W3Q9Pul2pF9w3rE= X-Received: by 10.223.182.81 with SMTP id i17mr8785413wre.224.1512246936733; Sat, 02 Dec 2017 12:35:36 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Sat, 2 Dec 2017 12:35:35 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Robert Raszuk Date: Sat, 2 Dec 2017 21:35:35 +0100 X-Google-Sender-Auth: _Shqd7atL8bn7uqnP4jrHL9w09M Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Tom Herbert Cc: Stefano Salsano , Mark Smith , draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG Content-Type: multipart/alternative; boundary="f4030439df907a10e6055f616dbe" 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, 02 Dec 2017 20:35:41 -0000 --f4030439df907a10e6055f616dbe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Do you expect segment routing to be in a general node's forwarding > capabilities? =E2=80=8BI do. Based on the discussion with vendors or even forwarding ASIC= s manufacturers.=E2=80=8B Or more generally, the less moving parts we use the better :-) > =E2=80=8BVery true - I 100% agree. The crux is in finding the bare minimum = which will still meet good network design =E2=80=8Brequirements. //R. --f4030439df907a10e6055f616dbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Do you expect segme= nt routing to be in a general node's forwarding
capabilities?

=E2=80=8B= I do. Based on the discussion with vendors or even forwarding ASICs manufac= turers.=E2=80=8B

Or more gene= rally, the less moving parts we use the better :-)
=E2=80=8BVery true - I 100% agree. The crux = is in finding the bare minimum which will still=C2=A0
meet good network design =E2=80=8Brequirements.=C2=A0

//R.

=C2=A0
--f4030439df907a10e6055f616dbe-- From nobody Sat Dec 2 14:15: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 A96D7126C22 for ; Sat, 2 Dec 2017 14:15:43 -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 iyuVx_jFXPEv for ; Sat, 2 Dec 2017 14:15:41 -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 BA5FF1241F3 for ; Sat, 2 Dec 2017 14:15:41 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id y89so6189819pfk.0 for ; Sat, 02 Dec 2017 14:15:41 -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-language:content-transfer-encoding; bh=IqZodC/LeWR2q/4YXqhFWxk8cvDjaF1nB/jz0n4/N54=; b=l9zdlp7exzEro1WX9YEORSCgv4MgC07XlVSnrfjNhWG+ut2ol0Dbac/xdKmjxJXW4n 0FEa0ukfUGYo0z0Wjo5CiukbFzfZXT9/Ygy0yFNMQendyGULyVXotyDSoEcP00mISXFN EPL60/qq4N9qrFwdZQPWxf3JCrqXJXzsovl3FEXD37VzRsZa4ir84/RU+g4Dt1Z/rrO+ /duMXbOT1CGUWhSp1mmVdXpU56Rk0VRGAUIrd7Si26QM15vVIIcVYxE89SZ1bSLC/ah+ wS7aWeXHDMmox+jQNIfcWjlL9BofGkjw2QApzIMzCM0pQd/vl4xGaV55RLr37SR+JvoW 7S+A== 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-language:content-transfer-encoding; bh=IqZodC/LeWR2q/4YXqhFWxk8cvDjaF1nB/jz0n4/N54=; b=p+carcgJuJx4VEvftTDqiqwLpfXp/kDrGE4DMhb+bUc2EbpVtIq/DWuHEMI6ll1jBr fp2Fdu2dKlG+mBnSMG+3zyI6qDjQK2KhFQoI1T7aYv4WhtjaZ4+yOD12wKUPMPJXT4pZ /9qJuMe5sixsV6ixnfWAH4K+gHJEsX8CadmSb74o1zAxqe1xOHZ6sf5gNnY+JQtctQtM qadMovNI1+p9HxgxsnRNknSDFnOgMwVqED+/el8ot9lq9lJLtooRuXFJzSsYYpCDpYRb m4RjFa2mpzLOkkfvniRzzj8mbkf4pPlPyBlsoWzDNnR1PP+3cu3tke8fJwSCF2MYM9kq 8ExA== X-Gm-Message-State: AJaThX5HEiD03tKU6LOnAecY6RNx+7OWfp91wAlLtGM9ndAZknVtaMDb nt9QRWZ9msRlc6j7Jiqvfy+AbQ== X-Google-Smtp-Source: AGs4zMZsoyP4L35aUFPeWsqIXfMr6392WzrNnz43/L3FeQdDWddSkvFvuoJweaWBcIGsr8Km1OuAhg== X-Received: by 10.98.51.6 with SMTP id z6mr14857970pfz.34.1512252940937; Sat, 02 Dec 2017 14:15:40 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z25sm16541981pfe.121.2017.12.02.14.15.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Dec 2017 14:15:40 -0800 (PST) Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: ipv6@ietf.org References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1cf221bc-e2e3-bc04-6559-d01eff2e1232@gmail.com> Date: Sun, 3 Dec 2017 11:15:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 02 Dec 2017 22:15:44 -0000 On 03/12/2017 08:53, Robert Raszuk wrote: >> >> Right, the idea is that at each node the input flow label and dst map >> to an output flow label. All the flow label tables are constructed to >> provide give loop free forwarding and multipath selection. >=20 >=20 > =E2=80=8BThat's essentially SR-MPLS :) =E2=80=8B If you look at the early history of the flow label, which predated MPLS, this isn't a big surprise. (IPng-ologists also remember CATNIP, https://tools.ietf.org/html/rfc1707.) >=20 > SRH would be unneeded in this solution. >=20 >=20 > =E2=80=8BTrue - but I was just counting in general node's forwarding ca= pabilites=E2=80=8B. >=20 > =E2=80=8BI think the less moving parts we standardize the better :) It's true, but the flow label is already in every packet, albeit with different semantics. Brian From nobody Mon Dec 4 13:29: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 B6DC812896F for ; Mon, 4 Dec 2017 13:28:59 -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 vb6C2wF4-zJT for ; Mon, 4 Dec 2017 13:28:57 -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 6C61C1270FC for ; Mon, 4 Dec 2017 13:28:57 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id j124so9531297pfc.2 for ; Mon, 04 Dec 2017 13:28:57 -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=WbcCWMnIRNc4J555WFk2tm2HdbUWvgSsrFn/m1R9Kt0=; b=oxvc1BiKV+PK9sdmb6i1cj+s2U+RQs+khyEpwS5THxuyyjV8ANItfX5C0YndxhHkc4 j+1uG2N9a+5CpQ9fIOsDynuO2dE6MoAfho3qOl/OpHjtSUv75ViuY9Bvh9gx4ZMHxA1N HUg7L781QeHZAdKkhCYiRnxXINrmpnNA8AFqigTOP+DvR7GRfB9jcipDW2AdwzbNocJ2 cdjerLxSEYRrvtPq7O2v2YVigjIHJDQ+cCRGQ7u69qwLjuJz89sD4dP/facpVFwKU8Jb PqXGHP1OVqTIUBJ2o2TGuj23Mc2RZTsjkrJwvuCeFSxLVqdMTPi/rvUisASBWc7zWkOt k7bQ== 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=WbcCWMnIRNc4J555WFk2tm2HdbUWvgSsrFn/m1R9Kt0=; b=fxutwe4maEXUK2bjQTvyopBmQB30oIqluKR9wbjwKnRSDVbqE0WMRLW4XZY68jOkDi yogjTA5xL1xRMwnhVX6h1LShUl7KHFijmCVSbdyblrbHQPH5oGsNPawPYHUE01885v+3 Mas5KD1Mv4zPaLUeHSMZnB0EP8Cjz8SGC88FKsMwnNE95twCvDN8/1cJrxKaadUD58jM haLga/r7or9ZHodxHfqqFe4nFvwnIJpJZyCOjU8s64P5snnxDROKiwg+d+cOBgi3uUn0 tTnCb08w9ubO5bKAZX6MWj/GlZwdJ2VTic8WGRLSZwMwINMszciM5L13J2Gv8nilueEB Fh6A== X-Gm-Message-State: AJaThX4R9IcQb1quuOvlq8Quwc9nXZvPq7AmVEYuS4JL+phe9fER7tMT AgTm+0MZ+Bfm7F6zN2iDm1I= X-Google-Smtp-Source: AGs4zMY782NFkPRVYrJI0WpCiGekw8PBBMeKMFIwTqEHYL8EZYtvMt3egwef5DUsWIIt5qjRguqWBA== X-Received: by 10.84.193.3 with SMTP id e3mr15766710pld.300.1512422936996; Mon, 04 Dec 2017 13:28:56 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c4sm11270625pgn.93.2017.12.04.13.28.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Dec 2017 13:28:55 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C2CCB62B-172A-475F-B36C-9E9201D3117A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt Date: Mon, 4 Dec 2017 13:28:54 -0800 In-Reply-To: <1cf221bc-e2e3-bc04-6559-d01eff2e1232@gmail.com> Cc: Bob Hinden , IPv6 List To: Brian Carpenter References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> <1cf221bc-e2e3-bc04-6559-d01eff2e1232@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: Mon, 04 Dec 2017 21:28:59 -0000 --Apple-Mail=_C2CCB62B-172A-475F-B36C-9E9201D3117A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 2, 2017, at 2:15 PM, Brian E Carpenter = wrote: >=20 > On 03/12/2017 08:53, Robert Raszuk wrote: >>>=20 >>> Right, the idea is that at each node the input flow label and dst = map >>> to an output flow label. All the flow label tables are constructed = to >>> provide give loop free forwarding and multipath selection. >>=20 >>=20 >> =E2=80=8BThat's essentially SR-MPLS :) =E2=80=8B >=20 > If you look at the early history of the flow label, which predated = MPLS, > this isn't a big surprise. (IPng-ologists also remember CATNIP, > https://tools.ietf.org/html/rfc1707.) >=20 >>=20 >> SRH would be unneeded in this solution. >>=20 >>=20 >> =E2=80=8BTrue - but I was just counting in general node's forwarding = capabilites=E2=80=8B. >>=20 >> =E2=80=8BI think the less moving parts we standardize the better :) >=20 > It's true, but the flow label is already in every packet, albeit > with different semantics. >=20 I will add that swapping flow labels as I think Tom Herbert was = proposing has much less side effects than inserting and processing = extension headers. Bob --Apple-Mail=_C2CCB62B-172A-475F-B36C-9E9201D3117A 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 iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlolvhYACgkQrut0EXfn u6h+lAf/U4l+46PMOL6aOKy5axgN6POQ7vkVbEnIV73+Zi4PPum8LibOuj67Bemu PiHNUtc53P33ZlYKbn22WXvu6ABMHZL3FVQPIqrSF/ux5YulatApWf3oPN7Q/Y2L jpOkYRsY8ru8JG1o2c2VPztEPC9tGjfSAQHggArZb4YGFUS9Ukwe4bntjayp1ejS UNtMVtpO8D3dBVBi8hUSot5+gRNNE2383PK4wtp9dcylovBXzgC/h9OTKiNtxtbu l/eXY4PvETvsaJNttZ7xkQZ8gn2Mynl/QqnGCGS1NUMpQBsd9a799g1IcktWgW96 QNbuvRY4zOaM5U9LUFrFrW10Simuqw== =b1K4 -----END PGP SIGNATURE----- --Apple-Mail=_C2CCB62B-172A-475F-B36C-9E9201D3117A-- From nobody Tue Dec 5 06:59: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 BDB011294E7; Tue, 5 Dec 2017 06:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, 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 Ob0UJdCthbpC; Tue, 5 Dec 2017 06:59:14 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC0D127599; Tue, 5 Dec 2017 06:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10014; q=dns/txt; s=iport; t=1512485954; x=1513695554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KKAvFru8TmRG7PjssrlqOL58KdGzkulJBgiXwAy9V2o=; b=U7izsS2gtxhJ0QY7DK4L0HlrYlY+xCUdllvkgOQ5nQdU5lRCvYiSRB8g EuEGCxNWN+wkciFakv452YqSD8nQ5a2L9nrg9XHEtUI0w+TeDc2rojyL6 dzSFhlIc1wyjUZtiPRmL4XAXsLdGVMYccHMS1iqBmyQNTczdD9c74cQBz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgDgsyZa/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9Zjk1JweDeYogjnqBfYFahxqODoIVChgNhRYCGoUsPxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUjAQEBAwEBIRE6CxACAQgYAgImAgICHwYLFRACBAENBQkLiXcDF?= =?us-ascii?q?RCobYInhzkNgxgBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQ+COYIKgVaBaSmDAoJ?= =?us-ascii?q?rOQ8YgVYXgn4xgjIFojk9Aod0iCOEeoIWY4UuizGKPoJDPT+IJwIRGQGBOQEfO?= =?us-ascii?q?YFNbxUWJCoBgX4JgkkcgWd4AQGJE4EUAQEB?= X-IronPort-AV: E=Sophos;i="5.45,364,1508803200"; d="scan'208";a="318304155" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 14:58:56 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vB5Ewu4E011378 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Dec 2017 14:58:56 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Dec 2017 08:58:55 -0600 Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1320.000; Tue, 5 Dec 2017 08:58:55 -0600 From: "Darren Dukes (ddukes)" To: Brian E Carpenter , "draft-voyer-6man-extension-header-insertion@ietf.org" CC: 6man Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt Thread-Topic: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt Thread-Index: AQHTZ894JnM3BSQwJEyx3S1oM1NaEaM1R/MA Date: Tue, 5 Dec 2017 14:58:55 +0000 Message-ID: <69A89FE5-2D6E-4CD1-9DEB-ECE3346296AC@cisco.com> References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> In-Reply-To: <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.64.35] 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: Tue, 05 Dec 2017 14:59:17 -0000 QnJpYW4sIHRoYW5rcyBmb3Igc3RhcnRpbmcgdGhlIHRocmVhZC4gIFRoZXJlIGhhcyBiZWVuIGEg bG90IG9mIGNvbnZlcnNhdGlvbiBvbiB0aGlzIHRvcGljIG5vdyBmb3IgcXVpdGUgc29tZSB0aW1l LCBhbmQgbW9zdCByZWNlbnRseSBvbiB0aGlzIHRocmVhZCwgd2l0aCBzb21lIGdvb2QgZXhwbGFu YXRpb25z4oCmIEkgc2VlIHRoZSBmb2xsb3dpbmc6DQogDQoxIOKAkyBSRkM4MjAwIGhhcyBzb21l IG5vbi1ub3JtYXRpdmUgdGV4dCBzdGF0aW5nIG5vbi1zb3VyY2Ugbm9kZXMgZG8gbm90IGluc2Vy dCBleHRlbnNpb24gaGVhZGVycy4gTmVpdGhlciBSRkMyNDYwIG5vciBSRkM4MjAwIGRpc2FsbG93 IGFuIGludGVybWVkaWF0ZSBub2RlIGZyb20gaW5zZXJ0aW5nIFNSSC4NCiAgICAtIFJGQzI0NjAg c2VjdGlvbiA0IGRpZCBub3QgZXhjbHVkZSBpbnNlcnRpb24gb2YgU1JI4oCZcw0KICAgIC0gRXJy YXRhIElEOiA0NjU3IHN1Z2dlc3RlZCBzb21lIHRleHQgZnJvbSBGZXJuYW5kbyBkaXNhbGxvd2lu ZyBpbnNlcnRpb24sIGhvd2V2ZXIgdGhlIGRpc3Bvc2l0aW9uIG9mIHRoYXQgRXJyYXRhIHdhcyDi gJxIZWxkIGZvciBEb2N1bWVudCBVcGRhdGXigJ0NCiAgICAtIFJGQzgyMDAgY2xvc2VkIEVycmF0 YSA0NjU3IGFuZCB0aGVyZSBpcyBubyBub3JtYXRpdmUgc3RhdGVtZW50IGRpc2FsbG93aW5nIGV4 dGVuc2lvbiBoZWFkZXIgaW5zZXJ0aW9uLCByYXRoZXIgdGhlIHN1Z2dlc3Rpb24uDQoyIOKAkyBP dGhlcnMsIGluY2x1ZGluZyB5b3Vyc2VsZiwgaGF2ZSBwcm92aWRlZCBzb21lIGNvbnN0cnVjdGl2 ZSBzdWdnZXN0aW9ucy9jb21tZW50cyB0aGF0IGNhbiBiZSBleHBhbmRlZCB1cG9uIGluIHVwY29t aW5nIHJldmlzaW9ucy4gIFdl4oCZbGwgd29yayB0b3dhcmQgdGhhdC4NCg0KVGhhbmtzDQogIERh cnJlbg0KDQpPbiAyMDE3LTExLTI3LCA1OjMxIFBNLCAiQnJpYW4gRSBDYXJwZW50ZXIiIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KDQogICAgSGksDQogICAgDQogICAgSSdt IHByb2JhYmx5IHJlcGVhdGluZyBteXNlbGYsIGJ1dCBpdCBzZWVtcyBjbGVhciB0aGF0IHRoaXMg ZHJhZnQNCiAgICBpbiBpdHMgcHJlc2VudCBmb3JtIHdpbGwgbmV2ZXIgZ2V0IGFueXdoZXJlLiBG aXJzdGx5IEkgd2lsbCB0cnkgdG8NCiAgICBqdXN0aWZ5IHRoaXMgc3RhdGVtZW50LCBhbmQgc2Vj b25kbHkgSSdsbCB0cnkgdG8gbWFrZSBzb21lDQogICAgY29uc3RydWN0aXZlIHN1Z2dlc3Rpb25z Lg0KICAgIA0KICAgIEkuIFRoZSBwcm9ibGVtcyB3aXRoIHRoZSBjdXJyZW50IGRyYWZ0Og0KICAg IA0KICAgIEkuMS4gTm8gUkZDIGlzIGFsbG93ZWQgdG8gaGF2ZSBtb3JlIHRoYW4gZml2ZSBhdXRo b3JzIHdpdGhvdXQNCiAgICBhbiBleHRyZW1lbHkgZ29vZCByZWFzb24uIElmIHNpeCBvciBzZXZl biBwZW9wbGUgaGF2ZSBjb250cmlidXRlZCANCiAgICByb3VnaGx5IGVxdWFsIGFtb3VudHMgeW91 IG1pZ2h0IGp1c3QgYmUgYWJsZSB0byBwZXJzdWFkZSB0aGUNCiAgICBSRkMgRWRpdG9yIHRvIGxp c3QgZXZlcnlib2R5LCBidXQgMTg/IE5ldmVyLg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3MzIyI3NlY3Rpb24tNC4xLjENCiAgICANCiAgICBJLjIuIE1vcmUgc2VyaW91cyBp cyB0aGUgdG9uZSwgd2hpY2ggc3RhcnRzIHdpdGggdGhlIEFic3RyYWN0Lg0KICAgICJUaGUgbmV0 d29yayBvcGVyYXRvciBhbmQgdmVuZG9yIGNvbW11bml0eSBoYXMgY2xlYXJseSBpbmRpY2F0ZWQu Li4iDQogICAgaXMsIHRvIHB1dCBpdCBtaWxkbHksIG91dCBvZiBwbGFjZSBpbiBhbiBJRVRGIGRv Y3VtZW50LiBXZSB3b3JrDQogICAgYnkgZmFjdHMgYW5kIHJvdWdoIGNvbnNlbnN1cywgbm90IGJ5 IGRlY2xhcmF0aW9ucyBieSB2ZXN0ZWQNCiAgICBpbnRlcmVzdHMuIEkgdGhpbmsgYSBsb3Qgb2Yg cGVvcGxlIHdpbGwgc2ltcGx5IHN0b3AgcmVhZGluZw0KICAgIHRoZSBkcmFmdCBhZnRlciB0aGF0 IHNlbnRlbmNlLg0KICAgIA0KICAgIFRoZSB0b25lIG5lZWRzIHRvIGJlIHJhdGlvbmFsIGFuZCBm YWN0dWFsIGFyZ3VtZW50IGFib3V0IHdoeQ0KICAgIHRoZSBwcm9wb3NlZCBtZWNoYW5pc20gaXMg Ym90aCBkZXNpcmFibGUgYW5kIGhhcm1sZXNzLiBUaGUNCiAgICBhYnN0cmFjdCBuZWVkcyB0byBi ZSBhIGZhY3R1YWwgc3VtbWFyeS4NCiAgICANCiAgICBJLjMuIEEgZGV0YWlsIGlzIHRoYXQgc2lu Y2UgdGhpcyBkcmFmdCByZWNvbW1lbmRzIGlnbm9yaW5nDQogICAgYSBydWxlIGluIFJGQyA4MjAw LCBpdCBuZWVkcyB0byBiZSBhaW1lZCBhdCB0aGUgc3RhbmRhcmRzDQogICAgdHJhY2sgd2l0aCBV cGRhdGVzOiA4MjAwLg0KICAgIA0KICAgIEkuNC4gQW5vdGhlciBkZXRhaWwgaXMgdGhhdCBpbiBz b21lIHBsYWNlcyB0aGUgZHJhZnQgc2VlbXMNCiAgICB0byBhc3N1bWUgdGhhdCBvbmx5IHNlZ21l bnQgcm91dGluZyBoZWFkZXJzIHdpbGwgYmUNCiAgICBjYW5kaWRhdGVzIGZvciBpbnNlcnRpb24u IFRoYXQgbWF5IGJlIHRydWUgdG9kYXksIGJ1dA0KICAgIHByb2JhYmx5IG5vdCBmb3IgZXZlci4N CiAgICANCiAgICBJSS4gQ29uc3RydWN0aXZlIHN1Z2dlc3Rpb25zLg0KICAgIA0KICAgIEkgdW5k ZXJzdGFuZCB0aGF0IHRoZSBpZGVhIGlzIHRvIHByb3Bvc2UgdGhhdCB0aGlzIHJ1bGUNCiAgICBp biBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODIwMCNzZWN0aW9uLTQgOg0KICAgIA0K ICAgICIgIEV4dGVuc2lvbiBoZWFkZXJzIChleGNlcHQgZm9yIHRoZSBIb3AtYnktSG9wIE9wdGlv bnMgaGVhZGVyKSBhcmUgbm90DQogICAgICAgcHJvY2Vzc2VkLCBpbnNlcnRlZCwgb3IgZGVsZXRl ZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5DQogICAgICAgcGF0aCwgdW50 aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9k ZXMsDQogICAgICAgaW4gdGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBpZGVudGlmaWVkIGluIHRoZSBE ZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkDQogICAgICAgb2YgdGhlIElQdjYgaGVhZGVyLiINCiAg ICANCiAgICBNQVkgYmUgaWdub3JlZCB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgZG9tYWluIGZv ciBwYWNrZXRzIHRoYXQNCiAgICB0ZXJtaW5hdGUgd2l0aGluIHRoYXQgZG9tYWluLiBJZiB0aGF0 J3MgdGhlIGludGVudGlvbiwgSSB0aGluaw0KICAgIHRoZXJlIGFyZSBzZXZlcmFsIGxvZ2ljYWwg c3RlcHMgaW4gdGhlIGFyZ3VtZW50IHRoYXQgbmVlZCB0bw0KICAgIGJlIGxhaWQgb3V0LiBBIGxv dCBvZiB0aGUgaWRlYXMgYXJlIGFscmVhZHkgaW4gdGhlIGRyYWZ0OyB0aGlzDQogICAgaXMgbWFp bmx5IGFib3V0IG1ha2luZyBhIGNsZWFyIGFuZCBsb2dpY2FsIGNhc2UgdGhhdCB0aGUgd2hvbGUN CiAgICBjb21tdW5pdHkgY2FuIHVuZGVyc3RhbmQuDQogICAgDQogICAgMS4gSW50cm9kdWN0aW9u LCBvdXRsaW5lIG9mIHVzZSBjYXNlcyBbMV0uDQogICAgMi4gUHJlY2lzZSBkZWZpbml0aW9uIG9m IGEgZG9tYWluIGFuZCBvZiBpdHMgYm91bmRhcnksIGluZ3Jlc3NlcyBhbmQgZWdyZXNzZXMuDQog ICAgMy4gRXhwbGFuYXRpb24gb2YgaG93IHRoZSBjbGFzcyBvZiBwYWNrZXRzIGVsaWdpYmxlIGZv ciBoZWFkZXIgaW5zZXJ0aW9uIGFyZSBpZGVudGlmaWVkIFsyXS4NCiAgICA0LiBFeHBsYW5hdGlv biBvZiBob3cgdGhlIHdlbGwta25vd24gaXNzdWVzIGFyZSBhdm9pZGVkIChQTVRVRCwgZnJhZ21l bnRhdGlvbiwgSVBTZWMpLg0KICAgIDUuIENsZWFyIHN0YXRlbWVudCBvZiB3aGF0IGhlYWRlciBt YW5pcHVsYXRpb25zIGFyZSBhbGxvd2VkIGFuZCB3aGljaCBkZXZpY2VzIG1heSBwZXJmb3JtIHRo ZW0uDQogICAgNi4gUHJlY2lzZSBzdGF0ZW1lbnQgb2Ygd2hpY2ggdGV4dCBpbiBSRkMgODIwMCBp cyB1cGRhdGVkLg0KICAgIDcuIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIA0KICAgIA0KICAgIFsx XSBNb3JlIGRldGFpbHMgb24gdXNlIGNhc2VzIGNvdWxkIGJlIGFuIGFwcGVuZGl4LiANCiAgICAN CiAgICBbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZveWVyLTZtYW4tZXh0 ZW5zaW9uLWhlYWRlci1pbnNlcnRpb24tMDIjc2VjdGlvbi0zIA0KICAgIGlzIElNSE8gY29ycmVj dCBhcyBmYXIgYXMgdHJhbnNpdCBwYWNrZXRzIGdvLiBCdXQgaXQNCiAgICBzaG91bGQgYmUgcHJl c2VudGVkIGFzIGEgbWFpbnN0cmVhbSBwYXJ0IG9mIHRoZSBwcm9wb3NhbCwNCiAgICBub3QgYXMg YW4gZXhhbXBsZS4NCiAgICANCiAgICBJIGhvcGUgdGhpcyBpcyBoZWxwZnVsLg0KICAgICAgIEJy aWFuIENhcnBlbnRlcg0KICAgIA0KICAgIA0KICAgIA0KICAgIE9uIDIxLzExLzIwMTcgMDc6MzMs IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCiAgICA+IA0KICAgID4gQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzLg0KICAgID4gDQogICAgPiANCiAgICA+ICAgICAgICAgVGl0bGUgICAgICAg ICAgIDogSW5zZXJ0aW9uIG9mIElQdjYgU2VnbWVudCBSb3V0aW5nIEhlYWRlcnMgaW4gYSBDb250 cm9sbGVkIERvbWFpbg0KICAgID4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBEYW5pZWwgVm95 ZXINCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgRGFuaWVsIEJlcm5pZXINCiAgICA+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgSm9obiBMZWRkeQ0KICAgID4gICAgICAgICAgICAg ICAgICAgICAgICAgICBDbGFyZW5jZSBGaWxzZmlscw0KICAgID4gICAgICAgICAgICAgICAgICAg ICAgICAgICBEYXJyZW4gRHVrZXMNCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3Rl ZmFubyBQcmV2aWRpDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0ZWZhbm8gU2Fs c2Fubw0KICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICBBbnRvbmlvIENpYW5mcmFuaQ0K ICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICBEYXZpZCBMZWJydW4NCiAgICA+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgT2xpdmllciBCb25hdmVudHVyZQ0KICAgID4gICAgICAgICAg ICAgICAgICAgICAgICAgICBQcmVtIEpvbm5hbGFnYWRkYQ0KICAgID4gICAgICAgICAgICAgICAg ICAgICAgICAgICBNaWxhZCBTaGFyaWYNCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAg SGFuaSBFbG1hbGt5DQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEFobWVkIEFiZGVs c2FsYW0NCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9iZXJ0IFJhc3p1aw0KICAg ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBBcnRoaSBBeXlhbmdhcg0KICAgID4gICAgICAg ICAgICAgICAgICAgICAgICAgICBEaXJrIFN0ZWluYmVyZw0KICAgID4gCUZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LXZveWVyLTZtYW4tZXh0ZW5zaW9uLWhlYWRlci1pbnNlcnRpb24tMDIudHh0DQog ICAgPiAJUGFnZXMgICAgICAgICAgIDogMTQNCiAgICA+IAlEYXRlICAgICAgICAgICAgOiAyMDE3 LTExLTIwDQogICAgPiANCiAgICA+IEFic3RyYWN0Og0KICAgID4gICAgVGhlIG5ldHdvcmsgb3Bl cmF0b3IgYW5kIHZlbmRvciBjb21tdW5pdHkgaGFzIGNsZWFybHkgaW5kaWNhdGVkIHRoYXQNCiAg ICA+ICAgIElQdjYgaGVhZGVyIGluc2VydGlvbiBpcyB1c2VmdWwgYW5kIHJlcXVpcmVkLiAgVGhp cyBpcyBub3RhYmx5IHRoZQ0KICAgID4gICAgY2FzZSB3aGVuIHRoZSBlbnRpcmUgam91cm5leSBv ZiB0aGUgcGFja2V0IHJlbWFpbnMgaW4gaXRzIHNvdXJjZQ0KICAgID4gICAgZG9tYWluLiAgSW4g c3VjaCBhIGNvbnRleHQsIGl0IGRvZXMgbm90IG1hdHRlciB3aGVyZSB0aGUgZXh0ZW5zaW9uDQog ICAgPiAgICBoZWFkZXIgaXMgaW5zZXJ0ZWQuICBUaGUgc291cmNlIGRvbWFpbiBtYXkgZGVjaWRl IHRvIHBsYWNlIHRoZSBJUHY2DQogICAgPiAgICBleHRlbnNpb24gaGVhZGVyIGluc2VydGlvbiB3 aGVyZSBpdCBzdWl0cyBpdHMgYmVzdDogYXQgdGhlIHNvdXJjZSBvZg0KICAgID4gICAgdGhlIHBh Y2tldCBvciBhdCBhbnkgbWlkcG9pbnQgd2l0aGluIHRoZSBzb3VyY2UgZG9tYWluLg0KICAgID4g DQogICAgPiANCiAgICA+IA0KICAgID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQogICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC12b3llci02bWFuLWV4dGVuc2lvbi1oZWFkZXItaW5zZXJ0aW9uLw0KICAgID4gDQog ICAgPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQogICAg PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24t aGVhZGVyLWluc2VydGlvbi0wMg0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC12b3llci02bWFuLWV4dGVuc2lvbi1oZWFkZXItaW5zZXJ0aW9uLTAyDQog ICAgPiANCiAgICA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDoNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC12b3ll ci02bWFuLWV4dGVuc2lvbi1oZWFkZXItaW5zZXJ0aW9uLTAyDQogICAgPiANCiAgICA+IA0KICAg ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+IA0KICAgID4g SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K ICAgID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICA+IA0KICAgID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IEkt RC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCiAgICA+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KICAg ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCiAg ICA+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRv dy5odG1sDQogICAgPiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4 dA0KICAgID4gDQogICAgDQoNCg== From nobody Tue Dec 5 08:17: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 50D98127863; Tue, 5 Dec 2017 08:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vK6y7tMNIhjW; Tue, 5 Dec 2017 08:16:58 -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 D4AD6127735; Tue, 5 Dec 2017 08:16:57 -0800 (PST) Received: from [192.168.3.67] (109-155-16-190.fibertel.com.ar [190.16.155.109]) (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 14F8C804A4; Tue, 5 Dec 2017 17:16:50 +0100 (CET) Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: "Darren Dukes (ddukes)" , Brian E Carpenter , "draft-voyer-6man-extension-header-insertion@ietf.org" Cc: 6man References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <69A89FE5-2D6E-4CD1-9DEB-ECE3346296AC@cisco.com> From: Fernando Gont Message-ID: Date: Tue, 5 Dec 2017 13:16:22 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <69A89FE5-2D6E-4CD1-9DEB-ECE3346296AC@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 05 Dec 2017 16:17:00 -0000 On 12/05/2017 11:58 AM, Darren Dukes (ddukes) wrote: > Brian, thanks for starting the thread. There has been a lot of conversation on this topic now for quite some time, and most recently on this thread, with some good explanations… I see the following: > > 1 – RFC8200 has some non-normative text stating non-source nodes do not insert extension headers. Neither RFC2460 nor RFC8200 disallow an intermediate node from inserting SRH. > - RFC2460 section 4 did not exclude insertion of SRH’s > - Errata ID: 4657 suggested some text from Fernando disallowing insertion, however the disposition of that Errata was “Held for Document Update” > - RFC8200 closed Errata 4657 and there is no normative statement disallowing extension header insertion, rather the suggestion. Have you followed the publication process of RFC8200? :-) EH insertion is forbiden by RFC8200 as much as it could possibly be. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Dec 5 08:19:38 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 73F3E127698; Tue, 5 Dec 2017 08:19:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Protocol Action: 'Support for adjustable maximum router lifetimes per-link' to Proposed Standard (draft-ietf-6man-maxra-04.txt) X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ipv6@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-maxra@ietf.org, rfc-editor@rfc-editor.org, otroan@employees.org, terry.manderson@icann.org, 6man-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151249077646.23058.4339460707711541172.idtracker@ietfa.amsl.com> Date: Tue, 05 Dec 2017 08:19:36 -0800 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: Tue, 05 Dec 2017 16:19:36 -0000 The IESG has approved the following document: - 'Support for adjustable maximum router lifetimes per-link' (draft-ietf-6man-maxra-04.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ Technical Summary 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. Working Group Summary There is support for this document in the 6MAN working group. Several issues were raised during the w.g. last call. These issues are resolved in the current draft. There is a concensus to advance this document. Document Quality The quality of the document is good, it has received adequate review in the working group on the mailing list and at several 6man sessions at IETF meetings. Personnel Document Shepherd: Bob Hinden Responsible AD: Terry Manderson RFC Editor Note Please make the following change to the abstract OLD: This document allows for overriding these values on a per-link basis. NEW: This document allows for overriding these values on a per-link basis. This document specifies updates to the RFC4861 IPv6 Neighbor Discovery Protocol for increasing the the maximum time allowed between sending unsolicited multicast Router Advertisements (RA) from a router interface as well as for the maximum router lifetime. From nobody Tue Dec 5 11:26: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 D7C2D126C2F; Tue, 5 Dec 2017 11:26:49 -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 Qyl7URVsxAaG; Tue, 5 Dec 2017 11:26:48 -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 08FFC126DCA; Tue, 5 Dec 2017 11:26:48 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id m25so833076pgv.12; Tue, 05 Dec 2017 11:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UkHZ/X4Dr+U+gkPJUwudxyfLHkdeNExYPDDbd1lehYY=; b=NU+mVVZbBe9yZSpA50E0FYcyZBbAD8S1BJB522mKNZaeaFX17F1uYWtKbjjEQ8Y1oX gWCbeep3opZ0b2de/Wg2P87Yq2yHuLCdFOE08PJBEtIRpgj0LlTUii9y2nxmJNOAbYzo 5PRQtY1jvqFaaWn1dJD1LYwG8RB3ce7232rh27oxtEuprm/RD6wsf8nvagI8V9D4UARh k3L0PfZR2421OfwJNZoS0K/LX/tPkqxpTfe+ih1YkMGyueCNCO2dZfiFyL7XB0MuyYes TSv6p+ECR9bBkhvuw/CV2nEe7/vjbd5DrAfxAAZLTjfLfloAkcDDli63fUEaYHohqgsN c+7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UkHZ/X4Dr+U+gkPJUwudxyfLHkdeNExYPDDbd1lehYY=; b=FSnYbZw5F9FwAFrMBkmwaeb00PCclfgLRDHYtCupP/GucTdGu9+LkA9u9K5ygP0ECM PJ7P/GT1Qc2Gr2u6BbqhWnlS2WYkgq4AESVPlJenUbTW7cOVo4hBCdrBDu2ixSqL70Ku OAAGWs33o0eUXatdtWFLlNn8N8Jbdp3yJRMMFZG8++Rkyj0LHxQy03FhEW8wbbF6p15E t9Se4FPnpjv5vilAlI+75vKshmYr5fc19AbOsPTZe9r7JXIvVJ4YrE/noJUY4A3f4UDG jIkZS3EsHK4DQQp39H7o1aRjTsKVHGmKyr7TujfVQccD3RHVlGANrp5fBDd3x7R3S6T6 Ja1Q== X-Gm-Message-State: AJaThX7lTi5UGgZlHKFb+KgvRqBbj8D+Q4xMWcGeUYIhBddXZt8XMSFy GwulrogOmB/em3UPoS9x7uSVTw== X-Google-Smtp-Source: AGs4zMbyzIJchNg9cmsDBdieF087DDFHhenuCCc3C3JYzDGSg9PBozgQRJcUzxOzQYtoybA0J3hdlg== X-Received: by 10.101.101.215 with SMTP id y23mr18610645pgv.391.1512502007336; Tue, 05 Dec 2017 11:26:47 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o70sm1251023pfk.79.2017.12.05.11.26.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 11:26:46 -0800 (PST) Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Fernando Gont , "Darren Dukes (ddukes)" , "draft-voyer-6man-extension-header-insertion@ietf.org" Cc: 6man References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <69A89FE5-2D6E-4CD1-9DEB-ECE3346296AC@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 6 Dec 2017 08:26:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: Tue, 05 Dec 2017 19:26:50 -0000 On 06/12/2017 05:16, Fernando Gont wrote: > On 12/05/2017 11:58 AM, Darren Dukes (ddukes) wrote: >> Brian, thanks for starting the thread. There has been a lot of conver= sation on this topic now for quite some time, and most recently on this t= hread, with some good explanations=E2=80=A6 I see the following: >> =20 >> 1 =E2=80=93 RFC8200 has some non-normative text stating non-source nod= es do not insert extension headers. Neither RFC2460 nor RFC8200 disallow = an intermediate node from inserting SRH. >> - RFC2460 section 4 did not exclude insertion of SRH=E2=80=99s >> - Errata ID: 4657 suggested some text from Fernando disallowing in= sertion, however the disposition of that Errata was =E2=80=9CHeld for Doc= ument Update=E2=80=9D >> - RFC8200 closed Errata 4657 and there is no normative statement d= isallowing extension header insertion, rather the suggestion. >=20 > Have you followed the publication process of RFC8200? :-) >=20 > EH insertion is forbiden by RFC8200 as much as it could possibly be. To be extra clear: RFC8200 does not use the capitalization of normative keywords as defined in RFC2119. It is written in plain English. The text "Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node..." is just as normative as every other part of this Internet Standard. That's why any standards-track version of draft-voyer- would need to formally update RFC8200. Brian From nobody Tue Dec 5 11:59: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 E8A43127B5A for ; Tue, 5 Dec 2017 11:59:50 -0800 (PST) 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 WBG6jfeTgN4O for ; Tue, 5 Dec 2017 11:59:49 -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 BE9E8127B31 for ; Tue, 5 Dec 2017 11:59:48 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id p33so1155560uag.9 for ; Tue, 05 Dec 2017 11:59:48 -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=EOM2tKvb9gt/A+cPRq5saUHpfCF5dt8qbEbSftr9D34=; b=px4ofLgHESRfLQTgyDq4vrUD7NJ0nW9zpKwjSpPDA1Y+GDaE51PFovhgfqRJGduyHv Sd0Rp1UMlqTDNcu3w7/vfaVuG4EyqaAhptXT0eDXcd2eKAh0Hk2phkYDDSq4nUHXrOT5 CeBasfhgDkc/hXFmiTCkW9e6kOnjtGPjUYYxxs/TRogtvrVDOtEL0PgDzaIGmfqXUMqr 1vtAscGO1ziiJUuOcmigffggLlpO/DNKqtP+TtVbfMV1zXO8KiT5NqFX3xMyV6E+UXGy 2LBdrwnEF4peWzgIab7UkLmBb2aIwc1W6AupO/b8bhjZa16JrvwiTVImFP0QlS4/wWCO oN5w== 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=EOM2tKvb9gt/A+cPRq5saUHpfCF5dt8qbEbSftr9D34=; b=kSWhgxjT+ZHodktT2Ixa7wwTmh3Vk3hGU/PwBwRMD6PVAXueo3NktxTMaz8ln5LyNm 70UF8Blhjw6ZpdjtGWwNoq9CxnDWJ/NGrgD09s9bNDr5vT1cYv40TYYluTaJw1g0ES3g Td1rCldksFV1GGoK/B/KGKiAxLJ7x7bJS46NwIXRqKlkkO+X8kuXxbrfWBbHNq/mM/M/ s+/gewsqCjxwesMKTNz8ykaoqDTf15IFSwfte4f5rXlO45BckR8bDxXBEAvRTaFB3S/1 IDAq1H6Exgq/9mOQlBUBOHlFVqelD7Cle/dLItxgkMELoBjOvCb++WTQdwbKeX2mNFK9 hgmA== X-Gm-Message-State: AKGB3mKCwGDGgn7BUhrKN1pXaUpuBidicUwfQpZ3Zo6baXCPs7pgvRGX fRUqDMKr8CeImGkCGhQ7be45qDbPxjDXtqaYtE4= X-Google-Smtp-Source: AGs4zMZJjoM7jXl+lHV3RQ46nUwE8RazOR7uycfdTbWXUiW4zsW34pDsbzzNucMvoWbQ3KkvNQDvHrP1O1LA+/DDGr8= X-Received: by 10.176.11.5 with SMTP id b5mr6312047uak.118.1512503987584; Tue, 05 Dec 2017 11:59:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.56.218 with HTTP; Tue, 5 Dec 2017 11:59:17 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> <1cf221bc-e2e3-bc04-6559-d01eff2e1232@gmail.com> From: Mark Smith Date: Wed, 6 Dec 2017 06:59:17 +1100 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Bob Hinden Cc: Brian Carpenter , 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: Tue, 05 Dec 2017 19:59:51 -0000 On 5 December 2017 at 08:28, Bob Hinden wrote: > >> On Dec 2, 2017, at 2:15 PM, Brian E Carpenter wrote: >> >> On 03/12/2017 08:53, Robert Raszuk wrote: >>>> >>>> Right, the idea is that at each node the input flow label and dst map >>>> to an output flow label. All the flow label tables are constructed to >>>> provide give loop free forwarding and multipath selection. >>> >>> >>> That's essentially SR-MPLS :) >> >> If you look at the early history of the flow label, which predated MPLS, >> this isn't a big surprise. (IPng-ologists also remember CATNIP, >> https://tools.ietf.org/html/rfc1707.) >> >>> >>> SRH would be unneeded in this solution. >>> >>> >>> True - but I was just counting in general node's forwarding capabilites. >>> >>> I think the less moving parts we standardize the better :) >> >> It's true, but the flow label is already in every packet, albeit >> with different semantics. >> > > I will add that swapping flow labels as I think Tom Herbert was proposing has much less side effects than inserting and processing extension headers. Which would then violate the Flow Label spec unless the Flow Label value is zero. I think the less fiddling with packets in flight the better. Change creates opportunities for failure, so the less change the better. Encapsulation/decapsulation is much less change than EH insertion or modification (and restoration if the original value was non-zero) of the flow label. Change in the network, if necessary, should be minimised. The IPv6 SRH EH is obese because of the use of full 128 IPv6 addresses as segment identifiers. It is not a requirement to use 128 bit values as segment identifiers as in SR-MPLS they are only 20 bits i.e. the MPLS label size. Fix the SRH obesity problem and then there is no need to make a very fundamental change to IPv6 EH processing, and no need force customers to forklift upgrade their existing IPv6 networks to adopt SR (tunnelled SR is an incremental upgrade, as SR implementations can be plugged in on the side of existing IPv6 forwarding devices, similar to the way Ipsilon added IP routing capabilities to ATM switches.) The network wide forklift upgrade required to adopt this SR via EH insertion will impact its rate of adoption. The cost of the solution needs to be significantly cheaper than the cost of continuing to deal with the problem to encourage adoption. Incremental upgrades rather than forklift upgrades are cheaper in both capex and opex. Regards, Mark. From nobody Tue Dec 5 12:24: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 67F9F126DFF for ; Tue, 5 Dec 2017 12:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 fX2GZkYHa8Cu for ; Tue, 5 Dec 2017 12:24:42 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 07B3312025C for ; Tue, 5 Dec 2017 12:24:42 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id g9so3854037qth.9 for ; Tue, 05 Dec 2017 12:24:41 -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; bh=L+3mNoFCRZEGO7zUEbtFv5z+JF1tMu6ioRgCqFHmFuA=; b=LeDG87QJB49vjK4BpN0PS3yEEuOah+ihng1LV5BdZeJB8POlKqBxopOEFuZ+aWxOzC HAKqFX0XgIW0roVE7vdCQkG46QV8p23vWUaUH1wY1Tk8CXcaP7CaPQb7x0O6ULbvi3et qke4DI1Eq2IgrYKLY1si7rMwbEm+NdthVVYNDaEu0vOEZ4e3lg+3byq9wEK/mImF+bm3 YRlaiBwOUQiiCImk4pKfzxsPhJiTNBrRcTbAlv7mOJgJYHk5Msy5p3Ih+udpkZPHV3WT nxodyOPtVm4sqBJssm8jhkdqsfkAqgd2lokC2GWLq7aW8+HrBq4a1VPL7f4qVqzGfVaH eOjQ== 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=L+3mNoFCRZEGO7zUEbtFv5z+JF1tMu6ioRgCqFHmFuA=; b=KsKza9f+eWbYLltfRnCC9jmxFCZC/jo82NBQ8Fq0k28JR+rdhowvrY++sYWu7qjmno AmnVV9WDekXrSLmGyGtMViey+fd2c4Jph8d9eGu4HtTRLp0alcUG9EnLmvRVRxwfIXvo 0lC4EuAaivrAdp75pmQKe2BEdbFoaWMLEOiYGKcHGkseZBO8Hzp5+1JbelNrQz+RhldY GAnEmlncbAGBsSsDDmDtzkk/EfdSIeu3m5WtCQ9/ka8Iqzg8CAn4XpOmqGev7Vwd1ng4 jrg4Md0Pe2lTT6dUOJuGhTiZB3KdokaAx3caAmkNtsDFTHpShc8RzNJ+FI3sGrqalyIR L/9Q== X-Gm-Message-State: AKGB3mLBy8QPruDDcnA0Ti7eIV7cy3DGhWN7x1WXvEstfTzdoX7v0Zo3 9A1+k2/z3FpmDxbCmxbKFbCYPaVfc+pJC9TwNzgghg== X-Google-Smtp-Source: AGs4zMYX99I7vQLbMNOCL1IKtwX/tLteTmuisK1xwp/BVQnYNGDBNGWXG/nEA4NLJN5jvsZcYJUaJ2wfrb4i/UGhK9Q= X-Received: by 10.55.23.195 with SMTP id 64mr24062934qkx.262.1512505480918; Tue, 05 Dec 2017 12:24:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.121 with HTTP; Tue, 5 Dec 2017 12:24:40 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> <1cf221bc-e2e3-bc04-6559-d01eff2e1232@gmail.com> From: Tom Herbert Date: Tue, 5 Dec 2017 12:24:40 -0800 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Mark Smith Cc: Bob Hinden , 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: Tue, 05 Dec 2017 20:24:44 -0000 On Tue, Dec 5, 2017 at 11:59 AM, Mark Smith wrote: > On 5 December 2017 at 08:28, Bob Hinden wrote: >> >>> On Dec 2, 2017, at 2:15 PM, Brian E Carpenter wrote: >>> >>> On 03/12/2017 08:53, Robert Raszuk wrote: >>>>> >>>>> Right, the idea is that at each node the input flow label and dst map >>>>> to an output flow label. All the flow label tables are constructed to >>>>> provide give loop free forwarding and multipath selection. >>>> >>>> >>>> That's essentially SR-MPLS :) >>> >>> If you look at the early history of the flow label, which predated MPLS, >>> this isn't a big surprise. (IPng-ologists also remember CATNIP, >>> https://tools.ietf.org/html/rfc1707.) >>> >>>> >>>> SRH would be unneeded in this solution. >>>> >>>> >>>> True - but I was just counting in general node's forwarding capabilites. >>>> >>>> I think the less moving parts we standardize the better :) >>> >>> It's true, but the flow label is already in every packet, albeit >>> with different semantics. >>> >> >> I will add that swapping flow labels as I think Tom Herbert was proposing has much less side effects than inserting and processing extension headers. > > Which would then violate the Flow Label spec unless the Flow Label > value is zero. > Mark, The exlcusion that the flow label might be change for "compelling operational reasons" is in practice interpreted as the flow label may change in flight (i.e. receivers and network nodes cannot assume flow label doesn't change). So while doing something like this might be against the spec as written, I have to think this is potentially much less problematic and less churn than changing RFC8200 to allow extension header insertion. Tom > I think the less fiddling with packets in flight the better. Change > creates opportunities for failure, so the less change the better. > Encapsulation/decapsulation is much less change than EH insertion or > modification (and restoration if the original value was non-zero) of > the flow label. Change in the network, if necessary, should be > minimised. > > The IPv6 SRH EH is obese because of the use of full 128 IPv6 addresses > as segment identifiers. It is not a requirement to use 128 bit values > as segment identifiers as in SR-MPLS they are only 20 bits i.e. the > MPLS label size. > > Fix the SRH obesity problem and then there is no need to make a very > fundamental change to IPv6 EH processing, and no need force customers > to forklift upgrade their existing IPv6 networks to adopt SR > (tunnelled SR is an incremental upgrade, as SR implementations can be > plugged in on the side of existing IPv6 forwarding devices, similar to > the way Ipsilon added IP routing capabilities to ATM switches.) > > The network wide forklift upgrade required to adopt this SR via EH > insertion will impact its rate of adoption. The cost of the solution > needs to be significantly cheaper than the cost of continuing to deal > with the problem to encourage adoption. Incremental upgrades rather > than forklift upgrades are cheaper in both capex and opex. > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Dec 6 04:05: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 97934126B7E for ; Wed, 6 Dec 2017 04:05:43 -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 lew03SaGywJ5 for ; Wed, 6 Dec 2017 04:05:42 -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 BE85C124D6C for ; Wed, 6 Dec 2017 04:05:41 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id 9so6752748wme.4 for ; Wed, 06 Dec 2017 04:05:41 -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=zHR8ZI2vlpTPC3+q7qb3Veilf8jf3WFou9mEM/mcpQQ=; b=ZLOtddqEUNyMZpjEsYYpgA8p8y9HoDCujlUCiiWzS24eHTFXoxwcgpUouaXIMV5g75 UWGlPODJE1cpRjjVErJ1p+SqT8Cg85miobMjZTPFGhnozAh94r7+K4ecCTXcl+6yOwyp +Lpz7XaVsvJ+AVIH2znR+TtCtc9SHa7wuyUywJpVeXd0HpwPEF894HH81M0x+VR9fbPB ds5oYB+O2qbi5v24DWqBzNhpHnyRitplE0kZ1i7AS3VyvvivVDjNuuidoHXkmvrhmpJQ Dt7yQXyxuigIWG5i3S/iTBLr4J3de0z3+MquyktiQcaF3/6O8lW7pD9xtV/Gvkep2Qn4 OcDg== 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=zHR8ZI2vlpTPC3+q7qb3Veilf8jf3WFou9mEM/mcpQQ=; b=jJKQiVV3Pyew23kJ9yqB4+/oJt9wOmUBj6mjSKT/83BKn3n6z6NJwQTW35vJq8Q/NW a9wiv1xoqhw1u23sTTWjgmTmXem5GhE6WygMY7AfwgNwGZ/VichKYi0q6uRVoK8OyiJo Y5Co3h1amX2vypSiDHS4gy8zV/03MHVE30AIHZahBC/tUkvTzjvrEN9qDQGC/dC3r+XY A4fy7OTqbtQClFeXrlbXPb5Y4GgQS1QPrsRfAJMpqjafo1jSH62ySyWcpobJkosygyDi oEw48tZ5e8Nku8P/ocfTKgv43iQsxoKsnhBg8bP6kp66QdoEU35NiiUwxp13VD7PGXJ2 aLOA== X-Gm-Message-State: AKGB3mK3uxwylz5pMKr0wQldzLRlnb1xBb/e30XXbXPuzkkKPGjWGR5u 3yMeA22UEwZDz38ngL5TidBA747/ X-Google-Smtp-Source: AGs4zMYCfevOjc+M2OC8RUkQ7ur12es2e0zmsTZpH5uBxL+juPjG2yN0sVWyj/ur0azRhw+Ex7IUOg== X-Received: by 10.28.105.14 with SMTP id e14mr7766302wmc.74.1512561939939; Wed, 06 Dec 2017 04:05:39 -0800 (PST) Received: from [10.0.0.31] ([98.207.156.188]) by smtp.gmail.com with ESMTPSA id 2sm2836812wmk.28.2017.12.06.04.05.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 04:05:38 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_24721577-500C-4878-9302-080C4AB1616D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Confirm consensus to adopt Date: Wed, 6 Dec 2017 04:05:36 -0800 In-Reply-To: <2F87B4AC-E56C-4A33-82BD-E92DFEEAF331@gmail.com> Cc: Bob Hinden To: IPv6 List References: <2F87B4AC-E56C-4A33-82BD-E92DFEEAF331@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: Wed, 06 Dec 2017 12:05:43 -0000 --Apple-Mail=_24721577-500C-4878-9302-080C4AB1616D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Not hearing any objections, there is a consensus to adopt this document = as a 6MAN document. The author should publish the next version as = draft-ietf-6man-ndpioiana. Thanks, Bob > On Nov 16, 2017, at 12:07 AM, Bob Hinden wrote: >=20 >=20 > At the 6MAN session at the Singapore IETF there was a positive hum to = adopt as a 6MAN working group document: >=20 > Title : IPv6 ND PIO Flags IANA considerations > Author : Ole Tr=C3=B8an > Filename : draft-troan-6man-ndpioiana-01.txt > Pages : 4 > Date : 2017-09-19 >=20 > https://tools.ietf.org/html/draft-troan-6man-ndpioiana-01 >=20 > The is a call to confirm this consensus. If you object to adopting = this document, please > respond to the mailing list. Editorial suggestions can be sent to the = author. >=20 > This confirmation call will end on 30 November 2017. >=20 > Regards, > Bob Hinden >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_24721577-500C-4878-9302-080C4AB1616D 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 iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlon3RAACgkQrut0EXfn u6jWFAf8DZBg+TnaIhvmbnxTiPB7JM/AbpABiLQb8KfkSJ8JE+kdY/8jUgMAOK1W yeJ3+/JkahEj8LqP177rW+2lZGQ3f6B6V1lLANGaEMBcsP1/5g5lrpKpW+PXfIlf uGSRDEipV4NHKNynJ/yGX7LcqKM+9Wkwovc4/xiRmf7TKPWZsj9lddGWfxu1o1QE tJ32AOuF+lGYoDHMfPXiegkWf/zgIdW9dzN69m3Zt8dzQsuCeS8fGIEfcVuQP1OL N02wv52N0aXQ4Vz443w2qynDZ1/UFP99IcoLnoFyzgT5nIu6O8tzzyGJYheGb9B7 MKrdE8aNyxKmYOU275FAS9DJBw520w== =6kEa -----END PGP SIGNATURE----- --Apple-Mail=_24721577-500C-4878-9302-080C4AB1616D-- From nobody Wed Dec 6 04:10:13 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 7797D128AB0; Wed, 6 Dec 2017 04:10:12 -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: The 6MAN WG has placed draft-troan-6man-ndpioiana in state "Adopted by a WG" X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151256221248.30777.984834738699665019.idtracker@ietfa.amsl.com> Date: Wed, 06 Dec 2017 04:10:12 -0800 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: Wed, 06 Dec 2017 12:10:12 -0000 The 6MAN WG has placed draft-troan-6man-ndpioiana in state Adopted by a WG (entered by Robert Hinden) The document is available at https://datatracker.ietf.org/doc/draft-troan-6man-ndpioiana/ From nobody Wed Dec 6 04:48:18 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 8B4C912762F; Wed, 6 Dec 2017 04:48:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-ndpioiana-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151256449752.30718.1147540384147926073@ietfa.amsl.com> Date: Wed, 06 Dec 2017 04:48:17 -0800 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: Wed, 06 Dec 2017 12:48:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance WG of the IETF. Title : IPv6 ND PIO Flags IANA considerations Author : Ole Trøan Filename : draft-ietf-6man-ndpioiana-00.txt Pages : 3 Date : 2017-12-06 Abstract: The Prefix Information Option in the IPv6 Neighbor Discovery Router Advertisement defines an 8-bit flag field with two flags defined and the remaining 6 bits reservered (Reserved1). RFC 6275 has defined a new flag from this field without creating a IANA registry or updating RFC 4861. The purpose of this document is to request that IANA to create a new registry for the PIO flags to avoid potential conflict in the use of these flags. This document updates RFC 4861. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ndpioiana/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-ndpioiana-00 https://datatracker.ietf.org/doc/html/draft-ietf-6man-ndpioiana-00 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 Wed Dec 6 11:53: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 3941D1270A3 for ; Wed, 6 Dec 2017 11:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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 MD3PoCSgy-1L for ; Wed, 6 Dec 2017 11:53:27 -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 1C96E124D85 for ; Wed, 6 Dec 2017 11:53:27 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id l187so3452498vke.5 for ; Wed, 06 Dec 2017 11:53: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=VbHT3Lx5GbDDLpD4VWEwCN8zlbWWQh6vznaQsPpm5X0=; b=Ov21FWHgiyfSjmTRj0d4MsG8mUdA924SOCYOyU+NJSWKoqeT1x39iv51eahAW70cu6 Di+8wMzGK4i9IKlTM7LSoIkuuHgRAa732FFWjPHqBTKwTPKKCxTJv02nQCkyMuV4u/+0 UK3LEOr+j1O91vW35+GlQVbkCscIDBnZKMcEIKO5xKfZaRsjoULyrREvtXV/CjUB3jgr jn7NOOicrPviJQ3QQGkyJ4pieDZ/PC4de6RkyQUBuoyXbwattz8jRvzQh33CHNlCaxbs QxGGvhi4OTLJ84k9oUgKwY2u5mON9z6ZYT/J5L03TNS/WQ01oocgwxY+YUjnNgotYbWM DS1A== 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=VbHT3Lx5GbDDLpD4VWEwCN8zlbWWQh6vznaQsPpm5X0=; b=cUSVmTaaM7xEtIZV8T4tLsUvdN1F5u2UuQBBF7bmHTdBV6FsOTdr2w+XeqwUWFJ1KT qRs48qm2JTNtr/t5DF2UM/wfSHEUFY4lb2idmeldwJZ5vSp7+JG7D8fjRGHQ76VXYvYD ydFg/ujtkrtEtUcbTjQlFBA7wSdz7084c3qJj3fkTrtx1lMKFmS9n05m21FtR+qlmeT3 tnVwP/pnibQPA57UNYIE6pcSZZcyuNeeYVsvFutKryvxiqXkYvZBRsPmZPr/TD5vspU8 kVPc5XUkEUPpCcscl4bnmF0DmE5H4djHiuw74XSyUv40Bh+wKAhzl6UtAtkesV6GXW64 j7ig== X-Gm-Message-State: AKGB3mKxC9ypSwa32tliUg5rXZNdQKq870B5lhbodVa2KAXV+gWUzP29 gAo2KW7m+wj46bo44nWk0/MB6NYYnqLnRZYKyv4= X-Google-Smtp-Source: AGs4zMaLpNsWBsjl3aDsBh80be03B1V2NUtC4ZGZdEddc/Kyz5N6Vh15tL1QiE47SuNLRJbTPpu/EqWmE7S9+vi7WZM= X-Received: by 10.31.135.197 with SMTP id j188mr10893124vkd.34.1512590005860; Wed, 06 Dec 2017 11:53:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.56.218 with HTTP; Wed, 6 Dec 2017 11:52:55 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> <1cf221bc-e2e3-bc04-6559-d01eff2e1232@gmail.com> From: Mark Smith Date: Thu, 7 Dec 2017 06:52:55 +1100 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Tom Herbert Cc: Bob Hinden , 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, 06 Dec 2017 19:53:29 -0000 Hi Tom, On 6 December 2017 at 07:24, Tom Herbert wrote: > On Tue, Dec 5, 2017 at 11:59 AM, Mark Smith wrote: >> On 5 December 2017 at 08:28, Bob Hinden wrote: >>> >>>> On Dec 2, 2017, at 2:15 PM, Brian E Carpenter wrote: >>>> >>>> On 03/12/2017 08:53, Robert Raszuk wrote: >>>>>> >>> >>> I will add that swapping flow labels as I think Tom Herbert was proposing has much less side effects than inserting and processing extension headers. >> >> Which would then violate the Flow Label spec unless the Flow Label >> value is zero. >> > Mark, > > The exlcusion that the flow label might be change for "compelling > operational reasons" is in practice interpreted as the flow label may > change in flight (i.e. receivers and network nodes cannot assume flow > label doesn't change). So while doing something like this might be > against the spec as written, I have to think this is potentially much > less problematic and less churn than changing RFC8200 to allow > extension header insertion. > During the specification update of the Flow Label to better formalise it, I suggested Flow Label domains, with the analog being DSCP domains. That would have facilitated this sort of use. However, that was rejected - see Appendix A of RFC6436. I agree using the flow label is less intrusive than EH insertion, however it is still a fundamental change to IPv6 packet forwarding. It's already going to be a slow process to have IPv6 forwarding devices start using the Flow Label as a load balancing input. The idea to use the Flow Label for forwarding/switching goes back as far as 2004, and didn't get legs. https://datatracker.ietf.org/doc/draft-chakravorty-6lsa/ I don't understand why the SRH header is considered set in concrete, or more specifically how segments are identified in an IPv6 network, while far more fundamental changes to IPv6 forwarding are considered fine. I don't think SR has been widely deployed, and probably less so over IPv6 networks using EH insertion. It's a technology that is only a 3 or 4 years old (or something like that), compared to IPv6 which is now more than 20 and easily accessible in as early as 1998 (I was playing with Linux's implementation then, and Cisco's implementation a year later). 20 year old IPv6 forwarding implementations and deployments would be 100% compatible with SR based on tunnelling. I can think of a number of ways that SR segments can be identified that would be compatible with IPv6 forwarding that would reduce the size of the SRH EH - as suggested before, unique /64 per device, with the /64 carried in the SRH TLV, reducing the TLV size by 8 octets. - well known or locally selected single /64 for the SR function, then unique 64 bit IID per device, with the 64 bit IID carried in the SRH TLV, reducing the TLV size by 8 octets. This could be automatically generated via a PRNG. It would be safer to check for collisions, although probably not necessary. - well known or locally selected single /64 for the SR function, segment IDs 20 bits to match SR-MPLS IDs, 20 bits carred in the SRH TLV, reducing the TLV size by 13 octets. - well known or locally selected single /64 for the SR function, segment IDs 32 bits, and matching the OSPF or BGP IDs, which are represented as "IPv4 addresses", 32 bits carried in the SRH TLV, reducing the TLV size by 12 octets. In this latter case, the SR-MPLS IDs could possibly be auto generated by slicing off the lower 20 bits of the 32 bit IIDs, as people commonly vary the lower octets when they allocate OSPF or BGP IDs. Regards, Mark. > Tom > >> I think the less fiddling with packets in flight the better. Change >> creates opportunities for failure, so the less change the better. >> Encapsulation/decapsulation is much less change than EH insertion or >> modification (and restoration if the original value was non-zero) of >> the flow label. Change in the network, if necessary, should be >> minimised. >> >> The IPv6 SRH EH is obese because of the use of full 128 IPv6 addresses >> as segment identifiers. It is not a requirement to use 128 bit values >> as segment identifiers as in SR-MPLS they are only 20 bits i.e. the >> MPLS label size. >> >> Fix the SRH obesity problem and then there is no need to make a very >> fundamental change to IPv6 EH processing, and no need force customers >> to forklift upgrade their existing IPv6 networks to adopt SR >> (tunnelled SR is an incremental upgrade, as SR implementations can be >> plugged in on the side of existing IPv6 forwarding devices, similar to >> the way Ipsilon added IP routing capabilities to ATM switches.) >> >> The network wide forklift upgrade required to adopt this SR via EH >> insertion will impact its rate of adoption. The cost of the solution >> needs to be significantly cheaper than the cost of continuing to deal >> with the problem to encourage adoption. Incremental upgrades rather >> than forklift upgrades are cheaper in both capex and opex. >> >> Regards, >> Mark. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Wed Dec 6 13:32: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 177C5127599 for ; Wed, 6 Dec 2017 13:32:42 -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, 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=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 fRixY6yeYrdn for ; Wed, 6 Dec 2017 13:32:40 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 C220F127286 for ; Wed, 6 Dec 2017 13:32:39 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id m59so12593039qte.11 for ; Wed, 06 Dec 2017 13:32:39 -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; bh=AXPL0bhrBH/GDvwV0DqW3ZOc2Ax0aGFc0Yt5w2INN+w=; b=Yn1tUBptw26zQk1VfOsdGTpzTYuZoKRerE4XCwH065yuhvsJ4lySSi1hgPJzsTyKP6 ZcDFYP4Nysru8hqbydpLTX/0YhgjpikwbRE05vT8tjc2KM/zrP9H1VQInVNrDzjIAikD U1icWs/FUFhdWzthOSmTX5RwYEDW/RoXTrFIBdnQo8tZnrexdDQqVoQgxR7AK3lls54v udPD6SuUNePFao1zc9JEGyxJhsdwCTackOR+E8XBbJ/55hmKySGNJt4yiCT36jnzozXW CgJZkJkIHQg8g+QeojQwv0xduglDeqSBqrq+LxajJ1w9t2hBZLtF5/RekQrKjwlfC9bI saEw== 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=AXPL0bhrBH/GDvwV0DqW3ZOc2Ax0aGFc0Yt5w2INN+w=; b=qmpkbBznbKFuoQwOTUuaTIwMWWSWq3OkTMT64ZOCPaHpnpa9loeFmEW9bSDzwRoggR +MYJWCxZXCi6RBtBeai9H5xVNspvRrLVgJOnfX3flMJvSCc7ynjc2x5MomJlK0clogGv BT8OOlCW2v3Qj1WvO7hLUM9ggZhSQJ3qKyz3wYqPMtpMUy2veAVc56Cmf+EANrLdmcOL 7LZ9lB8yJr1qvj6na9AnPO4EoFr1D3qXqfqTmDx4qY5iKWUSY6wr4YZtFJ7MXQSwWD8o OJj0FiMoERQPA4JAuxEaZMy5J181bQHhnc+C5xr1XADraL0LWHll4ulIlU2LlFZF8qJT E8bw== X-Gm-Message-State: AKGB3mKeLukMnKB+hcEEGVW8mDIMYQKy1rNOvBZCxY8c5/YRgY5X6W1A fJOwTtRDcpHu3+gkDhJrLOpjSQFm2JFO1xEyqer+cg== X-Google-Smtp-Source: AGs4zMYG4uv4IILThW19RrsVheP/vxKj+eUPCvDcTQv+KAvcbhOak7L+pWcWWwWQ6OhUVPkhH2fpQKaw28Xkc6ylbK8= X-Received: by 10.200.49.99 with SMTP id h32mr6248017qtb.196.1512595958707; Wed, 06 Dec 2017 13:32:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.121 with HTTP; Wed, 6 Dec 2017 13:32:37 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> <1cf221bc-e2e3-bc04-6559-d01eff2e1232@gmail.com> From: Tom Herbert Date: Wed, 6 Dec 2017 13:32:37 -0800 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Mark Smith Cc: Bob Hinden , 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, 06 Dec 2017 21:32:42 -0000 On Wed, Dec 6, 2017 at 11:52 AM, Mark Smith wrote: > Hi Tom, > > On 6 December 2017 at 07:24, Tom Herbert wrote: >> On Tue, Dec 5, 2017 at 11:59 AM, Mark Smith wrote: >>> On 5 December 2017 at 08:28, Bob Hinden wrote: >>>> >>>>> On Dec 2, 2017, at 2:15 PM, Brian E Carpenter wrote: >>>>> >>>>> On 03/12/2017 08:53, Robert Raszuk wrote: >>>>>>> > > > >>>> >>>> I will add that swapping flow labels as I think Tom Herbert was proposing has much less side effects than inserting and processing extension headers. >>> >>> Which would then violate the Flow Label spec unless the Flow Label >>> value is zero. >>> >> Mark, >> >> The exlcusion that the flow label might be change for "compelling >> operational reasons" is in practice interpreted as the flow label may >> change in flight (i.e. receivers and network nodes cannot assume flow >> label doesn't change). So while doing something like this might be >> against the spec as written, I have to think this is potentially much >> less problematic and less churn than changing RFC8200 to allow >> extension header insertion. >> > > During the specification update of the Flow Label to better formalise > it, I suggested Flow Label domains, with the analog being DSCP > domains. That would have facilitated this sort of use. However, that > was rejected - see Appendix A of RFC6436. > > I agree using the flow label is less intrusive than EH insertion, > however it is still a fundamental change to IPv6 packet forwarding. > It's already going to be a slow process to have IPv6 forwarding > devices start using the Flow Label as a load balancing input. > > The idea to use the Flow Label for forwarding/switching goes back as > far as 2004, and didn't get legs. > > https://datatracker.ietf.org/doc/draft-chakravorty-6lsa/ > > I don't understand why the SRH header is considered set in concrete, > or more specifically how segments are identified in an IPv6 network, > while far more fundamental changes to IPv6 forwarding are considered > fine. I don't think SR has been widely deployed, and probably less so > over IPv6 networks using EH insertion. It's a technology that is only > a 3 or 4 years old (or something like that), compared to IPv6 which is > now more than 20 and easily accessible in as early as 1998 (I was > playing with Linux's implementation then, and Cisco's implementation a > year later). 20 year old IPv6 forwarding implementations and > deployments would be 100% compatible with SR based on tunnelling. > > I can think of a number of ways that SR segments can be identified > that would be compatible with IPv6 forwarding that would reduce the > size of the SRH EH > > - as suggested before, unique /64 per device, with the /64 carried in > the SRH TLV, reducing the TLV size by 8 octets. > > - well known or locally selected single /64 for the SR function, then > unique 64 bit IID per device, with the 64 bit IID carried in the SRH > TLV, reducing the TLV size by 8 octets. This could be automatically > generated via a PRNG. It would be safer to check for collisions, > although probably not necessary. > > - well known or locally selected single /64 for the SR function, > segment IDs 20 bits to match SR-MPLS IDs, 20 bits carred in the SRH > TLV, reducing the TLV size by 13 octets. > Mark, I don't see how that's going to help much. The authors of this draft have already stated that in order to doing EH insertion they will need to encapsulate when packets enter the SR domain, so that's forty-bytes of overhead right of the bat. And then there's the fixed overhead of the EH before we finally get to the savings of compressing the EH data. But even more important than the size of the headers, is the processing cost. Processing fixed encapsulation at high speed is expensive. Processing open ended header chains and TLVs is _really_ expensive to the point that they to date they are undeployable. While I appreciate the optimism of the authors that the problem of processing EH TLVs at line rate has been solved, I must admit I am skeptical. It is hard to ignore a long history which has not been kind to header chains or TLVs in IP. The obvious value of using something like the flow label is that it is a zero overhead solution in the wire protocol. No encpasulation and no EH. The route lookup for this could be implemented in a TCAM on src,dst,flow label and the action is just to write a 20 bit value. ILA, which serves the overlay network use case, is even simpler-- this is a fixed length lookup on the destination and a write back to the destination address. Flow label is not used and no change to standard protocols is required, Tom From nobody Wed Dec 6 14: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 6A479128799 for ; Wed, 6 Dec 2017 14:51:57 -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 RZqRkutRM0gp for ; Wed, 6 Dec 2017 14:51:55 -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 B284712711E for ; Wed, 6 Dec 2017 14:51:55 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id o2so3019392pgc.8 for ; Wed, 06 Dec 2017 14:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2tieYeI4QzItDuCzUcJArevN1qZV19DItwnivnN2dyI=; b=WMmnzagYr9H6Yo3M8K0HMMudYxoJHzQK0SOqtTiCDHJ2dlPHQ0/Fbxd8x8aqUrpnBA ec42XpNsu0DQqy0VFZnyXLm9KWvlzQteIogHjbGtejwZ/WoqJiZpBZ27y0vmxcGbqRYe 1oRswqMUc9qnkiVvhGQdYftHxRGfrr8buPTvag6zshxAzJdLu4Ii8lYVjotFUpFNryJa VmwLqs4kqzgxR/bR+DFEIXIzy7mpOH0/BicPRTSUo8Z30JOB15XiiZbuiRqBlbD1ib3i 2xzIHbbsaFAo3Mfdq2ctS3FjQKnxa4yyFg53Y4oOPqw2CK0UNIczIgUteW+0VOt4TCzJ V1cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2tieYeI4QzItDuCzUcJArevN1qZV19DItwnivnN2dyI=; b=lE8nJzbxxE8t38IOEOjl7eFA4GZ6PJCfZa+JRF6U6OVDfOIfJlrHuOUYr069RRAuCN /Hyz3Id8z5W2nB4G6MoHJ7WDH/6Xha5XcgKn934e9OtojhMfi8d+K0xvnQR2AACQrHH0 0Vm8LJrl2LHO9hocRchxfH518lBAlf7b9VfIT3X/YxP3BU9wiNSHOr55ENCsTsRELmci iavoaxEUwA6grO7YGgVuqN51Pq3NhRSRuYfeUDD9lTfvUzxp1rybvnygPC2amuvuDAiI +3yzDR1av4F+mk/D/uUoqKWw7wLnL4Yvv0IvYx6XmaeAvsQfVMizk7NQxYUA1iMvU62Q 0SMg== X-Gm-Message-State: AJaThX7tKISOSnH5EmezlrWvXJc5Tcgmy3L17kFZahRjaQjVoOrbf9/7 0hAmRs1jjqkE+JUzhWVdGJk= X-Google-Smtp-Source: AGs4zMYa/c1XhazVvz1L/ZfYUd8dgscXN6quAfRRDjWNreCUWt8V1NGWN0vZDQeflSvU6LqDJPwk0g== X-Received: by 10.84.132.129 with SMTP id e1mr24266622ple.376.1512600710281; Wed, 06 Dec 2017 14:51:50 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x22sm6085576pfa.169.2017.12.06.14.51.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 14:51:49 -0800 (PST) Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Mark Smith , Tom Herbert Cc: IPv6 List , Bob Hinden References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> <1cf221bc-e2e3-bc04-6559-d01eff2e1232@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 7 Dec 2017 11:51:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 06 Dec 2017 22:51:57 -0000 On 07/12/2017 08:52, Mark Smith wrote: ...> I don't understand why the SRH header is considered set in concrete, The issue is surely whether it is already set in silicon. While we can argue about anything, there isn't much point in arguing with hardware. Brian From nobody Mon Dec 11 23:20: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 56ADC1277BB; Mon, 11 Dec 2017 23:20:56 -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 D0vkUT-ZGXGK; Mon, 11 Dec 2017 23:20:55 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 C4CFC1241FC; Mon, 11 Dec 2017 23:20:54 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id a12so22018002lfe.4; Mon, 11 Dec 2017 23:20:54 -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=H37ulJZoJ2bsC4KS3lsrCHbLt72+TS81HOOernS4rdg=; b=HvTloF/+yuowanKik/WHrbU6pxZQvusGez8hbdWIJCap1j6hAMR23TusjWPciadgk1 YJa4nlD43dL0aD+2LKJoyp2odAUDk+YnTy/vj8FGVry7Sf/Asor8Bh+HsmPRznUc+rir qmrYrcCvcihf1Sv0IUg7GC/JohFiPr/iCqQT2qji2bdT1hm3XMKAP3cWrfVAUJE+JOQw WHhNgXa7Lmp9LCAlujPjax2u59FaO19fym9BsajDL1gGmtISZjTFO4vtGxDa8HXnsos/ m1JvtsY7mqickDGDWpLD22sqBVRkfAocERd0Una2+CXEB/UpFlYLaOvg5rbWIIVAdrkw mDyA== 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=H37ulJZoJ2bsC4KS3lsrCHbLt72+TS81HOOernS4rdg=; b=ge43dwi6AoOf/l1sWprwB4BnLyQh+QbqLRroVQEywxT6VWPKi4BGqgMHSNuZwAR9da XC4zqOFORh12DBwJc8NDA4p3Y6ve3WGW/FFX5ydMwGep8ZvXSkF3o9U6aqTUtXyfq9+Z LTiJnvoZ0xiBLnumBvsC2Z1eszCALjxJpbZqxKx0XAUu2q2hHcj0tgQJbFsDbs5dofvb mOzsxEPhth4twR1dWp/KwYlnHfaVdw/maLXSPpAnWTZeTSYr2nUX0JUipN3qlt4NmcMy gzC6s4EtWwHgoIshmp1YknFKNUSsTAIBu224XPO0sVWhQnq6dAMuItyYTWOJPDkE6OXY 2XSA== X-Gm-Message-State: AKGB3mLsFOImYZwQP8aServ0P/qWhod4rPRce1asRZX3UnNfEO61CnEB 6ZnilOZd2Y0Xz5BgHbH1EJYP8qo9TXqhJsXnusCy5Q== X-Google-Smtp-Source: ACJfBoue3sM61DBOCmuUqBZN2qsBWkhlp48q/6bsl8VEF/4ouEKRy4FRTb5bS2ocHhmXPIPNIhpEpQdk2TJbrZGhCs0= X-Received: by 10.46.20.5 with SMTP id u5mr1573227ljd.9.1513063252644; Mon, 11 Dec 2017 23:20:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Mon, 11 Dec 2017 23:20:31 -0800 (PST) From: Naveen Kottapalli Date: Tue, 12 Dec 2017 12:50:31 +0530 Message-ID: Subject: Windows 10 doesn't honour 'M' flag in RA To: 6man WG , v6ops list Content-Type: multipart/alternative; boundary="f403045fc116b257f405601f7d1f" 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, 12 Dec 2017 07:20:56 -0000 --f403045fc116b257f405601f7d1f Content-Type: text/plain; charset="UTF-8" Hello, In our recent testing, we observed that Windows 10 doesn't honour 'M' flag in RA. It's not just Windows 10, same behaviour is observed with latest Mac OS as well. Is there any specification reference to support this? Your valuable input is highly appreciated. Yours, Naveen. --f403045fc116b257f405601f7d1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

In our recent testing, we observ= ed that Windows 10 doesn't honour 'M' flag in RA.=C2=A0 It'= s not just Windows 10, same behaviour is observed with latest Mac OS as wel= l.=C2=A0 Is there any specification reference to support this?
Your valuable input is highly appreciated.

Yours,
Naveen.
--f403045fc116b257f405601f7d1f-- From nobody Mon Dec 11 23: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 A84521277BB for ; Mon, 11 Dec 2017 23:26: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, 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=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 7jRB-mHSqJ9x for ; Mon, 11 Dec 2017 23:26:16 -0800 (PST) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 6F9CA1241FC for ; Mon, 11 Dec 2017 23:26:16 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id z62so7743790yba.11 for ; Mon, 11 Dec 2017 23:26: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=PV00J4fLmOLQhbpr2oNRlwlOHaUvmh4UbAbccCm/jKE=; b=kTwqZBjrNZNbgNcpTbO8Pw+W/o0X/6yMeFmk/hSq+HuJxB8DEbpyuYTW/OsQRLT//D Gv/Dcn93sD73VrT05vT4C/4lwmdOrDfOQwJRXzIHPFNkLAHDcuRWB0VyV/2Yt5sIbm7z +h8hTBX8tK+SpJb0lM6eNlpdlr99g7Dxsbtd0Io7IjW+SXCxsRmLtMLRkQ+G6j18Y0mu qnGuH8nXGK37wEbgAw+i/1CDRKM/KFUy8xRMdkgiiPa8LLe1Cym5zFnKQmYaPDmnTPar Ae3TRJgq9HIj2yB+FrSocoo5c6lBeTJkeGGEuMpQfUk9C0+voQCJ9AYFaH3h1BiQfHLN UDGQ== 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=PV00J4fLmOLQhbpr2oNRlwlOHaUvmh4UbAbccCm/jKE=; b=Vv/h5SsDYQfytHlgS8iV8gyFBLm3YbG2dVynXe9jcvBTa1QLvnl+qUa23A/gM1Sw7R rF86H4woe9VJSvsQrmAgWVVrIUHVdVf+1D8dOIKIW0nM7tbgbVFux56ZQhHu9+4IbgBm Gvz/6PyRktmFLSXmHlqaW+m3feLW5ZxHMchpVWn7lW2jSbYeIdJh6wAJu+N/i3QR79Tm j6F3pIhimDfdtOpk2b95arIsdM38hrgd1S5X2cP2e2rzG9bng8CLoF7VoEGN8NzrF5Wk WUS8RRSR2xiO582G+PrJAwuKumdxVq4kFztDOhLiL6PPFfstP2TXay+CzjcRJ4cKEvMz AF9w== X-Gm-Message-State: AKGB3mLBErNB/gsL6AXN9JnolAAYiyKtJ7tsJyH9qXkF4EOfcj+JXKrB IXI76no5DiwyZZB1TnH3V3s4m/L4PVhFpMQZyG7qNg== X-Google-Smtp-Source: ACJfBouFPXSkswA+X2BcLw0fpCq5UvdN87cbeh7bgdC6lpEMFs5p/sFKPxPnkLRx97dH+lvOQTrtDspNbMJ9GvLx0Tw= X-Received: by 10.37.77.65 with SMTP id a62mr2282322ybb.185.1513063575172; Mon, 11 Dec 2017 23:26:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.185.199 with HTTP; Mon, 11 Dec 2017 23:25:54 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Tue, 12 Dec 2017 16:25:54 +0900 Message-ID: Subject: Re: Windows 10 doesn't honour 'M' flag in RA To: Naveen Kottapalli Cc: 6man WG , v6ops list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113c5646f71baf05601f90b7" 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, 12 Dec 2017 07:26:20 -0000 --001a113c5646f71baf05601f90b7 Content-Type: text/plain; charset="UTF-8" What does it really mean, to "honour the 'M' flag"? Those bits are advisory /at best/. On 12 December 2017 at 16:20, Naveen Kottapalli wrote: > Hello, > > In our recent testing, we observed that Windows 10 doesn't honour 'M' flag > in RA. It's not just Windows 10, same behaviour is observed with latest Mac > OS as well. Is there any specification reference to support this? > > Your valuable input is highly appreciated. > > Yours, > Naveen. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a113c5646f71baf05601f90b7 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgZvoZH/c/5Vt6gJQCB3rJ7P3Ed++zXTsw cozv2fGQdHMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjEy MDcyNjE1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADCkpapDRdckdH+HC9P6H/N2hoN3hfRg50B50HFghebglqbuwQbb VmBk7LzOwmzmYNgwtk7/914UFB2CnH6Jb3RDHgQdSGjg+XTZju92xdygbm6djFZ+mKFN5rI5GjGa 5kfwfqTwFVzTc2KGB/IWMF5zg6OFf2S7SXLLNHd4JcxKF9kRnxg3e1ma/4e8fQ5rQQFIpqdA8Luw k1wAbm379dwcfQz8a5ljOBfVSCECsI78xSsKuUjbEkB27KF18+iUYdqY6vl7vnqRQZP+/J6We71Y H1dHUPZwlV1cx6xVTPbrnaZ3UQAJBAHKEjWv171VrOew/BeC21M6KtffWwgCQM8= --001a113c5646f71baf05601f90b7-- From nobody Mon Dec 11 23:40: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 BCFF21293F9; Mon, 11 Dec 2017 23:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 MYg73m4mHw_y; Mon, 11 Dec 2017 23:40:35 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 E56D91293F2; Mon, 11 Dec 2017 23:40:34 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x204so22042509lfa.11; Mon, 11 Dec 2017 23:40:34 -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=PCpmkq3307SrmqTTeWQVMn8McUSs/aAwK5oq9Be0T+8=; b=bGWazaVvWp5S0waWS+FZ24IcY3FJeX6JoIJAxBxg/2A9Z6ej1f84fFYwPqag/cy85t K4zxwTtbO1jG4ejJFuxuD1+Xod5/dCDhUZePKU8RAM3OQvymiK4x/Q2l0opz8pNzj1V9 kszRBlwPod5xoNUz09aPqsOfjJ0PKTZPzHZReVUOCzkWnPl7/yyg4mSfE1JX5h2nKz1O wE/X9qOoXm6alt+vPtXYGEZOfAt0JiM/8zIGJYsZdUKmEeh7WRFdtdaH4JONY4do3aqa 1ZZY16Y2TrpFd+KeD2G0sZhWP10uPOHuD4tCyEzIHPtYJIgvGZBHPdL9QTEWvksFizh4 0DBA== 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=PCpmkq3307SrmqTTeWQVMn8McUSs/aAwK5oq9Be0T+8=; b=Gnp95jlOfiQ35ZK+eBBm9bp/bCbGO4yoX8Qox8BtgwgV4e+gw/T0B2RcNtR9U5X9Cd IXwj8rWFqcsC631JL2y1+lxd3GHw57i1mNCyc4vPPxsNLbFua/GLlVQPY/ZDBgbnMAKR n5PSGMPGBmMP+bPnujJGheroegXmy/QACRx1BFm4SoWvUpSB9IPBtIr6d9+C5dlh83Jh EJ8sifSOaP3nWmoAVKWIP7XIHpt5GxTT6GwRer76hYmYJ2Am1l9obSPAmxg5eTEiE4qD 8kjeHZd5HPHsfWlom0e+gMAc92wIu7VHE+u7Cf8rxunfzhqYuexTldFPwynPsM/C+5EH +EgQ== X-Gm-Message-State: AKGB3mJG/71hn2PPoAKFR40ahoeodHTXICVwMJ+98ug/cAn6uJMXKn8n jEGmnI9AY7Uz9Ik5jEcegQNjiBJiD1x7H+akOzE= X-Google-Smtp-Source: ACJfBou2rkFVV/ZKj0wigboCRbz+pBVnzRIeLjzozZxl+DT2AgTbG49bgib8ZttttkM/8FrmuQdW6CytyrAihquijDs= X-Received: by 10.46.23.20 with SMTP id l20mr1440983lje.25.1513064433126; Mon, 11 Dec 2017 23:40:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Mon, 11 Dec 2017 23:40:12 -0800 (PST) In-Reply-To: References: From: Naveen Kottapalli Date: Tue, 12 Dec 2017 13:10:12 +0530 Message-ID: Subject: Re: Windows 10 doesn't honour 'M' flag in RA To: Erik Kline Cc: 6man WG , v6ops list Content-Type: multipart/alternative; boundary="001a114b6b6c0f10c005601fc405" 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, 12 Dec 2017 07:40:37 -0000 --001a114b6b6c0f10c005601fc405 Content-Type: text/plain; charset="UTF-8" I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit. Yours, Naveen. On 12 December 2017 at 12:55, Erik Kline wrote: > What does it really mean, to "honour the 'M' flag"? Those bits are > advisory /at best/. > > On 12 December 2017 at 16:20, Naveen Kottapalli > wrote: > > Hello, > > > > In our recent testing, we observed that Windows 10 doesn't honour 'M' > flag > > in RA. It's not just Windows 10, same behaviour is observed with latest > Mac > > OS as well. Is there any specification reference to support this? > > > > Your valuable input is highly appreciated. > > > > Yours, > > Naveen. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > --001a114b6b6c0f10c005601fc405 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I mean that though the 'M' bit is set to 0, client= initiated DHCPv6 Solicit.

Yo= urs,
Naveen.

On 12 December 2017 at 12:55, Erik Kline <ek@go= ogle.com> wrote:
What doe= s it really mean, to "honour the 'M' flag"?=C2=A0 Those b= its are
advisory /at best/.

On 12 December 2017 at 16:20, Naveen Kottapalli <naveen.sarma@gmail.com> wrote:
> Hello,
>
> In our recent testing, we observed that Windows 10 doesn't honour = 'M' flag
> in RA.=C2=A0 It's not just Windows 10, same behaviour is observed = with latest Mac
> OS as well.=C2=A0 Is there any specification reference to support this= ?
>
> Your valuable input is highly appreciated.
>
> Yours,
> Naveen.
>
> -----------------------------------------------------= ---------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------
>

--001a114b6b6c0f10c005601fc405-- From nobody Mon Dec 11 23:45: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 70DF91267BB; Mon, 11 Dec 2017 23:45:43 -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, 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 uG-ceMzkV0cL; Mon, 11 Dec 2017 23:45:40 -0800 (PST) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4381293FD; Mon, 11 Dec 2017 23:45:40 -0800 (PST) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 1886F2732B; Tue, 12 Dec 2017 08:45:39 +0100 (CET) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id EEA0B658849; Tue, 12 Dec 2017 08:45:38 +0100 (CET) Received: by ws26.ernw.net (Postfix, from userid 1002) id CA8C1393B4; Tue, 12 Dec 2017 08:45:38 +0100 (CET) Date: Tue, 12 Dec 2017 08:45:38 +0100 From: Enno Rey To: Naveen Kottapalli Cc: Erik Kline , v6ops list , 6man WG Subject: Re: Windows 10 doesn't honour 'M' flag in RA Message-ID: <20171212074538.GB48853@ernw.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) 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, 12 Dec 2017 07:45:43 -0000 Hi, On Tue, Dec 12, 2017 at 01:10:12PM +0530, Naveen Kottapalli wrote: > I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit. that's a deliberate decision from Microsoft: their recent OSs all send out DHCPv6 Solicits at a very early stage of (IPv6) stack initialization (even before sending the router solicitation => at that point there's not even an RA to process/to inspect the flags of). See also https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/ best Enno > > Yours, > Naveen. > > On 12 December 2017 at 12:55, Erik Kline wrote: > > > What does it really mean, to "honour the 'M' flag"? Those bits are > > advisory /at best/. > > > > On 12 December 2017 at 16:20, Naveen Kottapalli > > wrote: > > > Hello, > > > > > > In our recent testing, we observed that Windows 10 doesn't honour 'M' > > flag > > > in RA. It's not just Windows 10, same behaviour is observed with latest > > Mac > > > OS as well. Is there any specification reference to support this? > > > > > > Your valuable input is highly appreciated. > > > > > > Yours, > > > Naveen. > > > > > > -------------------------------------------------------------------- > > > 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 > -------------------------------------------------------------------- -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Mon Dec 11 23:47: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 625A1129408; Mon, 11 Dec 2017 23:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, 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 K6KrSuTvi3Lm; Mon, 11 Dec 2017 23:47: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 322571267BB; Mon, 11 Dec 2017 23:47:29 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DB9EDB2; Tue, 12 Dec 2017 08:47:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1513064846; bh=Rz055voezXYi5Y5PTQ/xNHx8th4t4d7PhonJkc4QEIc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DlMPJPmfqttgAfldEJnT4aUMo5t/3kisC1B+S1TAmKo0aqd/YZ8eQ9tmCJM1QD6LC fcREBbxPp2LxCKcVtOQDOSOBoJB6LT0YLbS131QdGg4t2ujlMuAkYLl/Y0bo5KyF/o hhdH82Bu++6GyGw6SYEhoHs8dWCNmk3Q5+VGKphM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D734EB1; Tue, 12 Dec 2017 08:47:26 +0100 (CET) Date: Tue, 12 Dec 2017 08:47:26 +0100 (CET) From: Mikael Abrahamsson To: Naveen Kottapalli cc: Erik Kline , v6ops list , 6man WG Subject: Re: Windows 10 doesn't honour 'M' flag in RA In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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: Tue, 12 Dec 2017 07:47:30 -0000 On Tue, 12 Dec 2017, Naveen Kottapalli wrote: > I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit. M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. >From earlier discussions, there is nothing saying "you can't do DHCPv6 requests if M=0". So technically these implementations aren't in violation of any standards, the M and O flags are only informational. It would however be interesting to understand the rationale if this change from the OS vendors. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Dec 12 10:51: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 348DA1294F5; Tue, 12 Dec 2017 10:51:10 -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 ZWTpbF1A9VKJ; Tue, 12 Dec 2017 10:51:08 -0800 (PST) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 C44A41286CA; Tue, 12 Dec 2017 10:51:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBCIp4sC050121; Tue, 12 Dec 2017 10:51:04 -0800 Received: from XCH15-06-04.nw.nos.boeing.com (xch15-06-04.nw.nos.boeing.com [137.137.100.81]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBCIp13O050009 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 12 Dec 2017 10:51:01 -0800 Received: from XCH15-06-02.nw.nos.boeing.com (137.137.100.78) by XCH15-06-04.nw.nos.boeing.com (137.137.100.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 12 Dec 2017 10:50:50 -0800 Received: from XCH15-06-02.nw.nos.boeing.com ([137.137.100.78]) by XCH15-06-02.nw.nos.boeing.com ([137.137.100.78]) with mapi id 15.00.1347.000; Tue, 12 Dec 2017 10:50:50 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" , "ipv6@ietf.org" Subject: RE: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Topic: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTc3ids/3rysN/2UOtzik0uog6BqNADGWA Date: Tue, 12 Dec 2017 18:50:50 +0000 Message-ID: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> 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] x-tm-as-matchedid: 1-140811-150567-701625-704425-700685-705450-700476-705102 -706378-708882-700107-148004-148133-148980-10019-24817-35009-41000-42000-42 003-29961-666801 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: Tue, 12 Dec 2017 18:51:10 -0000 This is why it would be better to have IPv6 ND and DHCPv6 as a unified stateless/stateful autoconfiguration service. Everything can be done in a single message exchange (RS/RA with DHCPv6 option) instead of requiring multiple message exchanges just for the sake of examining the M/O bits. Thanks - Fred From nobody Tue Dec 12 14:33: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 BBA12124D37 for ; Tue, 12 Dec 2017 14:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 wztxrpLy0VjR for ; Tue, 12 Dec 2017 14:33:50 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 657A11279E5 for ; Tue, 12 Dec 2017 14:33:50 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id j124so345456pfc.2 for ; Tue, 12 Dec 2017 14:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=UnKv6jHEErKYx3JLb/fpf5AqNr3Hbl0UOlJP0p1886o=; b=eUZrSS8Z5nAki96YlXDEn/0j2cSOzIAmyY+q42QSqZlCsYRMGrLMYQniN6LG/Iqjyk MVA4H2bLY2LlSVT/DzrIklVEROl/zUeAnJ8Y+RArt0OFZdmkc7TvptukQSGSRx9yn04F 4dPPfAR4J77Oh6Nq4iZ9lYrQXFqLc9MyPdZkTGiCKRNrp/FhJPlzVKNjKCONA3o5pGe3 leXvcKTCYtfjqnniOjTcO6iBt4pbA71tUCau2GKD3lw1R/oykAuKxzhSgVBLIaO9NDgo KyrXUR2EIfj8Uj0zK2PbYarnAA2NgFWsKQINtNBq9PAvKwm3QQAoPVIyzNYks2Ns4Ev5 +sew== 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:cc:to :message-id; bh=UnKv6jHEErKYx3JLb/fpf5AqNr3Hbl0UOlJP0p1886o=; b=k7riey14n7ANXmv+ocAd54RX4CZx6ijGSmQPxranjUvc4b9Y95Cv9IPG7R0LvfNVzJ FT7a5/DtikRaP2zomahTVEmUOR3+epiho/G+dSX4VRX+7JPA6gCBYVd4CD9AU/n58l1Y StJKFoTnLU16iTGWXUXv04EBZO4IVqMNiwgkb1+YB8XbM1aOMlHQCRWrtwEzmt1ncjZj xdXABkEwRRaTUnv5CtJgOirzeFGaw3Ycx+oGySJywUW1yLDkJtleNWVMRC6aX57Ptfm6 oojIkfjw7Emn7YV/RodqK2MUZxJOO4Xq/J4uaTYrRmo/bxaaepjSCLwzgMyZrhpkDE3+ kE8g== X-Gm-Message-State: AKGB3mI0p2ipFE17v9Qe0fEIqMYKQfH48A4d2IB+eCiVYJ0aRgqLxdsG qTSCncdkq8CfJ/sayIJ2AoSf8jVh X-Google-Smtp-Source: ACJfBosfL1J1VCdHSfuOvc6WzANOYkVq73mmTt1wddHlXI3F3tvR/jvBIUXwDD+8loiwaFgNzTIcQg== X-Received: by 10.159.229.200 with SMTP id t8mr3852294plq.346.1513118029548; Tue, 12 Dec 2017 14:33:49 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id q72sm226522pfi.42.2017.12.12.14.33.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 14:33:48 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_BA3B4A11-4EBD-4A80-A849-CB432A278B02"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: New Version Notification for draft-hinden-ipv4flag-01.txt Date: Tue, 12 Dec 2017 14:33:46 -0800 References: <151311762550.30105.15490803659981825351.idtracker@ietfa.amsl.com> Cc: Bob Hinden , Brian Carpenter To: IPv6 List Message-Id: <09613E79-FAA9-49DF-9997-5C4739DF360A@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: Tue, 12 Dec 2017 22:33:53 -0000 --Apple-Mail=_BA3B4A11-4EBD-4A80-A849-CB432A278B02 Content-Type: multipart/alternative; boundary="Apple-Mail=_3AF56BDB-FE6C-4214-9FBA-500EAFB04A16" --Apple-Mail=_3AF56BDB-FE6C-4214-9FBA-500EAFB04A16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Based on the discussion on the previous draft, we updated it. We think = this resolves many of the issues raised. The changes include: o Inverted name of flag from "Available" to "Unavailable=E2=80=9D. o Added problem description and clarified scope. o Added router and operational considerations section. o Added host behavior considerations section. o Extended security considerations section. o Added Acknowledgment section, including reference to prior sunset4 = draft. Please review and comment. We think this version is an improvement over = the -00 version. Thanks, Bob & Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hinden-ipv4flag-01.txt > Date: December 12, 2017 at 2:27:05 PM PST > To: "Robert M. Hinden" , "Robert Hinden" = , "Brian Carpenter" >=20 >=20 > A new version of I-D, draft-hinden-ipv4flag-01.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-hinden-ipv4flag > Revision: 01 > Title: IPv6 Router Advertisement IPv4 Unavailable Flag > Document date: 2017-12-12 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-01.txt > Status: = https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/ > Htmlized: https://tools.ietf.org/html/draft-hinden-ipv4flag-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4flag-01 >=20 > Abstract: > This document specifies a Router Advertisement Flag to indicate that > there is no IPv4 service on the advertising default IPv6 router. > This document updates RFC5175. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_3AF56BDB-FE6C-4214-9FBA-500EAFB04A16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Based = on the discussion on the previous draft, we updated it.  We think = this resolves many of the issues raised.  The changes include:

   o  Inverted name of flag from "Available" = to "Unavailable=E2=80=9D.  

   o  Added problem = description and clarified scope.

   o  Added router and = operational considerations section.

   o  Added host = behavior considerations section.

   o  Extended security = considerations section.

   o  Added Acknowledgment section, including = reference to prior sunset4 draft.

Please review and comment.  We = think this version is an improvement over the -00 version.

Thanks,
Bob & Brian



Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hinden-ipv4flag-01.txt
Date: = December 12, 2017 at 2:27:05 PM = PST
To: = "Robert M. Hinden" <bob.hinden@gmail.com>, "Robert Hinden" <bob.hinden@gmail.com>, "Brian Carpenter" <brian.e.carpenter@gmail.com>

A new version of I-D, draft-hinden-ipv4flag-01.txt
has been successfully submitted by Robert M. Hinden and = posted to the
IETF repository.

Name: = = draft-hinden-ipv4flag
Revision: 01
Title:= = IPv6 Router Advertisement IPv4 Unavailable Flag
Document date: 2017-12-12
Group:= = Individual Submission
Pages: 8
URL: =            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-01.t= xt
Status: =         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-01<= /a>
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4flag-01

Abstract:
  This = document specifies a Router Advertisement Flag to indicate that
  there is no IPv4 service on the advertising = default IPv6 router.
  This document updates = RFC5175.




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


= --Apple-Mail=_3AF56BDB-FE6C-4214-9FBA-500EAFB04A16-- --Apple-Mail=_BA3B4A11-4EBD-4A80-A849-CB432A278B02 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 iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlowWUoACgkQrut0EXfn u6j5BQgAtXaSK8E1yVaz2KzRKK6lwbK8e/kpMCgukNdgfiTMHxbf2ZS1NgegYOER yeaYq2Uf6YR2va8o5qA+r+NViocxPwKpHwBZDHnXLQg/hPSGlxQV/rHN1E0GAY+Q Tj6ga0LrN7YVGnan0FIesluFbMaJhaLvTWEI+v7iSMaNyDW1HAth0egt5qZtd5/8 MudBS/8+e/Fe+yb9yn1pJ1OWMOPYSnZAGmncLScqWr3Yu7CPZxbHSBCvkHxDm3RC D7Z7M1JP4eJvxSbL9k2w2CJvsu2I4Gd11cP1D7vr+UgQIubLogCFNK8LjeNt2C48 giNznfSmbI7tkmfSyfpkhyygn0YvAg== =DETq -----END PGP SIGNATURE----- --Apple-Mail=_BA3B4A11-4EBD-4A80-A849-CB432A278B02-- From nobody Wed Dec 13 03:03: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 A1312128B8D; Wed, 13 Dec 2017 03:03:11 -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 wSpPtwnwCoJn; Wed, 13 Dec 2017 03:03:08 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 38ACB128D3E; Wed, 13 Dec 2017 03:03:08 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id l81so2141003lfl.6; Wed, 13 Dec 2017 03:03:08 -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=z10ESMJzlXIwCWFqezZcz4l4LFKTnSMNYmzTxXdecNo=; b=cUqeZHSY4Iy9T6SyWnxbd1nlFaZkuhMTlH0CssmEWEMt6lgjsLbpIYIBCsHYhuyxQB BKXZ3b5IBrdYwoUfk8YanoxxYxHPlMg81iut3mjbSIbeQda4IGr2MhP2hdUcbyPy7ZLi PAcZVe/e1h7TL1T2thR8TqKFV4KV7n+5Na1fqfSSNj1ccAuqzrBvh2Lo+4oP2aZWGfV3 ma7GUz23chwMhVIwGo0MnVXiyk1gvA5OVgzVh3MU9fpfhFRpbyeaeiievPRQ79Xj2EX7 5xSoLhmv6VkwRG+N+lFDmAgfXQtgNOZwt4NHsvH+IDubE4lylIZkWb/nHD3G3y51xfan 9blA== 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=z10ESMJzlXIwCWFqezZcz4l4LFKTnSMNYmzTxXdecNo=; b=EO577cKJekKp9YNk4rT+5bqaznEnQMt86hhhDUwG0oCFo3f/DJ7+WQHlPPmq12QGjh U6eJ6VpH/9sm1CXvDfZQuMgKZVleacfS50WkT0N4SrmHAJo5R5gqTL5XuGeKP6+izQgB T6tEKTtiC+JK+J/uUZZVvl/QFWPTittfL2SiW9vn31286VPoNoiPY38p82VQvqdSloJU nPF9Hu4hfXJ5arTFiCCb8hAyaUrMmmQkAPGIgfBpn6EVjgM4iChYF4Ofkv5ARLcr3BIn 236ij5Hh8znQgGbz4J5lLusLm/fRjdIPZU2eL+4bGoBvUslJlPpI7/o5Jn2vl13Vb+iQ DvxA== X-Gm-Message-State: AKGB3mILwGuQa+4lTBsfEMMV+XjdbIhCsDZnetwY+gH390C5Y8RcrKQT 8wWS/HIHixGTyZ64oHuJxNNI0Pah9EVCJ6YDHHLWfg== X-Google-Smtp-Source: ACJfBoucSemk0Sf7ORJcjpOW6hjzM0Ogwhfbxy8VOs2Ib+UevD3MvARRG4qXfPO8ntgHGiCJ8MeR4f/5niUy1KNdckI= X-Received: by 10.25.163.17 with SMTP id m17mr1306666lfe.88.1513162986420; Wed, 13 Dec 2017 03:03:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Wed, 13 Dec 2017 03:02:45 -0800 (PST) In-Reply-To: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> From: Naveen Kottapalli Date: Wed, 13 Dec 2017 16:32:45 +0530 Message-ID: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA To: "Templin, Fred L" Cc: "v6ops@ietf.org" , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a114033604b009d056036b659" 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, 13 Dec 2017 11:03:11 -0000 --001a114033604b009d056036b659 Content-Type: text/plain; charset="UTF-8" Yes, it would have been the better way. If clients aren't even referring the 'M' bit, what is the use of carrying in RA? Yours, Naveen. On 13 December 2017 at 00:20, Templin, Fred L wrote: > This is why it would be better to have IPv6 ND and DHCPv6 as a unified > stateless/stateful autoconfiguration service. Everything can be done in > a single message exchange (RS/RA with DHCPv6 option) instead of > requiring multiple message exchanges just for the sake of examining > the M/O bits. > > Thanks - Fred > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a114033604b009d056036b659 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, it would have been the better way.=C2=A0 If clients a= ren't even referring the 'M' bit, what is the use of carrying i= n RA?

Yours,
Naveen.
=

On 13 December 2017 at 00:20, Templin, Fred = L <Fred.L.Templin@boeing.com> wrote:
This is why it would be better to have IPv6 ND and DHCPv= 6 as a unified
stateless/stateful autoconfiguration service. Everything can be done in
a single message exchange (RS/RA with DHCPv6 option) instead of
requiring multiple message exchanges just for the sake of examining
the M/O bits.

Thanks - Fred

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

--001a114033604b009d056036b659-- From nobody Wed Dec 13 03:26: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 CB13B127A90; Wed, 13 Dec 2017 03:26:54 -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=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 ifMD_67PFNwY; Wed, 13 Dec 2017 03:26:52 -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 AB889127005; Wed, 13 Dec 2017 03:26:52 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 39694B4; Wed, 13 Dec 2017 12:26:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1513164410; bh=qbiiJ2KPdpc+Zmg8C+D3Rvxou9DbGKFANqvJDuNV7cs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=guh5NBitOQoD1JhwosmeQdONkr6PI7tfa8cOcDhxsN7/AHN8bE3AS0PJbV/jYyJLg NiKn2fKdtmcEw8y2lcDyZXadjrYMVSMoVGPuiUVKfAg7Y04n9rsBSCi4iMIHxU/jCm xofwtOu1fsg5dpEk8Gve7nyt/RybvkMIt95pEmg8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 371AEB1; Wed, 13 Dec 2017 12:26:50 +0100 (CET) Date: Wed, 13 Dec 2017 12:26:50 +0100 (CET) From: Mikael Abrahamsson To: Naveen Kottapalli cc: "v6ops@ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA In-Reply-To: Message-ID: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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: Wed, 13 Dec 2017 11:26:55 -0000 On Wed, 13 Dec 2017, Naveen Kottapalli wrote: > Yes, it would have been the better way. If clients aren't even > referring the 'M' bit, what is the use of carrying in RA? Some operating systems do, some don't. It's a hint. It's up to the implementor to decide what to do if the flag is set or not. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Dec 13 04:11: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 7BBF6124F57; Wed, 13 Dec 2017 04:11: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, 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 WLeqOzwZVCkO; Wed, 13 Dec 2017 04:11:46 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 A1059124BFA; Wed, 13 Dec 2017 04:11:45 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id f18so2355285lfg.8; Wed, 13 Dec 2017 04:11:45 -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=wbK9+yFa4I1xuuINEBSWhuEeG9Oi/oMr0g8Ndpvp8IM=; b=vMLmK9VVBLgSts0gxTpd3kqw1L2bKluYqsYbsmKwzbbQNewzdzxM/SY1Nn2p8pLrwi Yh3MbfENLAhP+PsqbBNZsHnW6ry6NPz7QlmNgrxl8DclglVDfI7Xz0zdGbnIxVaxboZa LpaSvaK8xza0hjtjAiuRS1l7WgWPS5JHaFcD0GiGrnJSWdTIdpCWuapHqPgwWORoQ0B6 X0wKSv4l4ZVl/v9rOvs7EghtcD5ZeqpvC+Dh+fB46OMKtimF/+fwKUhz9s0NisAiUpqr bZh0ZO4UW/1BlGWAtoaGzGgP8Wl3JlvLsGk6i9fRKJFlbINifUFsUiFQoQ+0eF+97ztu Wvrw== 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=wbK9+yFa4I1xuuINEBSWhuEeG9Oi/oMr0g8Ndpvp8IM=; b=il/4OlyRKonw24fqAkyER1qacpoRPD/C861KjUueysc+5b5FRlfkrehI1uAEF7RXi1 Me7DrMD25O1Hc6aIrgeLvBcoyWOgKe1540PlkgIWCt98XPltuHpt7aqKYrCi6SHCIK6+ 7NIYnWsn4KwIZkAhlEf/f6gwSJ26aL0DSUXMNFmfupiF+ENgN65d/XA+2TkX5Is7bRDF rWMIL51/MReziyc5eCzlk1wJyIYyt/OMZdfMzOEKEu7HmUr2Pu6IaTOh3+i5nXePvuxy ZMJ5MxanMEo/9WGR1kpHJj853MgJMf0crwTA00VBhDLd3zNkbafLswgRP0yULA+AVILa D+OA== X-Gm-Message-State: AKGB3mKBCbI07tyxXnH41dKWWmzEg4qmxhdalkYPg3/nEAgfQpsf7JvM zPNhcwNGbQzJKD+aJNlxYqbM6NdR8udCkWSNZfewIQ== X-Google-Smtp-Source: ACJfBosAjgC+kzsZN0tHWimrafIzJegZexLj1d+v4FSlCqE+GSWGHyp0EURV6W7/KC3vYD3gGZ2GtG0NPuaiMydSUqA= X-Received: by 10.25.167.143 with SMTP id q137mr1284770lfe.124.1513167103729; Wed, 13 Dec 2017 04:11:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Wed, 13 Dec 2017 04:11:23 -0800 (PST) In-Reply-To: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> From: Naveen Kottapalli Date: Wed, 13 Dec 2017 17:41:23 +0530 Message-ID: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA To: Mikael Abrahamsson Cc: "v6ops@ietf.org" , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a11410af6b4277a056037abcf" 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, 13 Dec 2017 12:11:47 -0000 --001a11410af6b4277a056037abcf Content-Type: text/plain; charset="UTF-8" I got that. But am not sure on what is the use when devices don't bother the value of that bit in RA. Yours, Naveen. On 13 December 2017 at 16:56, Mikael Abrahamsson wrote: > On Wed, 13 Dec 2017, Naveen Kottapalli wrote: > > Yes, it would have been the better way. If clients aren't even referring >> the 'M' bit, what is the use of carrying in RA? >> > > Some operating systems do, some don't. It's a hint. It's up to the > implementor to decide what to do if the flag is set or not. > > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > --001a11410af6b4277a056037abcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I got that.=C2=A0 But am not sure on what is the use when = devices don't bother the value of that bit in RA.

Yours,
Naveen.

On 13 December 2017 at 16:56, Mikael Abraham= sson <swmike@swm.pp.se> wrote:
On Wed, 13 Dec 2017, Naveen Kottapalli wrote:

Yes, it would have been the better way.=C2=A0 If clients aren't even re= ferring the 'M' bit, what is the use of carrying in RA?

 Some operating systems do, some don't. It's a hint. It's up to = the implementor to decide what to do if the flag is set or not.



--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

--001a11410af6b4277a056037abcf-- From nobody Wed Dec 13 04: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 2DDF7126CB6 for ; Wed, 13 Dec 2017 04:29:58 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 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 HOrnDpBwi0T8 for ; Wed, 13 Dec 2017 04:29:55 -0800 (PST) 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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC89126BF3 for ; Wed, 13 Dec 2017 04:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1513168193; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=tKTUdb95boJmG9EXZG9TnoLKpYCx3tvW13Dsfr2+izY=; b=foGrwH+rfW/09MGYUs6qeZ0nvIMarTuOh0Y4yal5x9Qb5j3LtZqUqjlIADVqpXJ89J228XxLA9I4QSRHe8nHV9fegplvUPSpLsfXGIX/GBz1n3yMoHM4aURXP3gNLcVLgXF4hB5AV0OAjRjxzrzkiqxG7tVYvZwu5unLf6orUKw= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0088.outbound.protection.outlook.com [94.245.120.88]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-133--ZJ-N3DNPbyMnsXgRmlwWw-1; Wed, 13 Dec 2017 12:29:48 +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_256_CBC_SHA384_P256) id 15.20.323.4; Wed, 13 Dec 2017 12:29:44 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::757e:c03:9cae:965f]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::757e:c03:9cae:965f%13]) with mapi id 15.20.0323.011; Wed, 13 Dec 2017 12:29:44 +0000 From: Tim Chown To: Naveen Kottapalli CC: Mikael Abrahamsson , "v6ops@ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Topic: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTc3gpBv+D1eZ2VUO2egLF+TEkW6NADVEAgAEPjYCAAAa7AIAADHKAgAAFUwA= Date: Wed, 13 Dec 2017 12:29:44 +0000 Message-ID: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.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.3273) x-originating-ip: [94.119.96.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 20:clgP9ObbhgyEI4iVV194Ygcrg/UlEAPOCv6X0XFVzSK6G6Rza3u5N/mqozRyfhYR2BPY7InW+9Bm9oFWjEUslRE9DzB+CB4A1Vr0Jd+J0Zg4HncauwY1ZlY987dsW/ad8QSAXgjYJbDvie62zaCNdhO409LWEL1KxBRAniuEUDk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ee36af26-9026-483a-5e52-08d5422530b8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:AM3PR07MB1140; x-ms-traffictypediagnostic: AM3PR07MB1140: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM3PR07MB1140; x-forefront-prvs: 052017CAF1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(252514010)(189003)(199004)(24454002)(7736002)(3846002)(54896002)(966005)(6512007)(72206003)(53936002)(57306001)(39060400002)(8676002)(25786009)(6306002)(68736007)(8936002)(6246003)(4326008)(50226002)(478600001)(66066001)(2900100001)(5250100002)(42882006)(2950100002)(229853002)(6916009)(6116002)(14454004)(102836003)(6486002)(36756003)(81166006)(81156014)(76176011)(236005)(93886005)(97736004)(3660700001)(83716003)(6436002)(106356001)(99286004)(105586002)(54906003)(316002)(786003)(82746002)(6506007)(74482002)(33656002)(5660300001)(2906002)(3280700002)(86362001)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: ee36af26-9026-483a-5e52-08d5422530b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2017 12:29:44.0936 (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: -ZJ-N3DNPbyMnsXgRmlwWw-1 Content-Type: multipart/alternative; boundary="_000_F2F313539641467081520DF1B184451Ejiscacuk_" 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, 13 Dec 2017 12:29:58 -0000 --_000_F2F313539641467081520DF1B184451Ejiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gMTMgRGVjIDIwMTcsIGF0IDEyOjExLCBOYXZlZW4gS290dGFwYWxsaSA8bmF2ZWVuLnNhcm1h QGdtYWlsLmNvbTxtYWlsdG86bmF2ZWVuLnNhcm1hQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJIGdv dCB0aGF0LiAgQnV0IGFtIG5vdCBzdXJlIG9uIHdoYXQgaXMgdGhlIHVzZSB3aGVuIGRldmljZXMg ZG9uJ3QgYm90aGVyIHRoZSB2YWx1ZSBvZiB0aGF0IGJpdCBpbiBSQS4NCg0KWW91IHdvdWxkbuKA mXQgYmVsaWV2ZSBob3cgbWFueSB0aG91c2FuZCBlbWFpbHMgaGF2ZSBkaXNjdXNzZWQgdGhpcyA6 KQ0KDQpBIOKAmGhpbnTigJkgd2FzIHRoZSBjb25zZW5zdXMuDQoNClRpbQ0KDQoNCllvdXJzLA0K TmF2ZWVuLg0KDQpPbiAxMyBEZWNlbWJlciAyMDE3IGF0IDE2OjU2LCBNaWthZWwgQWJyYWhhbXNz b24gPHN3bWlrZUBzd20ucHAuc2U8bWFpbHRvOnN3bWlrZUBzd20ucHAuc2U+PiB3cm90ZToNCk9u IFdlZCwgMTMgRGVjIDIwMTcsIE5hdmVlbiBLb3R0YXBhbGxpIHdyb3RlOg0KDQpZZXMsIGl0IHdv dWxkIGhhdmUgYmVlbiB0aGUgYmV0dGVyIHdheS4gIElmIGNsaWVudHMgYXJlbid0IGV2ZW4gcmVm ZXJyaW5nIHRoZSAnTScgYml0LCB3aGF0IGlzIHRoZSB1c2Ugb2YgY2FycnlpbmcgaW4gUkE/DQoN ClNvbWUgb3BlcmF0aW5nIHN5c3RlbXMgZG8sIHNvbWUgZG9uJ3QuIEl0J3MgYSBoaW50LiBJdCdz IHVwIHRvIHRoZSBpbXBsZW1lbnRvciB0byBkZWNpZGUgd2hhdCB0byBkbyBpZiB0aGUgZmxhZyBp cyBzZXQgb3Igbm90Lg0KDQoNCg0KLS0NCk1pa2FlbCBBYnJhaGFtc3NvbiAgICBlbWFpbDogc3dt aWtlQHN3bS5wcC5zZTxtYWlsdG86c3dtaWtlQHN3bS5wcC5zZT4NCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklF VEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86 aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== --_000_F2F313539641467081520DF1B184451Ejiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KT24gMTMgRGVjIDIwMTcsIGF0IDEy OjExLCBOYXZlZW4gS290dGFwYWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hdmVlbi5zYXJtYUBn bWFpbC5jb20iIGNsYXNzPSIiPm5hdmVlbi5zYXJtYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj5JIGdvdCB0aGF0LiZuYnNwOyBCdXQgYW0gbm90IHN1cmUgb24g d2hhdCBpcyB0aGUgdXNlIHdoZW4gZGV2aWNlcyBkb24ndCBib3RoZXIgdGhlIHZhbHVlIG9mIHRo YXQgYml0IGluIFJBLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KWW91IHdvdWxkbuKAmXQgYmVsaWV2ZSBob3cgbWFueSB0aG91c2FuZCBl bWFpbHMgaGF2ZSBkaXNjdXNzZWQgdGhpcyA6KSAmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2PkEg4oCYaGludOKAmSB3YXMgdGhlIGNvbnNlbnN1cy48L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRpbTwvZGl2Pg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsZWFyPSJhbGwiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSIgZGF0YS1zbWFydG1haWw9 ImdtYWlsX3NpZ25hdHVyZSI+WW91cnMsPGJyIGNsYXNzPSIiPg0KTmF2ZWVuLjwvZGl2Pg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gMTMgRGVjZW1i ZXIgMjAxNyBhdCAxNjo1NiwgTWlrYWVsIEFicmFoYW1zc29uIDxzcGFuIGRpcj0ibHRyIiBjbGFz cz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86c3dtaWtlQHN3bS5wcC5zZSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPnN3bWlrZUBzd20ucHAuc2U8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8 c3BhbiBjbGFzcz0iIj5PbiBXZWQsIDEzIERlYyAyMDE3LCBOYXZlZW4gS290dGFwYWxsaSB3cm90 ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NClllcywgaXQgd291bGQgaGF2ZSBiZWVuIHRoZSBiZXR0ZXIg d2F5LiZuYnNwOyBJZiBjbGllbnRzIGFyZW4ndCBldmVuIHJlZmVycmluZyB0aGUgJ00nIGJpdCwg d2hhdCBpcyB0aGUgdXNlIG9mIGNhcnJ5aW5nIGluIFJBPzxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvc3Bhbj5Tb21lIG9wZXJhdGluZyBzeXN0ZW1zIGRvLCBz b21lIGRvbid0LiBJdCdzIGEgaGludC4gSXQncyB1cCB0byB0aGUgaW1wbGVtZW50b3IgdG8gZGVj aWRlIHdoYXQgdG8gZG8gaWYgdGhlIGZsYWcgaXMgc2V0IG9yIG5vdC4NCjxkaXYgY2xhc3M9IkhP RW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KTWlrYWVsIEFicmFoYW1zc29uJm5ic3A7ICZu YnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOnN3bWlrZUBzd20ucHAuc2UiIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj4NCnN3bWlrZUBzd20ucHAuc2U8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiBjbGFzcz0i Ij5pcHY2QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3Rz OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8YnIgY2xhc3M9IiI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F2F313539641467081520DF1B184451Ejiscacuk_-- From nobody Wed Dec 13 07:24: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 15341126E7A; Wed, 13 Dec 2017 07:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 71_iJWycSl0v; Wed, 13 Dec 2017 07:24:26 -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 668E6126CF6; Wed, 13 Dec 2017 07:24:26 -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 vBDFOPti028352; Wed, 13 Dec 2017 08:24:26 -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 vBDFOJHx027930 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Dec 2017 08:24:19 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 13 Dec 2017 07:24:18 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Wed, 13 Dec 2017 07:24:18 -0800 From: "Templin, Fred L" To: Naveen Kottapalli CC: "v6ops@ietf.org" , "ipv6@ietf.org" Subject: RE: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Topic: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTc3ids/3rysN/2UOtzik0uog6BqNADGWAgAGWlID//8Bd4A== Date: Wed, 13 Dec 2017 15:24:18 +0000 Message-ID: <97a10ed486fd4f8993cfade81f90c8da@XCH15-06-08.nw.nos.boeing.com> References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.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.137.12.6] Content-Type: multipart/alternative; boundary="_000_97a10ed486fd4f8993cfade81f90c8daXCH150608nwnosboeingcom_" 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: Wed, 13 Dec 2017 15:24:29 -0000 --_000_97a10ed486fd4f8993cfade81f90c8daXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmF2ZWVuLA0KDQo+IFllcywgaXQgd291bGQgaGF2ZSBiZWVuIHRoZSBiZXR0ZXIgd2F5Lg0K DQpJdOKAmXMgbm90IHRvbyBsYXRlIHRvIHNldCB0aGluZ3MgcmlnaHQuIENvbWJpbmluZyBJUHY2 IE5EIHJvdXRlciBkaXNjb3ZlcnkNCmFuZCBESENQdjYgaW4gYSBzaW5nbGUsIHVuaWZpZWQgc2Vy dmljZSBjb21iaW5lcyB0aGUgYmVzdCBmZWF0dXJlcyBvZg0Kc3RhdGVsZXNzIGFuZCBzdGF0ZWZ1 bCBhdXRvY29uZmlndXJhdGlvbi4gQWxsIGl0IHRha2VzIGlzIGRlZmluaW5nIGEgbmV3DQpJUHY2 IE5EIG1lc3NhZ2Ugb3B0aW9uLg0KDQpQbHVzLCBpdCBpcyBiYWNrd2FyZHMgY29tcGF0aWJsZS4g SWYgdGhlIGhvc3Qgc2VuZHMgYW4gUlMgd2l0aCBhIERIQ1B2Ng0Kb3B0aW9uLCBhbmQgdGhlIHJv dXRlciBkb2VzIG5vdCByZWNvZ25pemUgdGhlIG9wdGlvbiwgdGhlIHJvdXRlciBzZW5kcw0KYmFj ayBhbiBSQSB3aXRoIG5vIERIQ1B2NiBvcHRpb24gYW5kIHRoZSBob3N0IGNhbiBrbm93IHRoYXQg aXQgbmVlZHMNCnRvIGRvIHRoaW5ncyB0aGUgb2xkIHdheSAoaS5lLiwgc2VuZCBESENQdjYgU29s aWNpdCBhZnRlciByZWNlaXZpbmcgdGhlIFJBKS4NCkluIHRoZSBvdGhlciBkaXJlY3Rpb24sIHRo ZSByb3V0ZXIgd2lsbCBuZXZlciBzZW5kIGFuIFJBIHdpdGggdGhlIERIQ1B2Ng0Kb3B0aW9uIGlu Y2x1ZGVkIHVubGVzcyB0aGUgaG9zdCBmaXJzdCBzZW50IGFuIFJTIHdpdGggREhDUHY2IG9wdGlv bi4NCg0KV2l0aCBhIGNvbWJpbmVkIGF1dG9jb25maWd1cmF0aW9uIHNlcnZpY2UgIGxpa2UgdGhp cywgdGhlIGFnZXMtb2xkIGRlYmF0ZQ0KYWJvdXQgU0xBQUMgdnMuIERIQ1B2NiBnb2VzIGF3YXks IGFuZCB3ZSB0cnVseSBnZXQgdGhlIGJlc3Qgb2YgYm90aA0Kd29ybGRzLg0KDQpUaGFua3MgLSBG cmVkDQoNCkZyb206IE5hdmVlbiBLb3R0YXBhbGxpIFttYWlsdG86bmF2ZWVuLnNhcm1hQGdtYWls LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTMsIDIwMTcgMzowMyBBTQ0KVG86IFRl bXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiB2Nm9wc0BpZXRm Lm9yZzsgaXB2NkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gV2luZG93cyAxMCBkb2Vz bid0IGhvbm91ciAnTScgZmxhZyBpbiBSQQ0KDQpZZXMsIGl0IHdvdWxkIGhhdmUgYmVlbiB0aGUg YmV0dGVyIHdheS4gIElmIGNsaWVudHMgYXJlbid0IGV2ZW4gcmVmZXJyaW5nIHRoZSAnTScgYml0 LCB3aGF0IGlzIHRoZSB1c2Ugb2YgY2FycnlpbmcgaW4gUkE/DQoNCllvdXJzLA0KTmF2ZWVuLg0K DQpPbiAxMyBEZWNlbWJlciAyMDE3IGF0IDAwOjIwLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90 ZToNClRoaXMgaXMgd2h5IGl0IHdvdWxkIGJlIGJldHRlciB0byBoYXZlIElQdjYgTkQgYW5kIERI Q1B2NiBhcyBhIHVuaWZpZWQNCnN0YXRlbGVzcy9zdGF0ZWZ1bCBhdXRvY29uZmlndXJhdGlvbiBz ZXJ2aWNlLiBFdmVyeXRoaW5nIGNhbiBiZSBkb25lIGluDQphIHNpbmdsZSBtZXNzYWdlIGV4Y2hh bmdlIChSUy9SQSB3aXRoIERIQ1B2NiBvcHRpb24pIGluc3RlYWQgb2YNCnJlcXVpcmluZyBtdWx0 aXBsZSBtZXNzYWdlIGV4Y2hhbmdlcyBqdXN0IGZvciB0aGUgc2FrZSBvZiBleGFtaW5pbmcNCnRo ZSBNL08gYml0cy4NCg0KVGhhbmtzIC0gRnJlZA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYu b3JnPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K --_000_97a10ed486fd4f8993cfade81f90c8daXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIE5hdmVlbiw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+IFllcywgaXQgd291bGQgaGF2 ZSBiZWVuIHRoZSBiZXR0ZXIgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SXTigJlzIG5vdCB0b28gbGF0ZSB0byBzZXQgdGhpbmdzIHJp Z2h0LiBDb21iaW5pbmcgSVB2NiBORCByb3V0ZXIgZGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmFuZCBESENQdjYgaW4gYSBzaW5nbGUsIHVuaWZpZWQgc2VydmljZSBjb21iaW5lcyB0aGUgYmVz dCBmZWF0dXJlcyBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zdGF0ZWxlc3MgYW5kIHN0YXRlZnVsIGF1 dG9jb25maWd1cmF0aW9uLiBBbGwgaXQgdGFrZXMgaXMgZGVmaW5pbmcgYSBuZXc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SVB2NiBORCBtZXNzYWdlIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlBsdXMsIGl0IGlzIGJhY2t3YXJkcyBjb21wYXRpYmxlLiBJZiB0 aGUgaG9zdCBzZW5kcyBhbiBSUyB3aXRoIGEgREhDUHY2PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm9wdGlv biwgYW5kIHRoZSByb3V0ZXIgZG9lcyBub3QgcmVjb2duaXplIHRoZSBvcHRpb24sIHRoZSByb3V0 ZXIgc2VuZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YmFjayBhbiBSQSB3aXRoIG5vIERIQ1B2NiBvcHRp b24gYW5kIHRoZSBob3N0IGNhbiBrbm93IHRoYXQgaXQgbmVlZHM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ dG8gZG8gdGhpbmdzIHRoZSBvbGQgd2F5IChpLmUuLCBzZW5kIERIQ1B2NiBTb2xpY2l0IGFmdGVy IHJlY2VpdmluZyB0aGUgUkEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiB0aGUgb3RoZXIgZGlyZWN0 aW9uLCB0aGUgcm91dGVyIHdpbGwgbmV2ZXIgc2VuZCBhbiBSQSB3aXRoIHRoZSBESENQdjY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+b3B0aW9uIGluY2x1ZGVkIHVubGVzcyB0aGUgaG9zdCBmaXJzdCBzZW50 IGFuIFJTIHdpdGggREhDUHY2IG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPldpdGggYSBjb21iaW5lZCBhdXRvY29uZmlndXJhdGlvbiBzZXJ2aWNlICZu YnNwO2xpa2UgdGhpcywgdGhlIGFnZXMtb2xkIGRlYmF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hYm91 dCBTTEFBQyB2cy4gREhDUHY2IGdvZXMgYXdheSwgYW5kIHdlIHRydWx5IGdldCB0aGUgYmVzdCBv ZiBib3RoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPndvcmxkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBOYXZlZW4gS290dGFw YWxsaSBbbWFpbHRvOm5hdmVlbi5zYXJtYUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBEZWNlbWJlciAxMywgMjAxNyAzOjAzIEFNPGJyPg0KPGI+VG86PC9iPiBUZW1w bGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiB2Nm9wc0BpZXRmLm9yZzsgaXB2NkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3Y2b3BzXSBXaW5kb3dzIDEwIGRvZXNuJ3QgaG9ub3VyICdNJyBmbGFnIGluIFJBPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgaXQg d291bGQgaGF2ZSBiZWVuIHRoZSBiZXR0ZXIgd2F5LiZuYnNwOyBJZiBjbGllbnRzIGFyZW4ndCBl dmVuIHJlZmVycmluZyB0aGUgJ00nIGJpdCwgd2hhdCBpcyB0aGUgdXNlIG9mIGNhcnJ5aW5nIGlu IFJBPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPllvdXJzLDxicj4NCk5hdmVlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMyBEZWNlbWJlciAyMDE3IGF0IDAwOjIwLCBUZW1w bGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t IiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg aXMgd2h5IGl0IHdvdWxkIGJlIGJldHRlciB0byBoYXZlIElQdjYgTkQgYW5kIERIQ1B2NiBhcyBh IHVuaWZpZWQ8YnI+DQpzdGF0ZWxlc3Mvc3RhdGVmdWwgYXV0b2NvbmZpZ3VyYXRpb24gc2Vydmlj ZS4gRXZlcnl0aGluZyBjYW4gYmUgZG9uZSBpbjxicj4NCmEgc2luZ2xlIG1lc3NhZ2UgZXhjaGFu Z2UgKFJTL1JBIHdpdGggREhDUHY2IG9wdGlvbikgaW5zdGVhZCBvZjxicj4NCnJlcXVpcmluZyBt dWx0aXBsZSBtZXNzYWdlIGV4Y2hhbmdlcyBqdXN0IGZvciB0aGUgc2FrZSBvZiBleGFtaW5pbmc8 YnI+DQp0aGUgTS9PIGJpdHMuPGJyPg0KPGJyPg0KVGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzppcHY2QGlldGYub3JnIj5pcHY2QGlldGYub3JnPC9hPjxicj4NCkFkbWluaXN0cmF0aXZl IFJlcXVlc3RzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwdjYiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXB2NjwvYT48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_97a10ed486fd4f8993cfade81f90c8daXCH150608nwnosboeingcom_-- From nobody Wed Dec 13 08:03: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 1DA40126C0F for ; Wed, 13 Dec 2017 08:03:46 -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, 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=fugue-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 x2tQyoYMsdvs for ; Wed, 13 Dec 2017 08:03:44 -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 2537612783A for ; Wed, 13 Dec 2017 08:03:44 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id 63so2550335qke.0 for ; Wed, 13 Dec 2017 08:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pERvFuLpBW3Wk6DO7TxdQYSjbs1MR0yJwwkM0x3wOsk=; b=bW38XI0r+5EEMrsuSbzqaZE7aKBEJhfRZFuIi9X+dPhj9zK/rjPL/FZuAHhkHvDtbg QNcKmd0mvn6ugM+Iz3NPJWilzHNDVrnIVEcUOe/d+cEDSDBo0Rx4KhTijNGEJkykuT9i X/aH9tHv8Z5y+jV1mNwwY+VBvbTC/uzDQq6PLUyIqgEtcsAALutfteMDPsDx+W/aaQVd 2L0eaMH8GgQKdLzVSVCwD0Xs9xpnjvlSTrVz9Akx1He8Qrl/lNKYXdF1Lqlz+ueGPKqU 6MCTmnn73aToK06Ej4Lpm82CUATZlNFRq3nt4/4lY7Qvv/GLBI0xFfRW3ur0l4NEOBYj gGqw== 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=pERvFuLpBW3Wk6DO7TxdQYSjbs1MR0yJwwkM0x3wOsk=; b=mbVTjbcpy/DjUC2v0SotnMB9VHyKqJLRwTQsDz2V89bNnVq6L+raQ0iOAFihMZLB7B UFz/AQ3SN8ryf9vjE9vzszX9HFebl3okQZe0Ge1EJiHAI79LRj579epDpzMf0XHEtcor lF+1Q5qdLXiD6FGYfpEZfzb5lpsBDrOaGs/ncz9qII6K9G+hx3P4Elvgtdh82sCnPO3x mjA1wwgog+NOwEXMfIJSOXqTPo8eTehgbH4q3tpK0Ry7xydq6ZYjBWeEWyQaLhJTwmgK goSyZZVC4pT6wL+3Xyj8YRKpVL2qOu6EMKZmUHI6b/d/D1oBm7Kl6XpsbVMUGAVvohIb Wprw== X-Gm-Message-State: AKGB3mJmIP2fVd81BSa/u2nkIwPhckjkatHzCLjC7G3ljPISZSMYRBOf QZ3jK8TQPiUX5qlvsIvuJnspGw== X-Google-Smtp-Source: ACJfBouaiTTAR8huiWuzq9jHyvTeEkRO2cEUu8WOyFiD9MNYnCF0SIht0dd2T0QCIUImTqafAdk3uw== X-Received: by 10.55.76.209 with SMTP id z200mr11291750qka.183.1513181023198; Wed, 13 Dec 2017 08:03:43 -0800 (PST) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id f5sm1264761qte.87.2017.12.13.08.03.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 08:03:41 -0800 (PST) From: Ted Lemon Message-Id: <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7459FA05-3802-4EC1-8F54-A91C47B1A452" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA Date: Wed, 13 Dec 2017 11:03:39 -0500 In-Reply-To: Cc: Naveen Kottapalli , "v6ops@ietf.org" , "ipv6@ietf.org" To: Tim Chown References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3445.5.20) 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, 13 Dec 2017 16:03:46 -0000 --Apple-Mail=_7459FA05-3802-4EC1-8F54-A91C47B1A452 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 13, 2017, at 7:29 AM, Tim Chown wrote: > A =E2=80=98hint=E2=80=99 was the consensus. A 'hint' was the vote. I don't believe that it was a consensus. As = Naveen points out, the current solution is technically invalid. It = would be better not to have the 'M' bit than to have it be a hint. --Apple-Mail=_7459FA05-3802-4EC1-8F54-A91C47B1A452 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 13, 2017, at 7:29 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
A = =E2=80=98hint=E2=80=99 was the consensus.

A 'hint' was the vote.   I don't believe that = it was a consensus.   As Naveen points out, the current solution is = technically invalid.   It would be better not to have the 'M' bit = than to have it be a hint.


= --Apple-Mail=_7459FA05-3802-4EC1-8F54-A91C47B1A452-- From nobody Wed Dec 13 08: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 8D0B4127077; Wed, 13 Dec 2017 08:45: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, 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 z6lLVZhOPCVy; Wed, 13 Dec 2017 08:45:53 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 824C1126D0C; Wed, 13 Dec 2017 08:45:53 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id 64so6369596wme.3; Wed, 13 Dec 2017 08:45:53 -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=zBbl1NwMWzear1xG0mC3Sza2wSECM0KOrUOuBCwKTXo=; b=RcDClaBgLfLhyF0hVxBQwg6qIepONHzTvyLYl2BNjPswUxmAmwftJ6vsV8MHOfH7ok 8g6GIWiGj/9c+/tIn3Q/raJdPSrGsMG8L0l3Fbe/qCETwbMywySDOzIwamAvGpGGFkSN hkaX7vrfI+lFFbPjf4oFWZO2E7L8PslbUn6UtAmRRR5OVSYxvdYiPgMwoVBbV0JK/4tW gcg1+6qOwVB0K62AQohAj3vbnDLhPH5yu7RIc7vurXsBoRzyQuScxIzqLYRLNYOj7j7s FrR3gKmG3Xo6ZMPuypXqxoNduE5hoKAWNn8GXP0hL+shPfkPGQ6TjeYQqB8SRYyLV+05 ArEw== 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=zBbl1NwMWzear1xG0mC3Sza2wSECM0KOrUOuBCwKTXo=; b=iX/mxIyYjD0WUuPOLsC7wG8GfBOAtteMcO/k+zlVZB1yPNUDWiENO6xNR7AgF/Cuho /xGz4Zjc7UXYxM2WnUSyiN4wVYG7ShY94xB0W+Oj3uwunLBDItt8qYo5KSDxmRdoKJR6 3ihJ80TkoxDfS0VE6V3Zb06deD+rBp4qI1gz2dgCslA4g+NZRkKv0dkD00pd1yCjRSGM 4ucUk0T3Gd7RAezrQqQZF+4a1EaJ+AQfMEsSfpxkTRgB3l7LDCTgVkpjk21phpUfAazZ r0GXXeZORJCr9JMSXmx7rrCW5HPX31jmN8ACR4xeEdaJHK3ufxvkJmsePnhYZQUFOjjH bBfA== X-Gm-Message-State: AKGB3mIk58GQIwDCbUIldMFVM+bXQ2CA1LbfF1pZOV6Lb7LhL4T1jHk5 p5r9YnLMDKQzCasg+3fScHs= X-Google-Smtp-Source: ACJfBovXBg5M48EvTomUa91wagvIDsu9vyeiLUjlB/sYN73z6YdCpV6e/FQ3FP7GGqAzcnTbFy84HA== X-Received: by 10.28.26.139 with SMTP id a133mr2458931wma.90.1513183551972; Wed, 13 Dec 2017 08:45:51 -0800 (PST) Received: from ?IPv6:2601:647:4d01:db10:90c2:513b:e253:d64f? ([2601:647:4d01:db10:90c2:513b:e253:d64f]) by smtp.gmail.com with ESMTPSA id j13sm2269640wre.55.2017.12.13.08.45.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 08:45:51 -0800 (PST) From: Bob Hinden Message-Id: <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C0F48051-A8CD-4208-97DD-296856C70214"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA Date: Wed, 13 Dec 2017 08:45:46 -0800 In-Reply-To: <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> Cc: Bob Hinden , Tim Chown , "v6ops@ietf.org" , IPv6 List To: Ted Lemon References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.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: Wed, 13 Dec 2017 16:45:55 -0000 --Apple-Mail=_C0F48051-A8CD-4208-97DD-296856C70214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ted, The actual text from Section 4.2. "Router Advertisement Message = Format=E2=80=9D in RFC4861 is: M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information. O 1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network. Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6. I think the protocol specification is clear. Bob > On Dec 13, 2017, at 8:03 AM, Ted Lemon wrote: >=20 > On Dec 13, 2017, at 7:29 AM, Tim Chown wrote: >> A =E2=80=98hint=E2=80=99 was the consensus. >=20 > A 'hint' was the vote. I don't believe that it was a consensus. As = Naveen points out, the current solution is technically invalid. It = would be better not to have the 'M' bit than to have it be a hint. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_C0F48051-A8CD-4208-97DD-296856C70214 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 iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloxWToACgkQrut0EXfn u6hcNgf+J62GtXZWFlswU45x4g+QAjmSCJTT8CZCGUxpQkDf2JLraiLdJ3gU/gry /BAJgeOZOnODQO19J57KPPvucrqpFeTZSU2GhaWiGX2Musjh5vSTWyB3ittQEjL2 ut86ExXZth89dxuRk6YVFwuaZ2DLpuX8RwdR8wXm4XgDD8nT+DV/kkUVTItFRCIq 0/FHImOPkKIFMqtxLFyxTEqXlMlt04i2XNqmddM2RvlhxhH8KH/rPRmd5szMGUpD KH1D1fEH97vDV4S03LKEEgl0zZQuxpYkmVfgtMJsT/HV/j7Tan5YvNRC2NtMhQ5X fzoXE7S1nP4d+zG85h+FzzTL2MCr9Q== =6rey -----END PGP SIGNATURE----- --Apple-Mail=_C0F48051-A8CD-4208-97DD-296856C70214-- From nobody Wed Dec 13 09:16: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 4FFFA1270FC; Wed, 13 Dec 2017 09:16:16 -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 eGxiB_DDCBEd; Wed, 13 Dec 2017 09:16:14 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 541A612706D; Wed, 13 Dec 2017 09:16:14 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id 74so3532109lfs.0; Wed, 13 Dec 2017 09:16:14 -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=bsinnr+IWesqa8ngIVnJrYgT8LAZcSNegS03WfHJYqM=; b=dnzuxVcywtXnuDF+e2iNV0CuMN7kC4k8UavOLs/HX3eK1TR4Jxahe15yYCb1wuAYFI pvZX3z8rM6RQ+qd+8P+VJBSi8BD17ZIfMZHke/apItIy/d5wgfM9lGPTAMoiLnQbEfAn rSdT1YvcUgdOz2SHJ/MHxD01rO0WT61lzLcrSneG+t0/oTOBHOeS3qyTVT2RyyqbDGyH fwf4sfe2tmN+RTe/O8nULjfJwjObZedWSh0b+rddZCNbwEO6sd3cQWTnIJjLkLnhweCh oiDt2dRLHc8fClmkJlrvXYPdbR6MQQGKuhg1NbCRFBCU0zU+gIIifI0BE789mlrElffH atJw== 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=bsinnr+IWesqa8ngIVnJrYgT8LAZcSNegS03WfHJYqM=; b=gfaWvoF0iSKKK5CZFgwzxjYchfnBkBF3+ZGSqW4ni1Xppvx8mwaDTgEh2XaRdmCXeU r3KV6Jht56CGhxzRV/JhQzdqwuhpa2+oLU8F0OGj8ovCeR/RQedyyCZ+v0M/JZqoTlLa LTduyzb9gRjXzO+d7vKDIbq0/48nFJosYKcS+qLiemn8RZymSB65l2NyRRTihmEL0WED zJwhRR6qBgLgO21caf2iHw8e+lpI2LfFdoum5d+NIdnHkRmgV3WZNlBRXPGwjPrBYUCC nj+VB3DaZkN/21O2upFlqwaiAZfnITAQS22UT91sitX/ZOsy0IVhlsZs623eRU1JC02M 4Htg== X-Gm-Message-State: AKGB3mJzB1iabyi9Ys7rUysb0oY/TsMr5eCjGB+l/hLSGRhv0cTS2WsH zrck+K380jesF8T5b1Fuok5M+cyvhoZUvht9z0k= X-Google-Smtp-Source: ACJfBou7vNPeX1kutEa0lZPjhyKA0Mz1eL05EfMrx9Unl1/FgWJIxKr5x+mQ0bBZDya/4kYcuusyoiZ5TrPJBDYNpFM= X-Received: by 10.25.163.17 with SMTP id m17mr2050738lfe.88.1513185372562; Wed, 13 Dec 2017 09:16:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Wed, 13 Dec 2017 09:15:51 -0800 (PST) In-Reply-To: <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> From: Naveen Kottapalli Date: Wed, 13 Dec 2017 22:45:51 +0530 Message-ID: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA To: Bob Hinden Cc: Ted Lemon , IPv6 List , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114033609c6aeb05603bec9b" 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, 13 Dec 2017 17:16:16 -0000 --001a114033609c6aeb05603bec9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Response inline. Yours, Naveen. On 13 December 2017 at 22:15, Bob Hinden wrote: > Ted, > > The actual text from Section 4.2. "Router Advertisement Message Format=E2= =80=9D in > RFC4861 is: > > M 1-bit "Managed address configuration" flag. When > set, it indicates that addresses are available via > Dynamic Host Configuration Protocol [DHCPv6]. > > Naveen] This statement isn't saying that 'M' bit SHOULD / SHALL be referred to learn or get the addresses via DHCPv6. This is where the point is. If the M flag is set, the O flag is redundant and > can be ignored because DHCPv6 will return all > available configuration information. > > O 1-bit "Other configuration" flag. When set, it > indicates that other configuration information is > available via DHCPv6. Examples of such information > are DNS-related information or information on other > servers within the network. > > Note: If neither M nor O flags are set, this indicates that no > information is available via DHCPv6. > > I think the protocol specification is clear. > > Bob > > > > > > On Dec 13, 2017, at 8:03 AM, Ted Lemon wrote: > > > > On Dec 13, 2017, at 7:29 AM, Tim Chown wrote: > >> A =E2=80=98hint=E2=80=99 was the consensus. > > > > A 'hint' was the vote. I don't believe that it was a consensus. As > Naveen points out, the current solution is technically invalid. It woul= d > be better not to have the 'M' bit than to have it be a hint. > > > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > > --001a114033609c6aeb05603bec9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Response inline.

Yours,
Naveen.

On 13 December 2017 at 22:15, Bob Hinden <bob.hinden@gmail.com> wrote:
Ted,

The actual text from Section 4.2. "Router Advertisement Message Format= =E2=80=9D in RFC4861 is:

=C2=A0 =C2=A0 =C2=A0 M=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1-bi= t "Managed address configuration" flag.=C2=A0 When
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0set, it indicates that addresses are available via
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Dynamic Host Configuration Protocol [DHCPv6].

Naveen] This statement isn't saying that &= #39;M' bit SHOULD / SHALL be referred to learn or get the addresses via= DHCPv6.=C2=A0 This is where the point is.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0If the M flag is set, the O flag is redundant and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0can be ignored because DHCPv6 will return all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0available configuration information.

=C2=A0 =C2=A0 =C2=A0 O=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1-bi= t "Other configuration" flag.=C2=A0 When set, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0indicates that other configuration information is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0available via DHCPv6.=C2=A0 Examples of such information
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0are DNS-related information or information on other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0servers within the network.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Note: If neither M nor O flags are set, this in= dicates that no
=C2=A0 =C2=A0 =C2=A0 =C2=A0 information is available via DHCPv6.

I think the protocol specification is clear.

Bob




> On Dec 13, 2017, at 8:03 AM, Ted Lemon <mellon@fugue.com> wrote:
>
> On Dec 13, 2017, at 7:29 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>> A =E2=80=98hint=E2=80=99 was the consensus.
>
> A 'hint' was the vote.=C2=A0 =C2=A0I don't believe that it= was a consensus.=C2=A0 =C2=A0As Naveen points out, the current solution is= technically invalid.=C2=A0 =C2=A0It would be better not to have the 'M= ' bit than to have it be a hint.
>
>
> ------------------= --------------------------------------------------
> 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
-----------------------------------------------------------------= ---


--001a114033609c6aeb05603bec9b-- From nobody Wed Dec 13 10:49: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 6260612704B; Wed, 13 Dec 2017 10:49:30 -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 54zyrGR2iP01; Wed, 13 Dec 2017 10:49:28 -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 4D451126E01; Wed, 13 Dec 2017 10:49:28 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id j9so1620623pgc.11; Wed, 13 Dec 2017 10:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6nWpVLjd8z7nlJHXrnjMk8EQaFImOsI7XOtHtC84kts=; b=IvYRn+36YcjUnTppb0Cg+cyN2ZQ1KG2M5Qr+A4HURKDWUwdc1lAyDCErFUv1HE9FS9 SDvxfzec1c0/TmMVasSS+kXKJvz+I5q3aqfBnVoKOQua/QpZ6AQLN1ubBw/QjpH71XxU BbXxhs7RErRYaMdYdhd+CN8T+0fja6eV1VQOE913MLTJrkfmD/qDsQ7fu+7QxXBPEPgd tyrCuWSz/bxCgziP6MmPG4hOLuYA7qHVUvYY781rgEde82oUnfJVzccECWIv0viiffDd MFhntQ/AiKDzXhsbeWxqhXCc5RgmLOJPO5pyoL72rL9BfShDyJ8pGcoHiHCmlm/eICa/ emGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6nWpVLjd8z7nlJHXrnjMk8EQaFImOsI7XOtHtC84kts=; b=lEklZ7jsxqf7pb7i9RJWdP8a+2WfQBaaF2AUlOsCJbrYCl/fUmu2YXWit6Ml8pCrly piP8YVE2GcOOcVZgcB1vlhb9UeiMHhLrAXTPBNkgwdUztPNnL1c5V+MidPuo7im2oXBf Ti+B5tmEsId6kJGH/cYppZCGzM5VrKlYXAtT+viv7DjSBsVFkXETyPGvET7vOU7ZcT95 //TOos99Jf8BAPcWOFHuZ/I/P3vwX04OcKqEcxhLK8sfx3utmr4nVcysNhu2fNz0096e 13EHbQceKIdwKEE4xgk1jbgaBCkpiW+QGt3v0iSG0oLCBlsDG9XeSOwUTJJZ1hulAf+n aYTw== X-Gm-Message-State: AKGB3mL2wCY/RgA2Oh2+yzdkjdsS/Z0yEE0KcNin5r3eiNcn0930UZiz PFO8aYcN+Mr2tIA3eykWqrU= X-Google-Smtp-Source: ACJfBov46Qp7FqORp4iskYiT9ExCrE4WVxjLJeBpqh9fdmtPtfn4bBvBONir/DKKQIkAxdXCU3P2Ug== X-Received: by 10.84.204.8 with SMTP id a8mr6766060ple.399.1513190967573; Wed, 13 Dec 2017 10:49:27 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s11sm3969393pgn.80.2017.12.13.10.49.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 10:49:26 -0800 (PST) Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA To: Naveen Kottapalli , Bob Hinden Cc: IPv6 List , "v6ops@ietf.org" , Ted Lemon References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 14 Dec 2017 07:49:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 13 Dec 2017 18:49:30 -0000 On 14/12/2017 06:15, Naveen Kottapalli wrote: > Response inline. >=20 > Yours, > Naveen. >=20 > On 13 December 2017 at 22:15, Bob Hinden wrote: >=20 >> Ted, >> >> The actual text from Section 4.2. "Router Advertisement Message Format= =E2=80=9D in >> RFC4861 is: >> >> M 1-bit "Managed address configuration" flag. When= >> set, it indicates that addresses are available vi= a >> Dynamic Host Configuration Protocol [DHCPv6]. >> >>=20 > [Naveen] This statement isn't saying that 'M' bit SHOULD / SHALL be > referred to learn or get the addresses via DHCPv6. This is where the p= oint > is. See below for why this cannot be a requirement. > If the M flag is set, the O flag is redundant and >> can be ignored because DHCPv6 will return all >> available configuration information. >> >> O 1-bit "Other configuration" flag. When set, it >> indicates that other configuration information is= >> available via DHCPv6. Examples of such informati= on >> are DNS-related information or information on oth= er >> servers within the network. >> >> Note: If neither M nor O flags are set, this indicates that no= >> information is available via DHCPv6. >> >> I think the protocol specification is clear. Well, the "Note:" does leave an open question. How does the person (or automaton) configuring the router that sends the RA know that no information is available via DHCPv6? It is entirely possible that DHCPv6 is available on another box, and the person configuring the the router doesn't know it. So these flags are intrinsically unreliable and can only be hints; it's *necessary* that hosts are allowed to ignore them and look for DHCPv6 anyway. [BTW I came to this realisation after drafting the text in https://tools.ietf.org/html/draft-hinden-ipv4flag-01#section-4. The logic of the situation is quite similar.] Brian From nobody Wed Dec 13 11:32: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 4B7C61275F4; Wed, 13 Dec 2017 11:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4ENh10C-2KUU; Wed, 13 Dec 2017 11:32:31 -0800 (PST) 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 5FA07124F57; Wed, 13 Dec 2017 11:32:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5434820090; Wed, 13 Dec 2017 14:35:49 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 164DE814AD; Wed, 13 Dec 2017 14:32:30 -0500 (EST) From: Michael Richardson To: "v6ops\@ietf.org" , IPv6 List Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA In-Reply-To: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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: Wed, 13 Dec 2017 19:32:33 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >>> O 1-bit "Other configuration" flag. When set, it >>> indicates that other configuration information is >>> available via DHCPv6. Examples of such information >>> are DNS-related information or information on other >>> servers within the network. > Well, the "Note:" does leave an open question. How does the person (or > automaton) configuring the router that sends the RA know that no > information is available via DHCPv6? It is entirely possible that > DHCPv6 is available on another box, and the person configuring the > the router doesn't know it. So these flags are intrinsically unreliable > and can only be hints; it's *necessary* that hosts are allowed to > ignore them and look for DHCPv6 anyway. So, maybe what we should be writing is: O 1-bit "Other configuration" flag. When clear it indicates that this router believes that it has all available/valid configuration information. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloxgE0ACgkQgItw+93Q 3WWaTwgAiLUm76e6KmPdxrY1KBOy19jziipePOpmUhPVf7pqagRlKbWDZI85wJBt u11pNT4sQb2alsqusx967xAC5uyG41OWsbbuabjt7rsp/cCl/NLsZqglhPequak8 nWGxvpEhgf8aDIbyuVTmUlkOAyaLtW4MPVizfzllAkQwGE3NylbCzU+ACFoRETVb qYTnW0HLc7BgoaNWrP+oEEZx0ZniOhF0cr2V81TUqliYGhLbk3G+L8b1emhsDjd1 nS/J/Enx3SIA8nFWi7Gs9KzjhB3UP5gEjS8Lleydvz1GuyP7ap2DYHNGZuf/Xkkt w8itgW2dOjgwGIGxw/OmcZIwYM/Ulw== =6U3v -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 13 11:35: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 6C3651275F4; Wed, 13 Dec 2017 11:35:46 -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 ijbxMTFQ-0jX; Wed, 13 Dec 2017 11:35:44 -0800 (PST) Received: from patsy.thehobsons.co.uk (ruthandcrusoe.plus.com [81.174.150.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CFE127058; Wed, 13 Dec 2017 11:35:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.lan (unknown [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 063021BC37; Wed, 13 Dec 2017 19:35:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA From: Simon Hobson In-Reply-To: Date: Wed, 13 Dec 2017 19:34:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> To: "v6ops@ietf.org list" , IPv6 List 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: Wed, 13 Dec 2017 19:35:46 -0000 Brian E Carpenter wrote: > Well, the "Note:" does leave an open question. How does the person (or > automaton) configuring the router that sends the RA know that no > information is available via DHCPv6? It is entirely possible that > DHCPv6 is available on another box, and the person configuring the > the router doesn't know it. So these flags are intrinsically = unreliable > and can only be hints; it's *necessary* that hosts are allowed to > ignore them and look for DHCPv6 anyway. I keep hearing this argument time and time again, but cannot reconcile = it with any professionally managed network. Are there really = professionally managed networks where the guys responsible for the = routers (intrinsically tied in with the network config) don't talk to = the guys running DHCP servers (intrinsically tied in with the network = config) ? Put another way, are there really networks where two different groups = "do their own thing" without agreeing between themselves how the network = is supposed to work ? From nobody Wed Dec 13 11:39: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 D6F07127058 for ; Wed, 13 Dec 2017 11:39:25 -0800 (PST) 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 456biKiqqjRr for ; Wed, 13 Dec 2017 11:39:23 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 7F054126FDC for ; Wed, 13 Dec 2017 11:39:23 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id l187so2137863vke.5 for ; Wed, 13 Dec 2017 11:39:23 -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=4ArZJlveoXJJeMx3YOQKi+xI0Rpo5ko6a9YzXHl1bLA=; b=DvhWee1ysIVVB+TUXc/tARoXUWY9fUEgoo9JG/PlQNgqeiJPB7Vd00htBXmTG9pkH3 TYnaN6OzngtvgWGr2PJR4kh7ItttpN5PVKlPZbCSSb6yYoATzWIQyXJPmy+pYfoeV2lf TFAHVoOR3j8VhxGDy9iBmsw8V0q1nIJF0EJDhud4GAvRMQBzi6mwk2KkzkcJaokYRY1p g2zrWzj+NbhwnkmOZUIe2gTJewN2ICy/mlXLBKu413KfRcz6k7PmtcsQ6FYd43RmV9n+ Aku9P3/gdIaZXKt6AZpEGKtm0jLSch6pTqgXge0QzUoyVaFCGAZ24xlEgT+cqulYbVaR 2Bng== 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=4ArZJlveoXJJeMx3YOQKi+xI0Rpo5ko6a9YzXHl1bLA=; b=RbZDKN43Lfs8S68FG12+4u8D6Dk1ivvSJspI5RwBZiD39ujEjUF3Jae3MCYlbilv9+ tMZeKmtNp8o5NIxQxYLh/nFGLv8atxLsOdB34MefbPblQxW10RVHd0O4xx6EDpc+bDlu CtXLRHX8hw2tJrdRmRQi1jafIEDcx51ZQEaNCEH9pPpJgGXSv04s8sBaG3xnhQIhPWcn Zf0X/XGH/Xvpo2prk3VmdSgRJVptyHnQQZJ+TP+FQzaypWmiaaMYPOldL3RHLH/4ZvxJ 0yXKXqhHvVOMZdPl3pZJA4dM5vqO4AaJSvnwFyjzFQCvbtEZU2Fei2UUbaMACth0cKyG XuHQ== X-Gm-Message-State: AKGB3mLEh2ELKcQtBZ/+awZpPJpNLy2wTCOS+L+j6r2w0HU3B9ujdcoR PD7oY9JBoKuF6cYXs3RTjF/7EoRsyb1bIZtfVdw= X-Google-Smtp-Source: ACJfBotu03ypIB4hlAerLYvEGlNbirUp8loqIZmkvSAYOz239WBJZhhxtbvkHZVyWMxPz/cHOOrB0RoiFZtLfSPF1o8= X-Received: by 10.31.135.197 with SMTP id j188mr8465908vkd.34.1513193962352; Wed, 13 Dec 2017 11:39:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.56.218 with HTTP; Wed, 13 Dec 2017 11:38:51 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> <1cf221bc-e2e3-bc04-6559-d01eff2e1232@gmail.com> From: Mark Smith Date: Thu, 14 Dec 2017 06:38:51 +1100 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Tom Herbert Cc: Bob Hinden , 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, 13 Dec 2017 19:39:26 -0000 Hi Tom, Sorry not to get back to you sooner. On 7 December 2017 at 08:32, Tom Herbert wrote: > On Wed, Dec 6, 2017 at 11:52 AM, Mark Smith wrote: >> Hi Tom, >> >> On 6 December 2017 at 07:24, Tom Herbert wrote: >>> On Tue, Dec 5, 2017 at 11:59 AM, Mark Smith wrote: >>>> On 5 December 2017 at 08:28, Bob Hinden wrote: >>>>> >>>>>> On Dec 2, 2017, at 2:15 PM, Brian E Carpenter wrote: >>>>>> >>>>>> On 03/12/2017 08:53, Robert Raszuk wrote: >>>>>>>> >> >> >> >>>>> >>>>> I will add that swapping flow labels as I think Tom Herbert was proposing has much less side effects than inserting and processing extension headers. >>>> >>>> Which would then violate the Flow Label spec unless the Flow Label >>>> value is zero. >>>> >>> Mark, >>> >> I can think of a number of ways that SR segments can be identified >> that would be compatible with IPv6 forwarding that would reduce the >> size of the SRH EH >> >> - as suggested before, unique /64 per device, with the /64 carried in >> the SRH TLV, reducing the TLV size by 8 octets. >> >> - well known or locally selected single /64 for the SR function, then >> unique 64 bit IID per device, with the 64 bit IID carried in the SRH >> TLV, reducing the TLV size by 8 octets. This could be automatically >> generated via a PRNG. It would be safer to check for collisions, >> although probably not necessary. >> >> - well known or locally selected single /64 for the SR function, >> segment IDs 20 bits to match SR-MPLS IDs, 20 bits carred in the SRH >> TLV, reducing the TLV size by 13 octets. >> > Mark, > > I don't see how that's going to help much. The authors of this draft > have already stated that in order to doing EH insertion they will need > to encapsulate when packets enter the SR domain, so that's forty-bytes > of overhead right of the bat. And then there's the fixed overhead of > the EH before we finally get to the savings of compressing the EH > data. > So my understanding of the fundamental problem SR is trying to solve is to remove (MPLS) path state and path monitoring RSVP load from the control plane. I think this is a good idea, as I think packet networks scale by pushing complexity out of the network and towards the edge ("dumb network, smart hosts"). The path information is instead shifted to the each packet, carried in the SRH. While I think using IPv6 addresses to identify hops in an IPv6 networks is an obvious first choice, it does add considerable per-packet overhead. 128 bits hop identifiers aren't necessary if SR-MPLS only needs and uses 20 bits for the same purpose. The schemes I suggested before would still carrying IPv6 forwarding compatible hop identifiers while reducing this overhead. EH insertion to avoid tunnelling overhead as a response to a large SRH header because of 128 bit hop identifiers is just shifting complexity that has been moved out of the control plane by SR back into the network, and into the forwarding plane. I think IPv6 SR looses a lot of value if it shifts complexity in the network rather than removing it. > But even more important than the size of the headers, is the > processing cost. Processing fixed encapsulation at high speed is > expensive. I don't think that's avoidable (although it has occurred to me that when IPv6 becomes ubiquitous, it might be possible to use it directly as a the layer 2 on-the-wire frame format). > Processing open ended header chains and TLVs is _really_ > expensive to the point that they to date they are undeployable. Agree. This is why the divide-and-conquer approach of pushing complexity to the edge of the network and into the hosts helps us build faster and faster networks. The simpler the processing in the network, the faster it can be done and it's also less prone to error because there are less things that can go wrong. With NAT and middleboxes in IPv4, we've ended up with more complexity in the network and I've had enough experiences with that that I want to the simplicity of IPv4 networks before NAT and middleboxes back in IPv6. > While > I appreciate the optimism of the authors that the problem of > processing EH TLVs at line rate has been solved, I must admit I am > skeptical. It is hard to ignore a long history which has not been kind > to header chains or TLVs in IP. > > The obvious value of using something like the flow label is that it is > a zero overhead solution in the wire protocol. No encpasulation and no > EH. The route lookup for this could be implemented in a TCAM on > src,dst,flow label and the action is just to write a 20 bit value. Using the flow label has the advantages you mention, however updating it is still putting complexity back into the forwarding plane, and is a fork lift upgrade of the forwarding plane to get it. The use of the flow label for ECMP also faces this forwarding plane upgrade problem, although much less so - the upgrade to gain it is localised to the parts of the network where you need it. You don't need to universally upgrade all your forwarding plane devices just to gain flow label ECMP balancing across multiple links between two of your forwarding plane devices. Broadly, there seems to be a view that flag day upgrades are acceptable for new network technologies. That's a far more expensive and disruptive way to upgrade the capabilities network than the piecemeal, incremental and localised method that has been used to build the Internet since the ARPANET flag day. I don't think it should be preferred, I think it should be the last resort. > ILA, which serves the overlay network use case, is even simpler-- this > is a fixed length lookup on the destination and a write back to the > destination address. Flow label is not used and no change to standard > protocols is required, > Agree. I think ILA's techniques are much better because they leave the core forwarding plane alone, with the ILA changes occurring either in the host or in the first hop network device. The IPv6 forwarding plane remains conventional, simpler and standard. Regards, Mark. From nobody Wed Dec 13 11:41: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 2AA87127AD4; Wed, 13 Dec 2017 11:41:18 -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 HFTdjv0EChLv; Wed, 13 Dec 2017 11:41:16 -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 38BE5126E7A; Wed, 13 Dec 2017 11:41:16 -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 vBDJfFdb040849; Wed, 13 Dec 2017 12:41:15 -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 vBDJfBDG040804 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Dec 2017 12:41:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 13 Dec 2017 11:41:10 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Wed, 13 Dec 2017 11:41:10 -0800 From: "Templin, Fred L" To: Simon Hobson , "v6ops@ietf.org list" , IPv6 List Subject: RE: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Topic: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTc3ids/3rysN/2UOtzik0uog6BqNADGWAgAGf3HSAAAE2IA== Date: Wed, 13 Dec 2017 19:41:10 +0000 Message-ID: <5a503a3d1fcd43e882c782b6b9031e79@XCH15-06-08.nw.nos.boeing.com> References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@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.137.12.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: Wed, 13 Dec 2017 19:41:18 -0000 Hi, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Simon Hobson > Sent: Wednesday, December 13, 2017 11:35 AM > To: v6ops@ietf.org list ; IPv6 List > Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA >=20 > Brian E Carpenter wrote: >=20 > > Well, the "Note:" does leave an open question. How does the person (or > > automaton) configuring the router that sends the RA know that no > > information is available via DHCPv6? It is entirely possible that > > DHCPv6 is available on another box, and the person configuring the > > the router doesn't know it. So these flags are intrinsically unreliable > > and can only be hints; it's *necessary* that hosts are allowed to > > ignore them and look for DHCPv6 anyway. >=20 > I keep hearing this argument time and time again, but cannot reconcile it= with any professionally managed network. Are there really > professionally managed networks where the guys responsible for the router= s (intrinsically tied in with the network config) don't talk > to the guys running DHCP servers (intrinsically tied in with the network = config) ? > Put another way, are there really networks where two different groups "do= their own thing" without agreeing between themselves > how the network is supposed to work ? A unified SLAAC/DHCPv6 service would reconcile the ambiguity. Thanks - Fred > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Dec 13 12:27: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 D0FFE128BBB for ; Wed, 13 Dec 2017 12:27:49 -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, 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 C4TzCr5CHU6h for ; Wed, 13 Dec 2017 12:27:47 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 D8C58126FDC for ; Wed, 13 Dec 2017 12:27:47 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id v26so1943307pfl.7 for ; Wed, 13 Dec 2017 12:27:47 -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=yrycD/NqndSEpfDnO9jlGvRkPUIoupM1wFMGife/TRA=; b=fI4yxmnsiMLokm/IlYGKbAcKYY2Q5vroZppOXf1gm31KKLusdbokERx9oJVq/5lnql jc+vm5ZnGcwziizZpvFDVdOs9fy/3tYn0csihp9nL632HktEORbNiGbY8EYdYBLOcjGt viB3sZUupQHcd5qfgiu6g3j+F0k/++sUIZGbWQ/3X1TKMYAbB3e1gOxSlQmI3e8f/Ld9 1L+pxUCajvIGd34jG5bKKwmRbLhy5CnEipi2URk3W/Ilm87mhdLoXycoUd3vbGs18tzm AH3VuulBIlQdpo7qeRLFDRGPybQXoFCjZU5osxtfXaY3oWHfOeQsF1eC5AQPUUApfORM /coQ== 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=yrycD/NqndSEpfDnO9jlGvRkPUIoupM1wFMGife/TRA=; b=fuN4CV68bXu6hDOkM7pcEXu61vXBoi++EQadI1lW8qgcsSWSy0z0wUjqK3p4OaeCbM o6DnUr0Bpxoh2Z5xJgZvNojV2qC2IFQOuEkx3wXfR0LIngEHz3mS6EhyFyT4rZjZ7Npg UX/lh63D3EBgP5KJ4gW/ZXl1qgEjT24mJUSvwn3E0eSfq2xsCWjX8gMGDqAyuh6mf77O pb+iHvvTHhtkA8Zn99pJ5VNwKMs/JbzW5Sn1SIyvJ60yuArvuHFof1fS4kC2n04KEs1N u+V93AS0RNrACf1oyQuwqFvZg/HjpR91YG8Y4xLofU67T/bVL0BIRbWrxscGQSOHwlFT QJdg== X-Gm-Message-State: AKGB3mIzM4JJSuGgmZM5xOdrgE6S2+i6EPhoMOJzn3G1yOpWx8E3Uuu5 ACdZrEIeoR3tOcMJpfc9ShdNy400k9k= X-Google-Smtp-Source: ACJfBouiW2lTEcSMxltOExsZcEhzEWKaM0itg+cbPh8YY6OtOxI0K0cTbIzixCHBnZn9hWzaRq8XHQ== X-Received: by 10.98.223.217 with SMTP id d86mr7314737pfl.190.1513196867242; Wed, 13 Dec 2017 12:27:47 -0800 (PST) Received: from ?IPv6:2620::10e7:10:982f:6dc7:6cfc:285? ([2620:0:10e7:10:982f:6dc7:6cfc:285]) by smtp.gmail.com with ESMTPSA id d6sm4014594pgn.69.2017.12.13.12.27.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 12:27:46 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_A2D15CD6-4CBA-4FA9-AA78-4B735D81784E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA Date: Wed, 13 Dec 2017 12:27:45 -0800 References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> To: "v6ops@ietf.org list" , IPv6 List In-Reply-To: Message-Id: 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: Wed, 13 Dec 2017 20:27:50 -0000 --Apple-Mail=_A2D15CD6-4CBA-4FA9-AA78-4B735D81784E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 13, 2017, at 11:34, Simon Hobson wrote: > Brian E Carpenter wrote: >=20 >> Well, the "Note:" does leave an open question. How does the person = (or >> automaton) configuring the router that sends the RA know that no >> information is available via DHCPv6? It is entirely possible that >> DHCPv6 is available on another box, and the person configuring the >> the router doesn't know it. So these flags are intrinsically = unreliable >> and can only be hints; it's *necessary* that hosts are allowed to >> ignore them and look for DHCPv6 anyway. >=20 > I keep hearing this argument time and time again, but cannot reconcile = it with any professionally managed network. Are there really = professionally managed networks where the guys responsible for the = routers (intrinsically tied in with the network config) don't talk to = the guys running DHCP servers (intrinsically tied in with the network = config) ? > Put another way, are there really networks where two different groups = "do their own thing" without agreeing between themselves how the network = is supposed to work ? Put another way, "are there really professionally managed networks?=E2=80=9D= Worth noting: the point is that the =E2=80=9CNote:=E2=80=9D in RFC 4861 = cited previously in the thread asserts that M=3D0&O=3D0 is a signal to = all hosts on the link that =E2=80=9Cno information is available via = DHCPv6,=E2=80=9D which is really only true while *all* the routers on = the link are consistently sending that signal. It stops being true as = soon as one or more of the routers on the link contradict the signal, = and it continues to not be true until all the contradicting routers = expire their valid lifetimes. On a =E2=80=9Cprofessionally managed = network,=E2=80=9D there might never be any contradicting routers on the = link at any time, and in that case the Note correctly describes how the = protocol works. In other cases, however, it remains a little less than = clear. So, I ask again: are there really professionally managed networks? --james woodyatt > --Apple-Mail=_A2D15CD6-4CBA-4FA9-AA78-4B735D81784E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Dec 13, 2017, at 11:34, Simon Hobson <linux@thehobsons.co.uk> wrote:
Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:

Well, the "Note:" does = leave an open question. How does the person (or
automaton) = configuring the router that sends the RA know that no
information is available via DHCPv6? It is entirely possible = that
DHCPv6 is available on another box, and the person = configuring the
the router doesn't know it. So these flags = are intrinsically unreliable
and can only be hints; it's = *necessary* that hosts are allowed to
ignore them and look = for DHCPv6 anyway.

I keep = hearing this argument time and time again, but cannot reconcile it with = any professionally managed network. Are there really professionally = managed networks where the guys responsible for the routers = (intrinsically tied in with the network config) don't talk to the guys = running DHCP servers (intrinsically tied in with the network config) = ?
Put another way, are there really networks where two = different groups "do their own thing" without agreeing between = themselves how the network is supposed to work ?

Put = another way, "are there really professionally managed = networks?=E2=80=9D

Worth noting: the = point is that the =E2=80=9CNote:=E2=80=9D in RFC 4861 cited previously = in the thread asserts that M=3D0&O=3D0 is a signal to all hosts on = the link that =E2=80=9Cno information is available via DHCPv6,=E2=80=9D = which is really only true while *all* the routers on the link are = consistently sending that signal. It stops being true as soon as one or = more of the routers on the link contradict the signal, and it continues = to not be true until all the contradicting routers expire their valid = lifetimes. On a =E2=80=9Cprofessionally managed network,=E2=80=9D there = might never be any contradicting routers on the link at any time, and in = that case the Note correctly describes how the protocol works. In other = cases, however, it remains a little less than clear.

So, I ask again: are there really professionally = managed networks?


--james woodyatt <jhw@google.com>



= --Apple-Mail=_A2D15CD6-4CBA-4FA9-AA78-4B735D81784E-- From nobody Wed Dec 13 13:00: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 6FD84127005 for ; Wed, 13 Dec 2017 13:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, 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 H6ww5FSJcf8V for ; Wed, 13 Dec 2017 13:00:36 -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 466EC126BFD for ; Wed, 13 Dec 2017 13:00:36 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 9B23D5D6 for ; Wed, 13 Dec 2017 21:00:35 +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 NIlZ7jQOgZB0 for ; Wed, 13 Dec 2017 15:00:35 -0600 (CST) Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) (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 337AF26A for ; Wed, 13 Dec 2017 15:00:35 -0600 (CST) Received: by mail-lf0-f70.google.com with SMTP id g15so886323lfh.4 for ; Wed, 13 Dec 2017 13:00:34 -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=+VRS1OPIsSgKBn5I1/sHF5bVCpiJy9bjPuKeeLmaH5I=; b=ozB5GgwvP3flT+723uSkK5kM6WDuu8ga1WTX+9J9EbWKnM5Q0BAw44iDE9hux7peuk ex4zgn5wqK6yhEeMnS7ASvqbG7qGTa+vdeEZGtTAo1TXgTz9GTbPLirweOWUS3ebHSw6 dJ7ATAaLvfVIZ9+1cn5/MG8uM+cj0+13D6AYQx10Dz9Nc7jazYOPdRWxXIJ69pWwLcYn wwH5sMrouOMIEBg2c24vGgBYIWnM/HeCJ9raTAusBnNijtsLY7XUnol0T0BAYFpyb8Pn /OP/N6vqAN6if1dc8mWf68UO6iygnPhVSukJ4OUSPcgmZDGbutJivZBK7uQaW8aAT9Aj 1j1Q== 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=+VRS1OPIsSgKBn5I1/sHF5bVCpiJy9bjPuKeeLmaH5I=; b=BnS5Qme+DifqAXPi6Stsqu8sJ4RAd4NWbLASg9ctkQmjJLgEG0hVxPCc5XEAfmezb0 hT3S6Mja3wfvlmCg8JntXEBZq6m3uWy/KC2/EHsgxtljnFfWM8/4LvB2efHbPf7krX4i Xycq0Ii0w6RLAR7R5w8i4N1A/Am+tuvbkAFexRGj8KPk1PV/ebRVmgDxkaVFIRUEwoQX oRNZks0r4IYm8TOuhxYudQREJNQClhyy7nHRNG5cpNw/vtWD8RjJVx8mH4LxjSumKT4i zN1xefm96nAO9kq1KlYefjER4h7nCtfgly42vZwSiDY9UmjQQ9XucQdKv4ylS1Gd1J0F MmyQ== X-Gm-Message-State: AKGB3mIj/fYKfOdHbJaUnoEHeHnvvsTB2XgeoxWAf5SK7eTRaHWs05P4 nsffmJ3+DaVlNR/ZUCMx5z15iAoVcNBtYAtzVG/kvaqSQMTVG9rwdE28IS6IsC0pQQTDvKt0eSf /9LUQv9XasWji61OXKELxBO9S X-Received: by 10.46.88.77 with SMTP id x13mr229448ljd.80.1513198833424; Wed, 13 Dec 2017 13:00:33 -0800 (PST) X-Google-Smtp-Source: ACJfBosJrZuMgCI67cZOkUQkEwZzstjS4HQGRUzyHui/nJfpvN+J4sqAXMq5J1tnyHLh9dii/A4rAP2/2e1rt6aGD6o= X-Received: by 10.46.88.77 with SMTP id x13mr229439ljd.80.1513198833135; Wed, 13 Dec 2017 13:00:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.216.99 with HTTP; Wed, 13 Dec 2017 13:00:32 -0800 (PST) In-Reply-To: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> From: David Farmer Date: Wed, 13 Dec 2017 15:00:32 -0600 Message-ID: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA To: Simon Hobson Cc: "v6ops@ietf.org list" , IPv6 List Content-Type: multipart/alternative; boundary="f4030438f0f0ec7f2605603f0e0c" 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, 13 Dec 2017 21:00:38 -0000 --f4030438f0f0ec7f2605603f0e0c Content-Type: text/plain; charset="UTF-8" On Wed, Dec 13, 2017 at 1:34 PM, Simon Hobson wrote: > Brian E Carpenter wrote: > > > Well, the "Note:" does leave an open question. How does the person (or > > automaton) configuring the router that sends the RA know that no > > information is available via DHCPv6? It is entirely possible that > > DHCPv6 is available on another box, and the person configuring the > > the router doesn't know it. So these flags are intrinsically unreliable > > and can only be hints; it's *necessary* that hosts are allowed to > > ignore them and look for DHCPv6 anyway. > > I keep hearing this argument time and time again, but cannot reconcile it > with any professionally managed network. Are there really professionally > managed networks where the guys responsible for the routers (intrinsically > tied in with the network config) don't talk to the guys running DHCP > servers (intrinsically tied in with the network config) ? > Put another way, are there really networks where two different groups "do > their own thing" without agreeing between themselves how the network is > supposed to work ? > So when the people running the DHCPv6 servers screw up, and the DHCP server is down, what tells the router tat DHCPv6 isn't available? Nothing, therefore, at best the M and O flags signal an intent not a fact, and should only be considered advisory. So I consider the M an O flags to mean; 1 = there should be a DHCPv6 server, and therefore hosts should keep trying if one doesn't readily answer 0 = there should not be a DHCPv6 server, and therefore hosts should not keep trying if one doesn't readily answer, or hosts might not try at all Furthermore, even if there is no router on the link to advertise an RA, or if the router is misconfigured to set M and O flags = 0, that doesn't mean there isn't a DHCPv6 severer on the link, or available via routed multicast. Its is probably safe to assume there isn't a DHCPv6 relay configured on the router though. This is why several OS send initial DHCPv6 Solicits. But, I would hope if M and O flags = 0, this would not be continued after a couple tries. In other words, if you send a couple solicits and get no answer, you have empirical evidence that the M and O flags = 0 is actually correct, and should then give up. I believe the M and O flag specification in RFC 4861 is technical correct, but is far too subtly written. I would be good when RFC 4861 is next update for this to be more plainly stated. 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> =============================================== --f4030438f0f0ec7f2605603f0e0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 13, 2017 at 1:34 PM, Simon Hobson <linux@thehobsons.c= o.uk> wrote:
Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> Well, the "Note:" does leave an open question. How does the = person (or
> automaton) configuring the router that sends the RA know that no
> information is available via DHCPv6? It is entirely possible that
> DHCPv6 is available on another box, and the person configuring the
> the router doesn't know it. So these flags are intrinsically unrel= iable
> and can only be hints; it's *necessary* that hosts are allowed to<= br> > ignore them and look for DHCPv6 anyway.

I keep hearing this argument time and time again, but cannot reconcile it w= ith any professionally managed network. Are there really professionally man= aged networks where the guys responsible for the routers (intrinsically tie= d in with the network config) don't talk to the guys running DHCP serve= rs (intrinsically tied in with the network config) ?
Put another way, are there really networks where two different groups "= ;do their own thing" without agreeing between themselves how the netwo= rk is supposed to work ?

So when the pe= ople running the DHCPv6 servers screw up, and the DHCP server is down, what= tells the router tat DHCPv6 isn't available? Nothing, therefore, at be= st the M and O flags signal an intent not a fact, and should only be consid= ered advisory.=C2=A0 So I consider=C2=A0the M an O flags to mean;

1 =3D there should be a DHCPv6 server, and therefore hosts = should keep trying if one doesn't readily answer
0 =3D there = should not be a DHCPv6 server, and therefore=C2=A0hosts should not keep try= ing if one doesn't readily answer, or hosts might not try at all
<= div>
Furthermore, even if there is no router on the link to a= dvertise an RA, or if the router is misconfigured to set M and O flags =3D = 0, that doesn't mean there isn't a DHCPv6 severer on the link, or a= vailable via routed multicast. Its is probably safe to assume there isn'= ;t a DHCPv6 relay configured on the router though. This is why several OS s= end initial DHCPv6 Solicits. But, I would hope if M and O flags =3D 0, this= would not be continued after a couple tries. In other words, if you send a= couple solicits and get no answer, you have empirical evidence that the M = and O flags =3D 0 is actually correct, and should then give up.
<= br>
I believe the M and O flag specification in=C2=A0RFC 4861=C2=A0is technical correct, but is far= too subtly written. I would be good when=C2=A0RFC 4861 is next update for this to be more plainly=C2=A0stated.

Thanks.
=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 &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
--f4030438f0f0ec7f2605603f0e0c-- From nobody Wed Dec 13 13:43: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 E7A7E126D73; Wed, 13 Dec 2017 13:43:33 -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 weEb_le_AROf; Wed, 13 Dec 2017 13:43:32 -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 F364512704B; Wed, 13 Dec 2017 13:43:31 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id j28so2079970pfk.8; Wed, 13 Dec 2017 13:43:31 -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=YAMLiS5BErtR6umb+60F3azxbZ4FGHRRTmC3Xhd31w4=; b=Tsr7eYjO9PR+gf1lqvjBJe87J/dzPC8e7wGS63Z2rmj+3I8/Pu2W1qKD+RvLTkYmfX pOnaJ8Bs4JN4b/1qGB56IRKeQh/uCctPqzKnJXfxe7ITUk5dIBD3gyliF35duyLgHRHx pd8c986XWnY1N66ETtpH90H4ZnamNqcLLDpI7L/eKGvcFSe1pl8vZqkCdvNxisc+KMNE ZE9KiJFIMy09WAvxz22G1oAhLobvnyvYY44JGIW4NTRiHKfwhPLU2X5YxTEsccQRr63O LUtSqDUeJwkR4etPWo/3TCTbT9nhysei640fMe1UE8MlTc41IwVPe85inC8jcB05YWLr 265w== 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=YAMLiS5BErtR6umb+60F3azxbZ4FGHRRTmC3Xhd31w4=; b=YkM1XsnM3lIUPW0nwPWEjnCJPGlerBhqL6489/3MXJBH9JxHyjNAtQ1T+i8qb+/62Y dilQRu+THct+YaokM9TqLJGqmmivHCXoPz+Bj8t5kiYrUmfVyQFQN/Aof+vNw+fD60rq yhyazMqu8DuOjGzw1VzZaB1PJ1TtM5H1pcIqYWvNukQsm804o3LS+XkHhzBrjy9pqK3b mYy2UsyRhlC6I2d570MzC0UQ8t3vobd5Iw+PkmAsWpQP91iaP+c1YueyNUk7n0wCTDOJ pram8YTwif2rEhslWIBkx33xQwGT8WhrD57sN151tSG0nHgkPV6m2evR2nLDsNRG8fuR 1glQ== X-Gm-Message-State: AKGB3mKksyN1Xx8cJgPkgDHkkN7fFnAZrOr/OsURdPBcDG9fApbHft12 VS/ljO4rxCwbAxr8YjUBYqw= X-Google-Smtp-Source: ACJfBot7pjWOmtYDSCc/N/6KE0gJfhXA0DgKzZlbtsabQVw71di3+UKgv0IqVujdkEveUlmY7V64Jw== X-Received: by 10.99.124.24 with SMTP id x24mr6470695pgc.196.1513201411569; Wed, 13 Dec 2017 13:43:31 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id z23sm4428634pgc.2.2017.12.13.13.43.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 13:43:29 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_098534B7-E197-4DB3-BC1B-1DFB55E961A1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA Date: Wed, 13 Dec 2017 13:43:27 -0800 In-Reply-To: Cc: Bob Hinden , "v6ops@ietf.org list" , IPv6 List To: james woodyatt References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@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: Wed, 13 Dec 2017 21:43:34 -0000 --Apple-Mail=_098534B7-E197-4DB3-BC1B-1DFB55E961A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 James, > On Dec 13, 2017, at 12:27 PM, james woodyatt wrote: >=20 > On Dec 13, 2017, at 11:34, Simon Hobson = wrote: >> Brian E Carpenter wrote: >>=20 >>> Well, the "Note:" does leave an open question. How does the person = (or >>> automaton) configuring the router that sends the RA know that no >>> information is available via DHCPv6? It is entirely possible that >>> DHCPv6 is available on another box, and the person configuring the >>> the router doesn't know it. So these flags are intrinsically = unreliable >>> and can only be hints; it's *necessary* that hosts are allowed to >>> ignore them and look for DHCPv6 anyway. >>=20 >> I keep hearing this argument time and time again, but cannot = reconcile it with any professionally managed network. Are there really = professionally managed networks where the guys responsible for the = routers (intrinsically tied in with the network config) don't talk to = the guys running DHCP servers (intrinsically tied in with the network = config) ? >> Put another way, are there really networks where two different groups = "do their own thing" without agreeing between themselves how the network = is supposed to work ? >=20 > Put another way, "are there really professionally managed networks?=E2=80= =9D >=20 > Worth noting: the point is that the =E2=80=9CNote:=E2=80=9D in RFC = 4861 cited previously in the thread asserts that M=3D0&O=3D0 is a signal = to all hosts on the link that =E2=80=9Cno information is available via = DHCPv6,=E2=80=9D which is really only true while *all* the routers on = the link are consistently sending that signal. It stops being true as = soon as one or more of the routers on the link contradict the signal, = and it continues to not be true until all the contradicting routers = expire their valid lifetimes. On a =E2=80=9Cprofessionally managed = network,=E2=80=9D there might never be any contradicting routers on the = link at any time, and in that case the Note correctly describes how the = protocol works. In other cases, however, it remains a little less than = clear. >=20 > So, I ask again: are there really professionally managed networks? Yes. The common definition of professional is that you get paid to do a = job. How well you do it is another matter :-) To you point, I think there are networks where all of the routers are = configured correctly. Bob --Apple-Mail=_098534B7-E197-4DB3-BC1B-1DFB55E961A1 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 iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloxnv8ACgkQrut0EXfn u6gIhQgAjpqM62OLl/Q7lIeAopLA9flw3zgIq0F6/03QqYqat57GGw1Fne1bXMFx Tf66Y/lsavX/9Dbhlnobf6j30cuyNuLvlKtU5DF2SwS+QRlSHh+xYjAfNCKhjbJo BYoCrmzIUzwuuBWjPm9qIQfuu5MCFh6vkVjSCm20NAAtZv0fTsiEvT2iyHSEqcrx cmko0MpEQ0RZu636sxvnBwSDl6VKN2Rk7qCzZU2xEyWF8tXJzQswQD7YK+lA/2Wa ReNSkvOWKw8AqW2yG8W2QrbHoxdjoR/2xuSVtAF7kBEEHzccLXJME1mQiO+9Uxl3 ri8YiOaGlgBlWQPOncza+2zB8h9p2A== =MSZP -----END PGP SIGNATURE----- --Apple-Mail=_098534B7-E197-4DB3-BC1B-1DFB55E961A1-- From nobody Wed Dec 13 14: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 C2EEB1205F0; Wed, 13 Dec 2017 14:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 qmeABsHuRs7h; Wed, 13 Dec 2017 14:08:04 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 4B60B126D85; Wed, 13 Dec 2017 14:08:04 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id vBDM7bdY040152; Wed, 13 Dec 2017 17:08:01 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2eubftt5bb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Dec 2017 17:08:01 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBDM80oB022136; Wed, 13 Dec 2017 17:08:01 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBDM7ufx022116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Dec 2017 17:07:59 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 13 Dec 2017 22:07:37 GMT Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 328BE4000341; Wed, 13 Dec 2017 22:07:37 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30484.vci.att.com (Service) with ESMTPS id 19A9C40006FB; Wed, 13 Dec 2017 22:07:37 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.227]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0361.001; Wed, 13 Dec 2017 17:07:36 -0500 From: "STARK, BARBARA H" To: Naveen Kottapalli CC: v6ops list , 6man WG Subject: RE: Windows 10 doesn't honour 'M' flag in RA Thread-Topic: Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTcxnIMEBQ+YpiC0KlzMNBptkKMaM/UtuWgAKBR0A= Date: Wed, 13 Dec 2017 22:07:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.212.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-13_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=359 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712130304 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, 13 Dec 2017 22:08:06 -0000 SGkgTmF2ZWVuIChvciBhbnlvbmUgZWxzZSB3aG8gY2FyZXMgdG8gYW5zd2VyKSwNCg0KPiBJbiBv dXIgcmVjZW50IHRlc3RpbmcsIHdlIG9ic2VydmVkIHRoYXQgV2luZG93cyAxMCBkb2Vzbid0IGhv bm91ciAnTScgZmxhZw0KPiBpbiBSQS7CoCBJdCdzIG5vdCBqdXN0IFdpbmRvd3MgMTAsIHNhbWUg YmVoYXZpb3VyIGlzIG9ic2VydmVkIHdpdGggbGF0ZXN0IE1hYw0KPiBPUyBhcyB3ZWxsLsKgIA0K DQpJJ20gY3VyaW91czogV2hhdCBpcyBiZWluZyBoYXJtZWQgYnkgdGhpcyBiZWhhdmlvcj8gSSBj YW4gZGVmaW5pdGVseSBzZWUgYWR2YW50YWdlcyBpbiBXaW5kb3dzIGFuZCBNYWMgT1MgZG9pbmcg aXQgdGhpcyB3YXk7IEknbSBqdXN0IHN0cnVnZ2xpbmcgdG8gdW5kZXJzdGFuZCB0aGUgZGlzYWR2 YW50YWdlcy4gWWVhcnMgYWdvLCB0aGVyZSB3YXMgYSBwcm9ibGVtIGluIHNvbWUgSVNQIG5ldHdv cmtzIHByaW9yIHRvIGZ1bGwgbGF1bmNoIG9mIElQdjYgYW5kIHByaW9yIHRvIHN1cHBvcnQgZm9y IFNPTF9NQVhfUlQgKFJGQyA3MDgzKSBvZiBESENQdjYgc2VydmVycyBiZWluZyBvdmVyd2hlbG1l ZCBieSBTb2xpY2l0IG1lc3NhZ2VzIHRoZXkgd2VyZSBjb25maWd1cmVkIG5vdCB0byByZXNwb25k IHRvIChiZWNhdXNlIElQdjYgd2Fzbid0IGZvcm1hbGx5IHN1cHBvcnRlZCkuIEJ1dCB3aXRoIFNP TF9NQVhfUlQsIHRoYXQgcmVhbGx5IHNob3VsZG4ndCBiZSBhbiBpc3N1ZS4gU28gd2hhdCBpcyBi ZWluZyBicm9rZW4gYnkgdGhpcyBiZWhhdmlvciBub3c/DQoNCkJhcmJhcmENCg== From nobody Wed Dec 13 15:35: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 27D30128AA1; Wed, 13 Dec 2017 15:35:35 -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 dlqB8omm8Y5o; Wed, 13 Dec 2017 15:35:32 -0800 (PST) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE25C1201F8; Wed, 13 Dec 2017 15:35:31 -0800 (PST) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id BCACD27304; Thu, 14 Dec 2017 00:35:29 +0100 (CET) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 9068765D5B0; Thu, 14 Dec 2017 00:35:29 +0100 (CET) Received: by ws26.ernw.net (Postfix, from userid 1002) id 5AAA439CB5; Thu, 14 Dec 2017 00:35:29 +0100 (CET) Date: Thu, 14 Dec 2017 00:35:29 +0100 From: Enno Rey To: "STARK, BARBARA H" Cc: Naveen Kottapalli , v6ops list , 6man WG Subject: Re: Windows 10 doesn't honour 'M' flag in RA Message-ID: <20171213233529.GA55691@ernw.de> References: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Mutt/1.7.1 (2016-10-04) 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, 13 Dec 2017 23:35:35 -0000 Hi, On Wed, Dec 13, 2017 at 10:07:36PM +0000, STARK, BARBARA H wrote: > Hi Naveen (or anyone else who cares to answer), > > > In our recent testing, we observed that Windows 10 doesn't honour 'M' flag > > in RA.?? It's not just Windows 10, same behaviour is observed with latest Mac > > OS as well.?? > > I'm curious: What is being harmed by this behavior? I can definitely see advantages in Windows and Mac OS doing it this way; I'm just struggling to understand the disadvantages. when the router - sends RAs with "O" flag. - is configured as a DHCPv6 server handing out one or several v6 DNS server(s) [which is a very common setup of CPE devices in broadband networks] then the node sending a DHCPv6 SOLICIT (without being "advised" to do so by the "M" flag) will receive (from the DHCPv6 server not being able to serve it's request) a "NoAddrAvail" status code and will hence (in full compliance with RFC 3315 sect. 17.13) ignore the *full* DHCPv6 packet received from the server. This in turns means it will not learn the (v6) DNS server which is clearly not what is intended by that type of setup from the broadband providers. See also: https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/ best Enno Years ago, there was a problem in some ISP networks prior to full launch of IPv6 and prior to support for SOL_MAX_RT (RFC 7083) of DHCPv6 servers being overwhelmed by Solicit messages they were configured not to respond to (because IPv6 wasn't formally supported). But with SOL_MAX_RT, that really shouldn't be an issue. So what is being broken by this behavior now? > > Barbara > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Wed Dec 13 16:01: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 203C5124B18 for ; Wed, 13 Dec 2017 16:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 N8_WR1G-AEmp for ; Wed, 13 Dec 2017 16:01:12 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 C7AB612025C for ; Wed, 13 Dec 2017 16:01:11 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id v21so3535458oth.6 for ; Wed, 13 Dec 2017 16:01:11 -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=6/YNR7DPeX+yluDSCVTKRbka8a6rQJo4k+L1rHSf7Gg=; b=VpoQwE3C9tHTRTrBI3eNFs3VVPJRvSv7f3qP4hqyQuk4y54swPs6BWggpjPABfRvvd kdpg/MPb2GvJWSpOYhDBEYZV5T4pArJ845dKulwOLu/mBMcau9psrGSxGIC9BaMiSiok mORpblsWArT4l0a2UkHW3wejQufb8muVa/A5Ki6XdSvXbpESnC5fCX7xXb6iw/MlvaZU e9D3MP+9z0QW/QdvFfC7jE20TGipinRs8WD+cbHuOI/gSNnRVFk1YTyJ9lFjK5qeTKOp s+8FbSsIKZvDT7L+B1CD4hp46xN3513ggGZ6lLkMpEDjdOsDIt6qZodzCmh/J/S6D3vg QSXQ== 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=6/YNR7DPeX+yluDSCVTKRbka8a6rQJo4k+L1rHSf7Gg=; b=G75+4gWJ58L+ZaajanNORDRTyjdUCvTQh0XhNc7ckblN53Zpg3MPLuAQAEE+Ce3l6w gbeh4ZRblNEwJZlaNrBfsVCOmONOIsYAen9y1i7PNozLlKrCRTZssxubucv5LFgezzgY D17iRB/do4JToJGlIbjaq0j4Tpt2dTKHR3INkgFEcAAshvGtWFwuHsipHh+o7OckRwo9 bITxOWIjMj4QK7z1NeK8Qk2UhQWvCLwIAdKCov549jdkfHeEyzAXFjd5LVIAbBWEjjZq wqYEnyCnRVMN3jRMEvfm9AfftGoIVC7g7/a/8RIzMR8b9vPTQj62JX2HiemfW2QGBJ7m cLcg== X-Gm-Message-State: AKGB3mJ+RRWdkifoHCNMQ4LFeUvTze+5e7/YVgoypiDew4M3pQGquddK G0QVWVpBaxZkpsDD0DBQPDYS+jv/ X-Google-Smtp-Source: ACJfBovqF5tcO3HpbFmDTjBJSIFUtoCXYtvR56sv0fxxHm521yMWYoYhXUrjB/UsaaBOdk2VzXIDLw== X-Received: by 10.157.62.93 with SMTP id h29mr3615177otg.386.1513209671109; Wed, 13 Dec 2017 16:01:11 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::100f? ([2600:8802:5600:f7a::100f]) by smtp.gmail.com with ESMTPSA id u65sm1282705oia.46.2017.12.13.16.01.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 16:01:10 -0800 (PST) From: Fred Baker Message-Id: <58948F5B-3676-47C8-BAF4-1954AE04303A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7C0831C7-8A9A-4FE7-9124-BEC514C45323"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: New Version Notification for draft-hinden-ipv4flag-01.txt Date: Wed, 13 Dec 2017 16:01:07 -0800 In-Reply-To: <09613E79-FAA9-49DF-9997-5C4739DF360A@gmail.com> Cc: IPv6 List To: Bob Hinden References: <151311762550.30105.15490803659981825351.idtracker@ietfa.amsl.com> <09613E79-FAA9-49DF-9997-5C4739DF360A@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) 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, 14 Dec 2017 00:01:14 -0000 --Apple-Mail=_7C0831C7-8A9A-4FE7-9124-BEC514C45323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 https://tools.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4flag-01.txt You're correct, it is improved. However, I still think there is a = fundamental issue in that the sets of IPv4 routers and IPv6 routers can = be completely disjoint, and the IPv6 routers not know about the IPv4 = capabilities. That can be viewed several ways - in the security = considerations, you note that it is a potential attack vector, for = example. Speaking for myself, I would rather have the hosts decide that = there is no IPv4 service available from the fact of not having an = address and being in a backoff mode in DHCP than from a potentially = erroneous assertion in an unrelated protocol. It seems to me that the issue could be addressed by using an exponential = backoff in DHCP (if you don't get an answer, ask again, but wait = increasingly long), eventually stopping asking, and waiting for someone = to issue an ARP announcement that they are using an address other than = 169.254.x.x. Would it help if I posted a draft about inferring lack of IPv4 services = from the lack of IPv4 data? > On Dec 12, 2017, at 2:33 PM, Bob Hinden wrote: >=20 > Hi, >=20 > Based on the discussion on the previous draft, we updated it. We = think this resolves many of the issues raised. The changes include: >=20 > o Inverted name of flag from "Available" to "Unavailable=E2=80=9D. >=20 > o Added problem description and clarified scope. >=20 > o Added router and operational considerations section. >=20 > o Added host behavior considerations section. >=20 > o Extended security considerations section. >=20 > o Added Acknowledgment section, including reference to prior = sunset4 draft. >=20 > Please review and comment. We think this version is an improvement = over the -00 version. >=20 > Thanks, > Bob & Brian >=20 >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-hinden-ipv4flag-01.txt >> Date: December 12, 2017 at 2:27:05 PM PST >> To: "Robert M. Hinden" , "Robert Hinden" = , "Brian Carpenter" >>=20 >>=20 >> A new version of I-D, draft-hinden-ipv4flag-01.txt >> has been successfully submitted by Robert M. Hinden and posted to the >> IETF repository. >>=20 >> Name: draft-hinden-ipv4flag >> Revision: 01 >> Title: IPv6 Router Advertisement IPv4 Unavailable Flag >> Document date: 2017-12-12 >> Group: Individual Submission >> Pages: 8 >> URL: = https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-01.txt >> Status: = https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/ >> Htmlized: https://tools.ietf.org/html/draft-hinden-ipv4flag-01 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-01 >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4flag-01 >>=20 >> Abstract: >> This document specifies a Router Advertisement Flag to indicate = that >> there is no IPv4 service on the advertising default IPv6 router. >> This document updates RFC5175. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_7C0831C7-8A9A-4FE7-9124-BEC514C45323 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----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAloxv0MACgkQEhdRnd2G P+Ac8A/+Kp7mtmMDRw8sgNDlePixvnTI4VZnf9xeR5ruL1mE80CW5xHoep4rX6T0 shbgCcIranBq3xZdxIk7WEHOi4H/UHzFUEe67FZZT+EC1E8eBVYM24OqT9xUiUBB GwlvrVXsVcUDwXTY36gG1CGNXZ5BUjjmpB1Nz/LK/ORrNiR2SggQQsVHK1JQ/rtI b9O5GCMx72PEF0BD40LJGNCBqnpT4ZvLjizY7LFSF0tEfNTuK+PomB01h4lCVxaF 1DfzmxfGLHtaZ7kvSxEnVvgITmcincKQlfdTrR1WWfAgGfbcCRxEYDTJH8DWgY46 S10IVpqlg9OfvlJuZ+54Ls8ZszjD1YPqQbveu0ZbX3yJmvqLUBr89aqfIv7XRrPC wkmTcpahTSSujNHxPpIRR/AVhrca+q8wgTU/RdrLb0EPU7yNwgjU4Tl2OHpuhCG1 3NcXCL/+t4cLhMCRRwg/5DA/+6/ptGiKDeic1NUecDbicEnNYQWS7wKqbKCwug42 LMdpnG511wz/PD/VeGy5czJR1xCDTxYU+BCXYTNPeWnh9+r44NcHfq89kLeu/3rP 5pWsGXsmErTCSvd05vziLMNMXCp2j1IlJgMc2gu1Uo3PGnTs81a4ECWEPyzZWI3X iMYBwgOoHvkVGernwJ/VdHEccDhyw+xU7NtZHvPCkX8zd1lciZg= =sR79 -----END PGP SIGNATURE----- --Apple-Mail=_7C0831C7-8A9A-4FE7-9124-BEC514C45323-- From nobody Wed Dec 13 17:11: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 3FDA112421A for ; Wed, 13 Dec 2017 17:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 ZCTRGeaObbSO for ; Wed, 13 Dec 2017 17:10:58 -0800 (PST) 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 6DFF51200F1 for ; Wed, 13 Dec 2017 17:10:58 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id d4so6125934qtj.5 for ; Wed, 13 Dec 2017 17:10:58 -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; bh=+ExMM6Y91zkCkaWgKXBh7Pviu4QkTLMcn54A2RLEE7M=; b=bZqTl0QL/ePDfA79clGx5hTi4pwe5OnVzCUx/k+SM+gM+gRWvBd9iRtT25Rl4xbPJ1 5tvzIIytznkHGmF2mH+JCW3KUwK3m8j+Nsydq9eI35+Y1BvGNfepWodlbP50kOtSvbXS 3O/4zWFR7cEDUr/pQ0+86x1quDmtQ1q6jUVxhCn7gqVLbnlbfpOkIcE7fb1giVFZF0YU YHPha/bl7VAKJeEv76OfBASQ5CrxV+bM96WrpEkWVvUZ4twKnk27OEofo3nZX1SWuzDZ 0c3T0uSEsgHSv1xavqjnLbHT+sgqQcWNR3kr7nOeGN+7qWIwGg3zeou/+MEHfgWEawFI UXFg== 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=+ExMM6Y91zkCkaWgKXBh7Pviu4QkTLMcn54A2RLEE7M=; b=luzJg0XdkDlj0v+u6F4V9u9Rxc6kqNkwCOKX2xoTAC7lUy1r7oxDFi/c6gHqqYCFBK fHFGWDBydaMEa+WeQoAe58R69jZpXuWaKHql7ANXB/xHxoAonBYJ9dJ6Xkoa8kspKFPk TQH4HUK+n9/5KeZS9onIata/3fIFQLiDV9YNGekoTRqP4qZziQMDHQW5k0ZUuNCWnJIJ ASgD9TraDUwWrqrGsl4zh3S+G7eu451xDzrqWstwUjhTCtF+QlOMD1RTjOxVIkaMIuJm nWQGBdc+RYGWw/TwFAL8/Nj7kdtjDfthXI1KKY4LKfpy1/fPoPRXxThzJSQXPOJeckX4 LU2w== X-Gm-Message-State: AKGB3mJ/siksQxjZpmx7Rll/WMos4CBGrn/MsoW7AqlhYy7+/kKrGjzS AZdwHdcK673Fol3T5BNIRB3/UBBLhbGDfKMvnkRlWw== X-Google-Smtp-Source: ACJfBovAsMOplC2pzWrmTCqxGOD2ro9cakYLZlkQjo5sMBcaPkkHEGjTWgBAkQbjt3HSMpR2eQ4amvxUMEzrZ2SY/CQ= X-Received: by 10.200.58.229 with SMTP id x92mr14250789qte.187.1513213857434; Wed, 13 Dec 2017 17:10:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.121 with HTTP; Wed, 13 Dec 2017 17:10:56 -0800 (PST) In-Reply-To: References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <8ecf3590-5313-551e-fbb3-f95aada87a67@uniroma2.it> <1cf221bc-e2e3-bc04-6559-d01eff2e1232@gmail.com> From: Tom Herbert Date: Wed, 13 Dec 2017 17:10:56 -0800 Message-ID: Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt To: Mark Smith Cc: Bob Hinden , 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, 14 Dec 2017 01:11:00 -0000 > EH insertion to avoid tunnelling overhead as a response to a large SRH > header because of 128 bit hop identifiers is just shifting complexity > that has been moved out of the control plane by SR back into the > network, and into the forwarding plane. I think IPv6 SR looses a lot > of value if it shifts complexity in the network rather than removing > it. > I suspect that if EH insertion can't be done without encapsulation then the value proposition for using extension headers here largely evaporates The overhead of encapsulation is not insignifanct and the issues of incompatibility of using any EH are still present. An alternative is to put the routing information as payload of the encpasulation instead of EH. That is the approach taken by BIER for instance. For the cost of an eight byte UDP header they get compatability on any network (and with IPv4 for that matter). > > >> But even more important than the size of the headers, is the >> processing cost. Processing fixed encapsulation at high speed is >> expensive. > > I don't think that's avoidable (although it has occurred to me that > when IPv6 becomes ubiquitous, it might be possible to use it directly > as a the layer 2 on-the-wire frame format). > Considering that everything is pretty much layer 3 switched point to point links you could do that. But probably more hassle to change everything than it's worth. >> Processing open ended header chains and TLVs is _really_ >> expensive to the point that they to date they are undeployable. > > Agree. This is why the divide-and-conquer approach of pushing > complexity to the edge of the network and into the hosts helps us > build faster and faster networks. > > The simpler the processing in the network, the faster it can be done > and it's also less prone to error because there are less things that > can go wrong. > > With NAT and middleboxes in IPv4, we've ended up with more complexity > in the network and I've had enough experiences with that that I want > to the simplicity of IPv4 networks before NAT and middleboxes back in > IPv6. > > > >> While >> I appreciate the optimism of the authors that the problem of >> processing EH TLVs at line rate has been solved, I must admit I am >> skeptical. It is hard to ignore a long history which has not been kind >> to header chains or TLVs in IP. >> >> The obvious value of using something like the flow label is that it is >> a zero overhead solution in the wire protocol. No encpasulation and no >> EH. The route lookup for this could be implemented in a TCAM on >> src,dst,flow label and the action is just to write a 20 bit value. > > Using the flow label has the advantages you mention, however updating > it is still putting complexity back into the forwarding plane, and is > a fork lift upgrade of the forwarding plane to get it. > > The use of the flow label for ECMP also faces this forwarding plane > upgrade problem, although much less so - the upgrade to gain it is > localised to the parts of the network where you need it. You don't > need to universally upgrade all your forwarding plane devices just to > gain flow label ECMP balancing across multiple links between two of > your forwarding plane devices. > > Broadly, there seems to be a view that flag day upgrades are > acceptable for new network technologies. That's a far more expensive > and disruptive way to upgrade the capabilities network than the > piecemeal, incremental and localised method that has been used to > build the Internet since the ARPANET flag day. I don't think it should > be preferred, I think it should be the last resort. > > >> ILA, which serves the overlay network use case, is even simpler-- this >> is a fixed length lookup on the destination and a write back to the >> destination address. Flow label is not used and no change to standard >> protocols is required, >> > > Agree. I think ILA's techniques are much better because they leave the > core forwarding plane alone, with the ILA changes occurring either in > the host or in the first hop network device. The IPv6 forwarding plane > remains conventional, simpler and standard. > Less is more! Tom > Regards, > Mark. From nobody Wed Dec 13 17:18: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 C8175126DCA for ; Wed, 13 Dec 2017 17:18:25 -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 LL9QzPOp6RlD for ; Wed, 13 Dec 2017 17:18:23 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 C6E3E1243FE for ; Wed, 13 Dec 2017 17:18:23 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id q20so2337388pgv.2 for ; Wed, 13 Dec 2017 17:18:23 -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-language:content-transfer-encoding; bh=Szx/LW2fWzxYI3hkqK9MEVegSdOANb8sTUxu2J+S99w=; b=OiLXrdW/MDXgFC6HLOoK4j4VUxQvHwbQGyVhqKt1tUjC0VW0xwG/A+rFJFp6MIex/y oPAthflmBDzZB3aG39rnRozBgphZ1TebrwlKcuUT9LkdjMzoBHFrTSXjH9BRv940fQOS XD82nbwVou5b759RaKrv73qyUAJj5o56FXKisKXCIhDaejrpaghNlu26QcBd55Vhu8z+ EdaKOy4iHLE1VYgyRmUOcc1PUd14SlJfCNoySqYJ75vY10Rk1wrh0gLoCITZTkqNalrR pxedHyAsTpSoNxDtAM+0RRTSItbGRJoQMWsFLNLPeP7RPA1PQHweQpkj2JnlTEJoom1D HX6w== 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-language:content-transfer-encoding; bh=Szx/LW2fWzxYI3hkqK9MEVegSdOANb8sTUxu2J+S99w=; b=gMgj/lRxuWaqR5MVt7T4Jctj+f7tWwGkqzHKJpqBeprFDvV5/PsmvNPbkvhGr5g8c1 zRQ32rd4me3DGSM1xvgzx+mrxw4NBBf5+eChxIceN8AZL9knShC5qA7fTj8ZzWHmIYCl g9S+ExM6ZF1+z2vRpKpf+Z/CHXRmwgOBxNnygE/wHHO0as9k9PBPw9B2TANRELGIY23Q fiyiS+T61M4OXZaCdC/pLs1RoMFNaHP/4WCVqK4z8pD1gvqHBySTY0lX62A5FGFJh5yV eWtStq3YI8SzJFmt5jeUmngDvm9Y6ETFf+d3++kWY6emlicDyqrPZ85fZiHg+DkmHYW3 wN+A== X-Gm-Message-State: AKGB3mIATTIx3WrFdFsrtQVKcx3OKD8wr1TU4CG5IZy48Oj5Wptl8uGv /Hud+ov39ZG0XSixJ/rbglLHUQ== X-Google-Smtp-Source: ACJfBosSLZ+NN18IpokTE8AZLha/Q+4caKK8Jq12zPOrzByiNCZqTPzUK2qob3Ml2d7+WKpUtK2x3A== X-Received: by 10.98.33.8 with SMTP id h8mr7855855pfh.160.1513214303002; Wed, 13 Dec 2017 17:18:23 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a87sm4971354pfg.159.2017.12.13.17.18.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 17:18:21 -0800 (PST) Subject: Re: New Version Notification for draft-hinden-ipv4flag-01.txt To: ipv6@ietf.org References: <151311762550.30105.15490803659981825351.idtracker@ietfa.amsl.com> <09613E79-FAA9-49DF-9997-5C4739DF360A@gmail.com> <58948F5B-3676-47C8-BAF4-1954AE04303A@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 14 Dec 2017 14:18:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <58948F5B-3676-47C8-BAF4-1954AE04303A@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 14 Dec 2017 01:18:26 -0000 On 14/12/2017 13:01, Fred Baker wrote: > https://tools.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4flag-01.txt >=20 > You're correct, it is improved. However, I still think there is a funda= mental issue in that the sets of IPv4 routers and IPv6 routers can be com= pletely disjoint, and the IPv6 routers not know about the IPv4 capabiliti= es. That can be viewed several ways - in the security considerations, you= note that it is a potential attack vector, for example. Speaking for mys= elf, I would rather have the hosts decide that there is no IPv4 service a= vailable from the fact of not having an address and being in a backoff mo= de in DHCP than from a potentially erroneous assertion in an unrelated pr= otocol. >=20 > It seems to me that the issue could be addressed by using an exponentia= l backoff in DHCP (if you don't get an answer, ask again, but wait increa= singly long), eventually stopping asking, and waiting for someone to issu= e an ARP announcement that they are using an address other than 169.254.x= =2Ex. >=20 > Would it help if I posted a draft about inferring lack of IPv4 services= from the lack of IPv4 data? Yes please. The question in my mind about the IPv4 Unavailability flag is= whether the various host heuristics in section 4 are significantly better= than what you are suggesting. In any case, all we are suggesting is additional "evidence of absence" compared to the simple absence of DHCP responses. Also, of course, the goal here is not to exorcise the demon of IPv4. It's to minimise pointless traffic and remove a potential attack vector. How can we best achieve that? Brian >=20 >> On Dec 12, 2017, at 2:33 PM, Bob Hinden wrote: >> >> Hi, >> >> Based on the discussion on the previous draft, we updated it. We thin= k this resolves many of the issues raised. The changes include: >> >> o Inverted name of flag from "Available" to "Unavailable=E2=80=9D.= >> >> o Added problem description and clarified scope. >> >> o Added router and operational considerations section. >> >> o Added host behavior considerations section. >> >> o Extended security considerations section. >> >> o Added Acknowledgment section, including reference to prior sunse= t4 draft. >> >> Please review and comment. We think this version is an improvement ov= er the -00 version. >> >> Thanks, >> Bob & Brian >> >> >> >>> Begin forwarded message: >>> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-hinden-ipv4flag-01.txt >>> Date: December 12, 2017 at 2:27:05 PM PST >>> To: "Robert M. Hinden" , "Robert Hinden" , "Brian Carpenter" >>> >>> >>> A new version of I-D, draft-hinden-ipv4flag-01.txt >>> has been successfully submitted by Robert M. Hinden and posted to the= >>> IETF repository. >>> >>> Name: draft-hinden-ipv4flag >>> Revision: 01 >>> Title: IPv6 Router Advertisement IPv4 Unavailable Flag >>> Document date: 2017-12-12 >>> Group: Individual Submission >>> Pages: 8 >>> URL: https://www.ietf.org/internet-drafts/draft-hinden-ipv= 4flag-01.txt >>> Status: https://datatracker.ietf.org/doc/draft-hinden-ipv4fla= g/ >>> Htmlized: https://tools.ietf.org/html/draft-hinden-ipv4flag-01 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-hinden-ip= v4flag-01 >>> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4= flag-01 >>> >>> Abstract: >>> This document specifies a Router Advertisement Flag to indicate tha= t >>> there is no IPv4 service on the advertising default IPv6 router. >>> This document updates RFC5175. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission >>> 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 >> -------------------------------------------------------------------- >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Wed Dec 13 18:58: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 773DF127078; Wed, 13 Dec 2017 18:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779] 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 JqnuMut3bi9i; Wed, 13 Dec 2017 18:58:44 -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 3289D124234; Wed, 13 Dec 2017 18:58:43 -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 37DDE3B549D; Thu, 14 Dec 2017 02:58:41 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id CD521160041; Thu, 14 Dec 2017 02:58:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 90E59160048; Thu, 14 Dec 2017 02:58:40 +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 Pgwk3jNcJRV2; Thu, 14 Dec 2017 02:58:40 +0000 (UTC) Received: from jmb.localhost (unknown [73.93.155.16]) by zmx1.isc.org (Postfix) with ESMTPSA id 4F75A160041; Thu, 14 Dec 2017 02:58:40 +0000 (UTC) Date: Wed, 13 Dec 2017 18:58:39 -0800 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Naveen Kottapalli Cc: Mikael Abrahamsson , "v6ops@ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA In-Reply-To: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, 14 Dec 2017 02:58:46 -0000 At Wed, 13 Dec 2017 17:41:23 +0530, Naveen Kottapalli wrote: > I got that. But am not sure on what is the use when devices don't bother > the value of that bit in RA. Effectively nothing. If you look at RFC2461 and RFC2462, you'll find behavior regarding these bits were more normative. For example, Section 5.5.3 of RFC2462 stated: [...] If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. (you should read "the stateless address autoconfiguration protocol" as DHCPv6). But when we tried to update these docs (the result is RFC4861 and RFC4862) we realized that it was not widely implemented and that it would be quite difficult to specify more sensible behavior that met people's varied opinions and preferences. IIRC those include: - some people wanted to be able to run DHCPv6 without bothering RA (technically, RFC2461/2462 didn't prohibit it, but there was a desire of making it clearer) - some people wanted to have a way to signal hosts not to use DHCPv6 (this is probably your interpretation. but even RFC2461/2462 didn't have a clear description of such a way). on a related matter, the meaning of zero-M/O bits wasn't clear (RFC2462 said hosts shouldn't stop DHCPv6 on the bit change from 1 to 0, but it didn't say anything about what it means if the bit is 0 from the beginning). - some people wanted to have a way to turn off running DHCPv6 (the original description of changing M from 1 to 0 didn't work that way) In retrospect, it was probably just a bad idea to try to control this just from these two bits. So there was also an idea of deprecating those bits. But some people didn't like the idea due to compatibility with existing implementations that rely on those bits. So, the current wording of RFC4861 (and the silence about these bits in RFC4862) was a kind of procedural compromise. I suspect no one can give a reasonable technical explanation to "what is the use of these bits?" or "why do we even have these bits if they are useless?". There have been attempts to give clearer semantics to these bits, but none of them has succeeded. That's an unfortunate situation, given that there are actually implementations that still refer to these bits. But, knowing the history I'm pessimistic about any further effort on these bits. My humble suggestion is to just accept the reality and use our time for something else. -- JINMEI, Tatuya From nobody Thu Dec 14 04:07: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 9BC43126BF0; Thu, 14 Dec 2017 04:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 PJ013V38jhJK; Thu, 14 Dec 2017 04:07:18 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 A02771200C5; Thu, 14 Dec 2017 04:07:17 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id u127so2309712lff.5; Thu, 14 Dec 2017 04:07:17 -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=xfIgRAsDB2hEeZlEVRV6MXABz5tgZ7tXU4OZEUc+2SU=; b=HZPdbYSVnW/QSqHIugMQkWVM1ipcn8n4O1m+sHzN++kQNtkKko+orwQAZQ+nv+SwYx IM1NSD3LiLsZfYYNQN7V2OFXNqcL4y3Lmw1j10HSEG+rdcE7+9bZ8Km71ELIaVMukans aw+Y3MnhXAPy0y6WVIH0YNjSaQJYcMJD2DhWcXaz8sDx8xuSR5zRV8HbDYvqGdFyOpGX SJD9EmnpsbVoTBHydU53AokO8Zw2AG22BL5+juItTOX4M8QIArTtMbgPP4o2ZjoWfkii 6O+OC0tuCEzScZng6cYT2iknsqDI4ta3uFHAX+WKc9kSp/FNs24XsatLflcRZfSMkdUm J+uw== 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=xfIgRAsDB2hEeZlEVRV6MXABz5tgZ7tXU4OZEUc+2SU=; b=Hm3M6rjml59ADsNXsB2TDvE7ut4L2Qs6+7i8J26hZc+gAdjjq7rg62LqajqNt9pefq D7EPmw3gmrtXUe9+OlUoA4Liskxgo/UbVg98vR84KTgAHewdwi/kQkYHMdUWkmCmQEM/ jXpYV3DlSaHKr1B/TrWvzEwFT0Be3cgukg0Yx4WReniVJYkUWrZ+h6C0qJoO0qKTthjJ kSqwdwdPrh/mU7TPEKM8LfNlOXQRvnwPUZjS+lidcZydg3/RgRJj2qOS0jewksInh2fQ y0GWiWwUiDaCcJ2COGwG4SEJzTrxURe3tY69WNTyVIo2Hm6XARWSijUalZrpnj4VPucD GDPQ== X-Gm-Message-State: AKGB3mICrQ39LOEXZ/y3CtaMl8KUenG/2MnQnL3v3MNXWzwFl1Mo15Vq AUCVZv/w9hcsInLyD0RCVg8Vz5nv8SQu4yqiWS4= X-Google-Smtp-Source: ACJfBoub9Jtzjeng3HtcHYheFKU1+OoTKxZdpWPdI0cKsEwFlTRGMdCmdcTrKSddwqIDeQ4sgL+VdrTAEV/XRatMHPg= X-Received: by 10.46.89.69 with SMTP id n66mr3992804ljb.26.1513253235854; Thu, 14 Dec 2017 04:07:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Thu, 14 Dec 2017 04:06:55 -0800 (PST) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Naveen Kottapalli Date: Thu, 14 Dec 2017 17:36:55 +0530 Message-ID: Subject: Re: Windows 10 doesn't honour 'M' flag in RA To: "STARK, BARBARA H" Cc: v6ops list , 6man WG Content-Type: multipart/alternative; boundary="94eb2c073aec94136605604bb93b" 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, 14 Dec 2017 12:07:20 -0000 --94eb2c073aec94136605604bb93b Content-Type: text/plain; charset="UTF-8" No harm is seen with this behaviour. Just curious on know why the protocols are designed this way where devices doesn't honour the flags sent. Yours, Naveen. On 14 December 2017 at 03:37, STARK, BARBARA H wrote: > Hi Naveen (or anyone else who cares to answer), > > > In our recent testing, we observed that Windows 10 doesn't honour 'M' > flag > > in RA. It's not just Windows 10, same behaviour is observed with latest > Mac > > OS as well. > > I'm curious: What is being harmed by this behavior? I can definitely see > advantages in Windows and Mac OS doing it this way; I'm just struggling to > understand the disadvantages. Years ago, there was a problem in some ISP > networks prior to full launch of IPv6 and prior to support for SOL_MAX_RT > (RFC 7083) of DHCPv6 servers being overwhelmed by Solicit messages they > were configured not to respond to (because IPv6 wasn't formally supported). > But with SOL_MAX_RT, that really shouldn't be an issue. So what is being > broken by this behavior now? > > Barbara > --94eb2c073aec94136605604bb93b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No harm is seen with this behaviour.=C2=A0 Just curious on= know why the protocols are designed this way where devices doesn't hon= our the flags sent.

=
Yours,Naveen.

On 14 December 2017 at 03:37, STARK, BARBARA= H <bs7652@att.com> wrote:
Hi= Naveen (or anyone else who cares to answer),

> In our recent testing, we observed that Windows 10 doesn't honour = 'M' flag
> in RA.=C2=A0 It's not just Windows 10, same behaviour is observed = with latest Mac
> OS as well.=C2=A0

I'm curious: What is being harmed by this behavior? I can defini= tely see advantages in Windows and Mac OS doing it this way; I'm just s= truggling to understand the disadvantages. Years ago, there was a problem i= n some ISP networks prior to full launch of IPv6 and prior to support for S= OL_MAX_RT (RFC 7083) of DHCPv6 servers being overwhelmed by Solicit message= s they were configured not to respond to (because IPv6 wasn't formally = supported). But with SOL_MAX_RT, that really shouldn't be an issue. So = what is being broken by this behavior now?

Barbara

--94eb2c073aec94136605604bb93b-- From nobody Thu Dec 14 06:01: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 19B851201F2; Thu, 14 Dec 2017 06:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z0dMiZulNt89; Thu, 14 Dec 2017 06:01:28 -0800 (PST) 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 F1E851200CF; Thu, 14 Dec 2017 06:01:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 920EF20090; Thu, 14 Dec 2017 09:04:48 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9B3EE81D85; Thu, 14 Dec 2017 09:01:26 -0500 (EST) From: Michael Richardson To: "STARK\, BARBARA H" cc: Naveen Kottapalli , v6ops list , 6man WG Subject: Re: Windows 10 doesn't honour 'M' flag in RA In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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: Thu, 14 Dec 2017 14:01:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable STARK, BARBARA H wrote: >> In our recent testing, we observed that Windows 10 doesn't honour 'M' >> flag in RA.=C2=A0 It's not just Windows 10, same behaviour is observ= ed with >> latest Mac OS as well.=C2=A0 > I'm curious: What is being harmed by this behavior? I can definitely I think a concern is that for a network on which there are no legitimate DHCPv6 servers (O=3D0,M=3D0), that the operator of the router(s) sending RAs don't know if the hosts will take the configuration from the RA, or the configuration from the rogue DHCPv6 server. One might think that setting M=3D0 and filtering all RAs from "access" ports that this would protect the network. But it's not the case, you need to filter DHCPv6 as well. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloyhDYACgkQgItw+93Q 3WXxOAf/fXBfvMwh2Dr7L/lejpBhsmVpVFSUvov6TxFeMz0XlwAf1lMWRgbz5g98 amboqfbnWJhQ+oowG9iY3948owOUK63J1gr8dDBtR58se5U4YxcefnZzQwCD8Xqq BzeHwr5M54bQ6n9dcrZA+VCtkRlTmc6WBtVp5kiG9d3eqECIzwAaOtWWXE5VQeY7 3zdCzbNg8X3I3jBNxAOD7gQm3aWRULe3RHfrvjS2JNSvj7qMgCvDqtap3qnWW6ZG InVVYeqhpx0Ga0TF+pTAJWPHziP9PXUdneKu1oqFr7Xr3DzrT91LgWqmJKL1/SNm krd+TjHH+Z18GS8FOxQvMtG8nKMSeg== =+4YH -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 14 14: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 CB69E126DEE for ; Thu, 14 Dec 2017 14:49:30 -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 fvWFEwUrFtAh for ; Thu, 14 Dec 2017 14:49:28 -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 6463B1242F5 for ; Thu, 14 Dec 2017 14:49:28 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id n6so4709655pfa.4 for ; Thu, 14 Dec 2017 14:49:28 -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=fL9lyZENt6kscdctANXO87labuOF5swZPWcNG5XrQkw=; b=nYmXugO0PLnckGv7f+ISFeMpPEZTmh/pQQwk4x2WOHdSKCMVbMyfNGa3UlcpTanjPQ VocFEpemm3E6CdYhX1lgWhsBEaWve86Fx4e2I4iTrqeeG1CieSVzzzUFGTNN5E2gpep9 x6qyRw9KtO1RVE3h3iEXrBlQ5WHqehbLSFxj3e2Zc6B4FtZ18tJncSBqx0Z1F9CggQgq tMNU9nU6uZXJqFJ+TMUlNOQlo0sCLv4kX88gx8fg7LbHt159DvXHtKTZ1MKtlCRr4k67 OhjvqLCj6SgstV8ZHpkvrP7ZjquMs5O3ExE9KJxcGx5v+Z8mdbkEoflbhmV+dN4n92d9 8QQg== 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=fL9lyZENt6kscdctANXO87labuOF5swZPWcNG5XrQkw=; b=Dfpj9Sxnew2eiLu82wdhWORWVjngpV7hGNDTw931SIiESpt+nqoKkfimkhCpvU0dh9 iTb3NXdw7QNfIAP7I0VPmMJVWMupRQ79PMnwA7z3q10fjK5EhMPpDpi/kig5JCbgPmzB /zrWasgxNfYdA8KS5YJofoR/pYlT988ERhhxhl/j4nhbeb6hLelVeNRN7TGbJr5wo6J+ qlII3LPWsJiVMsugQH4+O8WFJBKXtYTTOCAbpX1DtzDnb163f6/faIa2T4hrEzi75uQP ut31mLOlu9fBDNxs6ExJOQ7R2ToNgkKPKnwQGELWqC0QLXQYp1VzXEA6M88YKP5kGLK4 yfnA== X-Gm-Message-State: AKGB3mKJf0GDPWcGInGml4c94Rr/mgAv5Po5A90FDHPyDWNdvkbW+/AU X92bNLmMdnjLuEAA1CPpTb97dzx3 X-Google-Smtp-Source: ACJfBos1oBtTjcf5tGu8b1VPxwXDlxuq6jsFn14edwsUMx7r/CCHmZAl6uyZMQQAHJCgszk6xSkDxg== X-Received: by 10.84.233.8 with SMTP id j8mr11262992plk.231.1513291767592; Thu, 14 Dec 2017 14:49:27 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id n5sm8015797pgp.20.2017.12.14.14.49.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 14:49:25 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EC5A286A-ADCD-494A-B90A-D71F80E558FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-hinden-ipv4flag-01.txt Date: Thu, 14 Dec 2017 14:49:24 -0800 In-Reply-To: Cc: Bob Hinden , IPv6 List To: Brian Carpenter , Fred Baker References: <151311762550.30105.15490803659981825351.idtracker@ietfa.amsl.com> <09613E79-FAA9-49DF-9997-5C4739DF360A@gmail.com> <58948F5B-3676-47C8-BAF4-1954AE04303A@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, 14 Dec 2017 22:49:31 -0000 --Apple-Mail=_EC5A286A-ADCD-494A-B90A-D71F80E558FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Dec 13, 2017, at 5:18 PM, Brian E Carpenter = wrote: >=20 > On 14/12/2017 13:01, Fred Baker wrote: >> https://tools.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4flag-01.txt >>=20 >> You're correct, it is improved. However, I still think there is a = fundamental issue in that the sets of IPv4 routers and IPv6 routers can = be completely disjoint, and the IPv6 routers not know about the IPv4 = capabilities. That can be viewed I don=E2=80=99t have any data, but I suspect that in most cases they are = not disjoint. I think the question is this mechanism useful in the = cases where they are not disjoint and/or under unified management. >> several ways - in the security considerations, you note that it is a = potential attack vector, for example. Speaking for myself, I would = rather have the hosts decide that there is no IPv4 service available = from the fact of not having an address and being in a backoff mode in = DHCP than from a potentially erroneous assertion in an unrelated = protocol. >>=20 >> It seems to me that the issue could be addressed by using an = exponential backoff in DHCP (if you don't get an answer, ask again, but = wait increasingly long), eventually stopping asking, and waiting for = someone to issue an ARP announcement that they are using an address = other than 169.254.x.x. >>=20 >> Would it help if I posted a draft about inferring lack of IPv4 = services from the lack of IPv4 data? Yes, please do. I think the challenge ids to have it be reliable in = both the case where there isn=E2=80=99t IPv4 and the case where the host = is temporarily isolated from the IPv4 router/services. Also, how to = distinguish from a set of hosts trying to find IPv4 services vs. there = is IPv4 service. >=20 > Yes please. The question in my mind about the IPv4 Unavailability flag = is > whether the various host heuristics in section 4 are significantly = better > than what you are suggesting. In any case, all we are suggesting is > additional "evidence of absence" compared to the simple absence of = DHCP > responses. >=20 > Also, of course, the goal here is not to exorcise the demon of IPv4. > It's to minimise pointless traffic and remove a potential attack > vector. How can we best achieve that? Right, is it better to send a signal to the hosts, or have them all = figure it out themselves. Thanks, Bob >=20 > Brian >=20 >>=20 >>> On Dec 12, 2017, at 2:33 PM, Bob Hinden = wrote: >>>=20 >>> Hi, >>>=20 >>> Based on the discussion on the previous draft, we updated it. We = think this resolves many of the issues raised. The changes include: >>>=20 >>> o Inverted name of flag from "Available" to "Unavailable=E2=80=9D. >>>=20 >>> o Added problem description and clarified scope. >>>=20 >>> o Added router and operational considerations section. >>>=20 >>> o Added host behavior considerations section. >>>=20 >>> o Extended security considerations section. >>>=20 >>> o Added Acknowledgment section, including reference to prior = sunset4 draft. >>>=20 >>> Please review and comment. We think this version is an improvement = over the -00 version. >>>=20 >>> Thanks, >>> Bob & Brian >>>=20 >>>=20 >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for draft-hinden-ipv4flag-01.txt >>>> Date: December 12, 2017 at 2:27:05 PM PST >>>> To: "Robert M. Hinden" , "Robert Hinden" = , "Brian Carpenter" >>>>=20 >>>>=20 >>>> A new version of I-D, draft-hinden-ipv4flag-01.txt >>>> has been successfully submitted by Robert M. Hinden and posted to = the >>>> IETF repository. >>>>=20 >>>> Name: draft-hinden-ipv4flag >>>> Revision: 01 >>>> Title: IPv6 Router Advertisement IPv4 Unavailable Flag >>>> Document date: 2017-12-12 >>>> Group: Individual Submission >>>> Pages: 8 >>>> URL: = https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-01.txt >>>> Status: = https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/ >>>> Htmlized: = https://tools.ietf.org/html/draft-hinden-ipv4flag-01 >>>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-01 >>>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4flag-01 >>>>=20 >>>> Abstract: >>>> This document specifies a Router Advertisement Flag to indicate = that >>>> there is no IPv4 service on the advertising default IPv6 router. >>>> This document updates RFC5175. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=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=_EC5A286A-ADCD-494A-B90A-D71F80E558FD 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 iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloy//QACgkQrut0EXfn u6iI8gf/V/zU7aqPnnNivaTkasfFxyT1aNXKRgIr1v8g98ee+S2tj6HVsXwUE4Yi f6jYL4ulC4mEZAcIGhpys6fiGipsPm5aNR6G3vMdh9whenUeXraBlXFBrdUbFeI8 MxCuLnraoswv+0sybFRzpOReQcbZZ3BMMwkftVZ3z6BbtqxuUhxKzRh+MVcs3Wfm PBs8bIk/VCwnFiaDyJPMvN7s5HO1fAOBm6/bK71MdlL68pB1FSqWD7UfzIwZhZ1H sP5v3joeq7bPZMnTpkr3T0/kcKDqgh/6ZVcJBtW2hYMh5JFUUVEvyhHvaVphEF87 8z4MY+sZdaQktgjxwLzVco7WrKIPvw== =J5nc -----END PGP SIGNATURE----- --Apple-Mail=_EC5A286A-ADCD-494A-B90A-D71F80E558FD-- From nobody Thu Dec 14 15:15: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 912C01270AE for ; Thu, 14 Dec 2017 15:15:27 -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 z0_sD9YoBqT2 for ; Thu, 14 Dec 2017 15:15:26 -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 0EE4E127005 for ; Thu, 14 Dec 2017 15:15:26 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id u25so4753789pfg.5 for ; Thu, 14 Dec 2017 15:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=206HziOr++kx2KkTnqqIbbXGLPP54acXh9wVuLhD5nU=; b=OTibahp2RAZPfoyI+tIW1zFJ1aMOnYqEnaEjv0+rkb4GfoAxXG2+Cjd6RB5HrPTkFe 1VZcfkfVEyleFAxXRJsbI1Rt2Hgrm5658M0EgXjTxDxANC/pXzlI2xwhzi+gY9oX0Gxv eNGPT11f0u4pq2gTJTbF2el3coUVj6pVLicec1KPnCbeOk9dYHgq5cATXQMZonUb2/Ps SmB2BzcvkqcVk548ypIEDUBa/EC65/0rL3WO0gI4aHYb7mEuRbHjqaUrx0jHKJurZehe hS/4r+f3BYEOgTUnSfwQT/iG5KvFZTagCHKfYbr2kgHPdmQEfAfp5Nc1bR0vWEWjkH92 LS2w== 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:cc:to :message-id; bh=206HziOr++kx2KkTnqqIbbXGLPP54acXh9wVuLhD5nU=; b=Kzn6iQ04ambCjTP6L7a/q1f6lY7Ww2r+/4UVhR+g7ronco1bySP+Q6nOHn6rjY5jn4 ObSQs2xJy8IPWfDr3LPYV0fz+a2PSNTR4LkQs61NGsIj26iaCwv4uvbFc1Vs+CyeDLyc dFBDGyTCOUlcrOr+qS5PgT9HlkQajNIfL1N5QcLPzg2rTPjRwobdW6KIabikfu3KCQeA GW8By3B6ryS9HGVbhR3tkFFpvTnP8kDxiZpBYnY64c4g2VOoQbiJ9Sr6f/DUaMiogmfB 2F3v6uZ2TUh1m7PAjqqxnSoIVxO0D63ZojG4NB8vFS6ujc8AydSjSgRT37HiOfOvZwxD VUrQ== X-Gm-Message-State: AKGB3mJ7Jbp8fCsrOJm5uLcGjuGPrYksGPJzAh74UvfApRZZEVbsBtLx rmgU8SdrMbkJGnJmlbtGI+zapxFR X-Google-Smtp-Source: ACJfBosNgdEgsjUWDzRWAW4er6Eb3WYdwFYGvzkw5gwsRuT9LClmYWNcvRZLAtuuz1o9JrsHOwBPHg== X-Received: by 10.84.240.68 with SMTP id h4mr11096904plt.431.1513293325087; Thu, 14 Dec 2017 15:15:25 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c191sm10054962pfg.24.2017.12.14.15.15.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 15:15:24 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_BBAF9D0C-3842-4321-9575-6F5D992572A5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 6man w.g. last call for Date: Thu, 14 Dec 2017 15:15:22 -0800 References: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> Cc: Bob Hinden To: IPv6 List Message-Id: 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, 14 Dec 2017 23:15:27 -0000 --Apple-Mail=_BBAF9D0C-3842-4321-9575-6F5D992572A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This message starts a three week 6MAN Working Group Last Call on = advancing: Title : IPv6 ND PIO Flags IANA considerations Author : Ole Tr=C3=B8an Filename : draft-ietf-6man-ndpioiana-00.txt Pages : 3 Date : 2017-12-06 https://tools.ietf.org/html/draft-ietf-6man-ndpioiana-00 as a Proposed Standard. Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the author. This last call will end on 5 January 2018. Thanks, Bob --Apple-Mail=_BBAF9D0C-3842-4321-9575-6F5D992572A5 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 iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlozBgsACgkQrut0EXfn u6g98gf/WsD3kPmPnMi/TPgcbH0GnuiSY7oOjgDy3hK6lQV3ytCACQ0EusEOHEaI jkU2PLtlQSx5d+u91gU8WfBtqa2w/j19axYyDUMkIKFVOpQreIyxPNy/4haOW4cC 4uxfqEUI59hOvrpOoqZBWTcHfUlkvFBvugRCoyPxDmBvUuqcDyDFAIqkWkk5iszZ E3AWZ/GoWg1e1DvCu6iaTd3wZV4Ots+wAI4eMj/ET9Zf8hWJ3dOw1or0SzH/FQx0 uk2lQ9yYw1qI0pLtG6ja+8fYypNFvLxWYRLELVPr1yLO1FyCa6lWvnQGuWIiaAvJ YS4cGu95W1KLK0JMDx1fkf5+6/mDIw== =n0bz -----END PGP SIGNATURE----- --Apple-Mail=_BBAF9D0C-3842-4321-9575-6F5D992572A5-- From nobody Thu Dec 14 15:36: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 94DA8127B73 for ; Thu, 14 Dec 2017 15:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, 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 zPUudbi6Nqwu for ; Thu, 14 Dec 2017 15:36:33 -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 01C96120725 for ; Thu, 14 Dec 2017 15:36:33 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 8AB39578 for ; Thu, 14 Dec 2017 23:36:32 +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 o7YCRqR7Pjjy for ; Thu, 14 Dec 2017 17:36:32 -0600 (CST) Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) (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 F3F9293D for ; Thu, 14 Dec 2017 17:36:31 -0600 (CST) Received: by mail-lf0-f69.google.com with SMTP id m35so1778676lfi.9 for ; Thu, 14 Dec 2017 15:36:31 -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=LSDWd1P1uT5/6y/h2OdQ1+PCtTFEixaRsl4M0y7ecqk=; b=XwP49B8pMJd/aCI+/OU9NttyRfUc/JhY0SCqhEgVDOrHRp5Z3gUNIP9uLg+JV5rPEW WMY4SFiNi2bB1/IcKfMf/ASvZ4I0EphmfF9BHn/C6z3gars1VkVJu+2n+zuzW+rWfhVd 5zWNqiwpYpsIVi4N8y72CAYLkJQnHOCTM0d8cDS74EqhIT5ix2cIwIbfguVpVm+CKyXl HEzF7G3KgdYqA2M+jgDfcHiZMQdytqAObVK7xOCKSY0H+pejReBZ92onfbPyDikMr+dP tYGwBfoOREX4F2ikK6z9HF8dRfoxr0cxF+s9hUaUGuH4J/SFmBZ+CvnUT4RcYE/bocZo NchQ== 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=LSDWd1P1uT5/6y/h2OdQ1+PCtTFEixaRsl4M0y7ecqk=; b=P6STOWQiSCVJL+j5Lwe+7aiWDVHjrboioiHgqV4WVA7UQEByFOL0RHw4188/h6K0ZL iuCbRlBIJKxTZSqHrXn06YyhzJPRzBUbm2o7baUAKGO9LkIs4g0HYOm1EtJh+c69dLWH 6BHdalPpBu110BT7fmHScgDe6oG51hjqNy5oltpSrZpixPuHCJBkuPQvlIlaRE2yjYP9 +IVm+haLXi6RSrPuB3v0xuFPnToDyPAcdRuLtaj85ckwBFXIoWS4GpcPyGble4R/cCn3 Sj17MVQv4p2TP69n4wXWVtQF/A68uE9fG9tU4P74Zp0BMLTeamPMT54OSbl+lNIXVI++ +TJg== X-Gm-Message-State: AKGB3mJ4gzsp1HslpCkbCt6twCErOmIp9hNuXiYHgPY42cZO8AV16vh4 Gxmmq53dD+482pfkzEkpHcZHSAKDE6n7B5Q2BVkXXcLyFDkhcfIqNYrCTpChxyZ0ATgYlOufXbe DTd1gA7/Dr+022ExIFQiYN3+n X-Received: by 10.25.215.27 with SMTP id o27mr4874898lfg.51.1513294590381; Thu, 14 Dec 2017 15:36:30 -0800 (PST) X-Google-Smtp-Source: ACJfBovC3QHtDEM4B4vJ6nIhpTyMbu6dsZ4juXl0JgMRAzvJX5ZXRa62YFDJhSv7QsgI5sXd+tK3ugCAHnVLBYpjOHk= X-Received: by 10.25.215.27 with SMTP id o27mr4874890lfg.51.1513294590126; Thu, 14 Dec 2017 15:36:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.87.83 with HTTP; Thu, 14 Dec 2017 15:36:28 -0800 (PST) In-Reply-To: References: <151311762550.30105.15490803659981825351.idtracker@ietfa.amsl.com> <09613E79-FAA9-49DF-9997-5C4739DF360A@gmail.com> <58948F5B-3676-47C8-BAF4-1954AE04303A@gmail.com> From: David Farmer Date: Thu, 14 Dec 2017 17:36:28 -0600 Message-ID: Subject: Re: New Version Notification for draft-hinden-ipv4flag-01.txt To: Bob Hinden Cc: Brian Carpenter , Fred Baker , IPv6 List Content-Type: multipart/alternative; boundary="001a1140db687c47bf0560555ab9" 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, 14 Dec 2017 23:36:35 -0000 --001a1140db687c47bf0560555ab9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2017 at 4:49 PM, Bob Hinden wrote: > Hi, > > > On Dec 13, 2017, at 5:18 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > > On 14/12/2017 13:01, Fred Baker wrote: > >> https://tools.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4flag-01.txt > >> > >> You're correct, it is improved. However, I still think there is a > fundamental issue in that the sets of IPv4 routers and IPv6 routers can b= e > completely disjoint, and the IPv6 routers not know about the IPv4 > capabilities. That can be viewed > > I don=E2=80=99t have any data, but I suspect that in most cases they are = not > disjoint. I think the question is this mechanism useful in the cases whe= re > they are not disjoint and/or under unified management. > > >> several ways - in the security considerations, you note that it is a > potential attack vector, for example. Speaking for myself, I would rather > have the hosts decide that there is no IPv4 service available from the fa= ct > of not having an address and being in a backoff mode in DHCP than from a > potentially erroneous assertion in an unrelated protocol. > >> > >> It seems to me that the issue could be addressed by using an > exponential backoff in DHCP (if you don't get an answer, ask again, but > wait increasingly long), eventually stopping asking, and waiting for > someone to issue an ARP announcement that they are using an address other > than 169.254.x.x. > >> > >> Would it help if I posted a draft about inferring lack of IPv4 service= s > from the lack of IPv4 data? > > > Yes, please do. I think the challenge ids to have it be reliable in both > the case where there isn=E2=80=99t IPv4 and the case where the host is te= mporarily > isolated from the IPv4 router/services. Also, how to distinguish from a > set of hosts trying to find IPv4 services vs. there is IPv4 service. > I agree, at the very least we need to fully consider both options. > > Yes please. The question in my mind about the IPv4 Unavailability flag = is > > whether the various host heuristics in section 4 are significantly bett= er > > than what you are suggesting. In any case, all we are suggesting is > > additional "evidence of absence" compared to the simple absence of DHCP > > responses. > > > > Also, of course, the goal here is not to exorcise the demon of IPv4. > > It's to minimise pointless traffic and remove a potential attack > > vector. How can we best achieve that? > > Right, is it better to send a signal to the hosts, or have them all figur= e > it out themselves. > I believe neither will be a universal solution, but I wonder if we can get close to a universal solution if we do both. Fundamentally, I believe a host has to determine for itself if IPv4 is available or not. But, I see nothing wrong with providing some bread crumbs to help the host make the correct determination. 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 --001a1140db687c47bf0560555ab9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 14, 2017 at 4:49 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
H= i,

> On Dec 13, 2017, at 5:18 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> On 14/12/2017 13:01, Fred Baker wrote:
>> https://tools.ietf.org/rfcdiff?url2=3Ddraft-hinden-ipv4flag-01.txt
>>
>> You're correct, it is improved. However, I still think there i= s a fundamental issue in that the sets of IPv4 routers and IPv6 routers can= be completely disjoint, and the IPv6 routers not know about the IPv4 capab= ilities. That can be viewed

I don=E2=80=99t have any data, but I suspect that in most cases they are no= t disjoint.=C2=A0 I think the question is this mechanism useful in the case= s where they are not disjoint and/or under unified management.

>> several ways - in the security considerations, you note that it is= a potential attack vector, for example. Speaking for myself, I would rathe= r have the hosts decide that there is no IPv4 service available from the fa= ct of not having an address and being in a backoff mode in DHCP than from a= potentially erroneous assertion in an unrelated protocol.
>>
>> It seems to me that the issue could be addressed by using an expon= ential backoff in DHCP (if you don't get an answer, ask again, but wait= increasingly long), eventually stopping asking, and waiting for someone to= issue an ARP announcement that they are using an address other than 169.25= 4.x.x.
>>
>> Would it help if I posted a draft about inferring lack of IPv4 ser= vices from the lack of IPv4 data?


Yes, please do.=C2=A0 I think the challenge ids to have it be reliable in b= oth the case where there isn=E2=80=99t IPv4 and the case where the host is = temporarily isolated from the IPv4 router/services.=C2=A0 Also, how to dist= inguish from a set of hosts trying to find IPv4 services vs. there is IPv4 = service.

I agree, at the very least we = need to fully consider both options.=C2=A0
=C2=A0
> Yes please. The question in my mind about the IPv4 Unavailability flag= is
> whether the various host heuristics in section 4 are significantly bet= ter
> than what you are suggesting. In any case, all we are suggesting is > additional "evidence of absence" compared to the simple abse= nce of DHCP
> responses.
>
> Also, of course, the goal here is not to exorcise the demon of IPv4. > It's to minimise pointless traffic and remove a potential attack > vector. How can we best achieve that?

Right, is it better to send a signal to the hosts, or have them all figure = it out themselves.

I believe neither wi= ll be a universal solution, but I wonder if we can get close to a universal= solution if we do both.

Fundamentally, I believe = a host has to determine for itself if IPv4 is available or not.=C2=A0 But, = I see nothing wrong with providing some bread crumbs to help the host make = the correct determination.=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 & Telecommunicat= ion 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: 6= 12-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
--001a1140db687c47bf0560555ab9-- From nobody Thu Dec 14 21:50: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 C4A2C126B7E for ; Thu, 14 Dec 2017 21:50:30 -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=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 KZ4v0X8IOwDK for ; Thu, 14 Dec 2017 21:50:28 -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 556E21241F5 for ; Thu, 14 Dec 2017 21:50:28 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BB2B9B1; Fri, 15 Dec 2017 06:50:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1513317025; bh=Bz8wmAtqBcWjt0c6iTOBoQ4zqvQEsEFSdav5T1CFG/o=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UUSeBnLeFE3a5NTp4lTrXt+HW+UNO+K/moixW4Sod5BlEDjTcuYVzaIF5muyAjhwc HIvsmMwOQB3auXCWRo7c7jhmryfnfiZe277qvwCVGsLEYViiNUwRCLRePbV3odfBDL 1kAtSqCFIdNUanOA7WtXq8V0bZirffMpAJcZ0fW8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A3F15AF; Fri, 15 Dec 2017 06:50:25 +0100 (CET) Date: Fri, 15 Dec 2017 06:50:25 +0100 (CET) From: Mikael Abrahamsson To: Bob Hinden cc: IPv6 List Subject: Re: 6man w.g. last call for In-Reply-To: Message-ID: References: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-636679191-1513317025=:8884" 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, 15 Dec 2017 05:50:31 -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-636679191-1513317025=:8884 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 14 Dec 2017, Bob Hinden wrote: > This message starts a three week 6MAN Working Group Last Call on advancing: > > Title : IPv6 ND PIO Flags IANA considerations > Author : Ole Trøan > Filename : draft-ietf-6man-ndpioiana-00.txt > Pages : 3 > Date : 2017-12-06 > > https://tools.ietf.org/html/draft-ietf-6man-ndpioiana-00 > > as a Proposed Standard. Substantive comments and statements of support > for publishing this document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will > end on 5 January 2018. I support this to be progressed. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-636679191-1513317025=:8884-- From nobody Fri Dec 15 08:19: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 E9B77124205 for ; Fri, 15 Dec 2017 08:19:16 -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 JTUvjaK-Ell7 for ; Fri, 15 Dec 2017 08:19:15 -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 7AED0120227 for ; Fri, 15 Dec 2017 08:19:15 -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 vBFGJDfQ016824; Fri, 15 Dec 2017 09:19:13 -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 vBFGJ3AG016709 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Dec 2017 09:19:03 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 15 Dec 2017 08:19:02 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Fri, 15 Dec 2017 08:19:02 -0800 From: "Templin, Fred L" To: Bob Hinden , IPv6 List Subject: RE: 6man w.g. last call for Thread-Topic: 6man w.g. last call for Thread-Index: AQHTdTF2JFPvU6wN/kWhsF4yNPlfo6NElkpA Date: Fri, 15 Dec 2017 16:19:02 +0000 Message-ID: References: <20160428004904.25189.43047.idtracker@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-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, 15 Dec 2017 16:19:17 -0000 U3VwcG9ydCBmb3IgcHJvZ3Jlc3NpbmcgdGhpcyB3b3JrLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBCb2IgSGluZGVuDQo+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxNCwgMjAx NyAzOjE1IFBNDQo+IFRvOiBJUHY2IExpc3QgPGlwdjZAaWV0Zi5vcmc+DQo+IENjOiBCb2IgSGlu ZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT4NCj4gU3ViamVjdDogNm1hbiB3LmcuIGxhc3QgY2Fs bCBmb3IgPGRyYWZ0LWlldGYtNm1hbi1uZHBpb2lhbmE+DQo+IA0KPiBUaGlzIG1lc3NhZ2Ugc3Rh cnRzIGEgdGhyZWUgd2VlayA2TUFOIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIGFkdmFuY2lu ZzoNCj4gDQo+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogSVB2NiBORCBQSU8gRmxhZ3MgSUFO QSBjb25zaWRlcmF0aW9ucw0KPiAgICAgICAgIEF1dGhvciAgICAgICAgICA6IE9sZSBUcsO4YW4N Cj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtNm1hbi1uZHBpb2lhbmEtMDAudHh0DQo+ IAlQYWdlcyAgICAgICAgICAgOiAzDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTEyLTA2DQo+ IA0KPiAgICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4t bmRwaW9pYW5hLTAwDQo+IA0KPiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkLiAgU3Vic3RhbnRpdmUg Y29tbWVudHMgYW5kIHN0YXRlbWVudHMgb2Ygc3VwcG9ydA0KPiBmb3IgcHVibGlzaGluZyB0aGlz IGRvY3VtZW50IHNob3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgbWFpbGluZyBsaXN0Lg0KPiBFZGl0 b3JpYWwgc3VnZ2VzdGlvbnMgY2FuIGJlIHNlbnQgdG8gdGhlIGF1dGhvci4gIFRoaXMgbGFzdCBj YWxsIHdpbGwNCj4gZW5kIG9uIDUgSmFudWFyeSAyMDE4Lg0KPiANCj4gVGhhbmtzLA0KPiBCb2IN Cj4gDQoNCg== From nobody Fri Dec 15 08:42: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 CCD34126C83 for ; Fri, 15 Dec 2017 08:42:51 -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 L7-FV_p74CYX for ; Fri, 15 Dec 2017 08:42:50 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 B31AD1293EC for ; Fri, 15 Dec 2017 08:42:45 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id y82so31334962wmg.1 for ; Fri, 15 Dec 2017 08:42:45 -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=vLfMjuyAfMYDq1RnBDU6rq1FtakH7phcYEkuEHrb6OU=; b=E5x26VpWqqdAzorp7cIBd6MZrxf7QgyTZJFYQnSzooH538ZRmmNWTYCb7qFpi177QF PAH/Hmk1bhw1smM12JO71zLaZCveuWx0pJjdmEXu21Fa/MJTnI3CT13QNFX53zNdEpte cUklBW25krRlAwVCNcYlKugsrU8MS9uetNu2IWUmuLErjw+ATBnmDyHW3mJlDXohUPd7 BsL4l1o83WUPQgzmZicVpz5k/aWoKoTTO0fJOFd5KMjhhcDmNGpb2eWknWfD4Wn52Tf3 BfjHspl0vsHa6AdcxpW/5SFNiYgDBVej3Wez5iBg2HbFpLe/sLPZ822iV68McnT5/SsS 7WAQ== 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=vLfMjuyAfMYDq1RnBDU6rq1FtakH7phcYEkuEHrb6OU=; b=aqwPAy13JlErAoB837YVLH9DBC8MQ3qtMU3x3S1Tv4S9e2HFWM1782gDVUaoULqD5z L1pP4rSEj2QjZ4kKLkKsX0rAAc5U5wvmXnpWyh7uJy4x5OFmeHcUTynTWvI1fF2YlEYD JSOVMmeNitFCs1EWB5RUyADu9RPzQJ21FxLnaddBS8QhzHHedhvYhTobcfLUeLutRauu V93PssGc7AxqjvTFWkogM13uzCuGf9D2TSVI2YaReKRU47Y5vnGd3CgNzGAa89pLNfVj 0ehVftZ/py5nU+wMlvK2+74xGszF93gZmE/aZ5TY5XepfV8WCeht4+xZKngQN0rwfarf XeNw== X-Gm-Message-State: AKGB3mI9QTViH2twG3Mkxc3rTAXs1CJOX/MpmlgBSDJhpyn7piPJQsFt mYxVGlzI22OiInpHxr+BTmmWBp6U X-Google-Smtp-Source: ACJfBoseUKX8kDrkAxMfN/Ao5wl6pYep6ksuWVaeN+zKnQx/xrC33yhedfmTa6LvHa+KVwsUVphWHg== X-Received: by 10.28.28.5 with SMTP id c5mr5787932wmc.115.1513356163965; Fri, 15 Dec 2017 08:42:43 -0800 (PST) Received: from ?IPv6:2601:647:4d01:db10:14c7:1a91:e4c7:e736? ([2601:647:4d01:db10:14c7:1a91:e4c7:e736]) by smtp.gmail.com with ESMTPSA id m134sm4230699wmg.6.2017.12.15.08.42.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 08:42:37 -0800 (PST) From: Bob Hinden Message-Id: <8074AEDC-A215-42D0-9F4A-C4AE1A0DD475@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7BC6EEB4-40CC-423F-B54A-DD7D98B1C00D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: 6man w.g. last call for Date: Fri, 15 Dec 2017 08:42:33 -0800 In-Reply-To: Cc: Bob Hinden To: IPv6 List References: <20160428004904.25189.43047.idtracker@ietfa.amsl.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: Fri, 15 Dec 2017 16:42:52 -0000 --Apple-Mail=_7BC6EEB4-40CC-423F-B54A-DD7D98B1C00D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 With no hats on, I support it as well. One comment. In Section 3. "Updates to RFC4861=E2=80=9D says: This document updates RFC4861 with the new IANA Considerations section specified below. Given that IANA considerations are to tell IANA to take an action, I = don=E2=80=99t think this is correct. I think something like the = following would be better: 3. Updates to RFC4861 This document updates Section 4.6.2 "Prefix Information=E2=80=9D of = RFC4861 to point to the new IANA registry that is created in this document. = Specifically: The current list of flags in the Prefix Information Option can be found in [IANA-TBD]. I think this is the intent of the update. Thanks, Bob > On Dec 14, 2017, at 3:15 PM, Bob Hinden wrote: >=20 > This message starts a three week 6MAN Working Group Last Call on = advancing: >=20 > Title : IPv6 ND PIO Flags IANA considerations > Author : Ole Tr=C3=B8an > Filename : draft-ietf-6man-ndpioiana-00.txt > Pages : 3 > Date : 2017-12-06 >=20 > https://tools.ietf.org/html/draft-ietf-6man-ndpioiana-00 >=20 > as a Proposed Standard. Substantive comments and statements of = support > for publishing this document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will > end on 5 January 2018. >=20 > Thanks, > Bob >=20 >=20 --Apple-Mail=_7BC6EEB4-40CC-423F-B54A-DD7D98B1C00D 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 iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloz+3kACgkQrut0EXfn u6h6hAf9GFLhkGRpQT+Hf+DnrdRGp5ZieN6NRybbTsxHu5HLsnv7mlXUQ+PqxijF VgAFRh7IVivLficE5lJVtkC3zjVlO3T7GotM4UpbqZihP9kmHpIg57CSwLxlbxCw OtlmzAlXwIhdopL5elq2eYJAGm6L/xAEWpvorHj/51iq9LRZ/BGhcvWpCKnZvpvc 7xbDsvROHv96zJUdxeLUDqs1knq4ThFVKnX6YIUIwdRECfXveI+AVA5DNVLQ5G/0 ff7BkDKQoNhrnEcUokdxcSJJmZ/Hma4HL38oVRM21f48FPDDEU6xOHgTPD5hcOJg zh8QHiXaa01TdwTS8ESY/pEwa6RtLg== =85qV -----END PGP SIGNATURE----- --Apple-Mail=_7BC6EEB4-40CC-423F-B54A-DD7D98B1C00D-- From nobody Fri Dec 15 12:23: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 1C6F6124F57 for ; Fri, 15 Dec 2017 12:23:52 -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 dcRGLXjYYq8b for ; Fri, 15 Dec 2017 12:23:49 -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 7536A124D6C for ; Fri, 15 Dec 2017 12:23:49 -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 vBFKNkKY018642 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Dec 2017 20:23:46 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: <5A342F51.80908@foobar.org> Date: Fri, 15 Dec 2017 20:23:45 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.22 (Macintosh/20171208) MIME-Version: 1.0 To: Bob Hinden CC: IPv6 List Subject: Re: 6man w.g. last call for References: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.2.3 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: Fri, 15 Dec 2017 20:23:52 -0000 Bob Hinden wrote: > This message starts a three week 6MAN Working Group Last Call on advancing: > > Title : IPv6 ND PIO Flags IANA considerations > Author : Ole Trøan > Filename : draft-ietf-6man-ndpioiana-00.txt > Pages : 3 > Date : 2017-12-06 > > https://tools.ietf.org/html/draft-ietf-6man-ndpioiana-00 > > as a Proposed Standard. Substantive comments and statements of support > for publishing this document should be directed to the mailing list. > Editorial suggestions can be sent to the author. This last call will > end on 5 January 2018. This seems like a sensible idea. Support. Nick From nobody Sun Dec 17 02:38: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 0D5DD126C22 for ; Sun, 17 Dec 2017 02:38:24 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 ad3-rgIMaHE1 for ; Sun, 17 Dec 2017 02:38:22 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F14126557 for ; Sun, 17 Dec 2017 02:38:21 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 016E458C4C0 for ; Sun, 17 Dec 2017 11:38:18 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id DE409B0D4A8; Sun, 17 Dec 2017 11:38:17 +0100 (CET) Date: Sun, 17 Dec 2017 11:38:17 +0100 From: Toerless Eckert To: ipv6@ietf.org Subject: rfc4007 implementation question Message-ID: <20171217103817.GA27808@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, 17 Dec 2017 10:38:24 -0000 Figure 1 of RFC4007 shows an example where a single link2 is attached to two interfaces - interface2, interface3. This is the one case we interface zones are different from link zones. Are there any implementations that suport this model directly ? Aka: Where a zone_id for the link scope would have no 1:1 equivalent interface id (or name) ? The implementations i have seen to support this case are all based on the creation of some virtual interface, then map the two underlying (physical) interfaces into it, and then the interface id of that virtual interface would map 1:1 to the link scope zone_id. And in result it seems interface IDs are used interchangeably with link scope zone_ids... Thanks --- tte@cs.fau.de From nobody Sun Dec 17 10:42: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 C24611243FE for ; Sun, 17 Dec 2017 10:42:24 -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 JButFPdTdYo7 for ; Sun, 17 Dec 2017 10:42:23 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 E6645124319 for ; Sun, 17 Dec 2017 10:42:22 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id g7so8308143pgs.0 for ; Sun, 17 Dec 2017 10:42:22 -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-language:content-transfer-encoding; bh=TJhRvtwwIorKWruwGN0cyLriFHXv5PVcwdi0RYsNKsg=; b=eW2nPzwsm5i5b8XHQ/kYW3crATGZ3ruSlqC+RqI6ZzE/frgMWpJ1X1wTww/GMmUD24 OtV3wG+wr1hozXizTEVNt08K1EwXbH+silPlKX2b0udDJW2gc8rPRI3hZokjn1Bsx4Bl GZS2BxorBfCDnI6q8xNfI4YW2wgHWs2GiicaHk9sFpiBWcRdiE3S3/TMwsSMgtDGFmaY jh+5t6EmZyaKU+nHBvjbTfPUCpv5BItHyZyYYIKKM/nygHEKGu+iLbIQV7zvwlqA4zRi eiVXO6C1JHc3MfuZCvTbwBY2QZZAvCKfQe0D5TD6r7ElzF4j7SqSck2CENbgsO5CIGF9 hmGw== 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-language:content-transfer-encoding; bh=TJhRvtwwIorKWruwGN0cyLriFHXv5PVcwdi0RYsNKsg=; b=MXLa23ldJFYrn7JT79PdJqmAfmbpKIBjZGNzgB8hoeTWPZS3eDWNvPnEv7usmrcjiI XDcUxhb6ZqhaDWeG+J1bwGNvQYuPn0DdMl7+TVvrlDrLIfhgjnM+TCTwU+vmAzFpSpGC tS5g8MTulf7cPW9bK+jEHFiMnavb7SWb/ZOMkxuEV2PNspJpP/x0NVtOnY/hUI8UU7Fp yburx0T059YA68YqKquZPP0+2PcMstjdLAMJGQf/3dSQwt8cjW53/Nc8paO+vhvyHjr9 TnQrHQaYQTbQcy7gfLrDh1UwbDrm9rrjflWCJLwZqeBtj8ALiu4aen3FtJm/VFszIHlP k5iA== X-Gm-Message-State: AKGB3mINPlwLXITSRmJ1Au9cZIN32sMPgNOsyLysIfGTT3xzeg3GlEmE aUsYRMG6C5MDmsSrqONC20X2Fw== X-Google-Smtp-Source: ACJfBosoZj9it3AceI0N1+hZ8In69AMnEHr7EbMBhp7qVELtvNy8k7+vk1D8rW9mcm11O/f2yVRAMg== X-Received: by 10.99.150.9 with SMTP id c9mr17629754pge.386.1513536142182; Sun, 17 Dec 2017 10:42:22 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q74sm21116979pfd.134.2017.12.17.10.42.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Dec 2017 10:42:20 -0800 (PST) Subject: Re: rfc4007 implementation question To: Toerless Eckert , ipv6@ietf.org References: <20171217103817.GA27808@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 18 Dec 2017 07:42:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171217103817.GA27808@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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, 17 Dec 2017 18:42:25 -0000 Apart from anything else, there seems to be no way to represent the "link index" described in RFC4007 in the socket API, which explicitly supports interface indexes. So even if a stack internally separates the two concepts as described in RFC4007, there seems to be no way to communicate this outside the stack. Regards Brian On 17/12/2017 23:38, Toerless Eckert wrote: > Figure 1 of RFC4007 shows an example where a single link2 is > attached to two interfaces - interface2, interface3. This is > the one case we interface zones are different from link zones. > > Are there any implementations that suport this model directly ? > Aka: Where a zone_id for the link scope would have no 1:1 equivalent > interface id (or name) ? > > The implementations i have seen to support this case are all based on the > creation of some virtual interface, then map the two underlying (physical) > interfaces into it, and then the interface id of that virtual interface > would map 1:1 to the link scope zone_id. And in result it seems > interface IDs are used interchangeably with link scope zone_ids... > > Thanks > --- > tte@cs.fau.de > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Dec 18 11:24: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 15BD7126BF6 for ; Mon, 18 Dec 2017 11:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 KIHNyFm_21WU for ; Mon, 18 Dec 2017 11:24:46 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 AB8B7120454 for ; Mon, 18 Dec 2017 11:24:45 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id v21so4682763wrc.0 for ; Mon, 18 Dec 2017 11:24:45 -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=U2k3u7FxWqQ1knZG2+olDSF1GWRYxcW5t7lD13YOzGk=; b=ETOq7wtxnkdIZtldo+H6DXXJtIyrQ5KBL1MDoM5eTDlGHWBZiEXqz35c/24HBr2pVW MNMqQOpqYpsBEZgR/hRMcCLizuRIvUUcifm6/Uc8en/uZlAqZ+BQj9hxdxHlLAa1FAK6 MzZPip8PDtGoMuOypyQvT2Su6iCwllUjXjkSt4/3UXoMvIc9GbLjHJpWY1epcuPTLd80 rvFwKE+PnKCWXBB/gUZ3mjVAzY8spuUjAQe5RHSjPk2vqHkhNsecBW7V7A5+RfTAmOmZ WgvUUuwlVRouM27ya0cBmAaECrQkh789OLVw+KRjgITiw/XPZazERMKNySEZLAaDVQPD jqdg== 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=U2k3u7FxWqQ1knZG2+olDSF1GWRYxcW5t7lD13YOzGk=; b=m23sNhB38t4MCzy5qTLMZEh3lgzr+/V6BEvH/lIXK1E6zTKVR2SgSuydLDCQRiHBec LY0oQ4J+5Z0/AKUYQbtSeTE+xFZiI7TbHdtjoQfsjgLUpDvHJ61gUePibX8Wnt+z63A/ 2Lo3jMmK2FjXDb9gxVSIX60/Qpfl8kPGZ187O1xXgvGF3BN04gCpMJ7Jf/VdRavgLJR9 IxW0RKA9lka3/aXSBjHQx/alkvCdQUM/R05Wdh3bPWqeWsI3VnxGv/NY/Q2lBBi/hMmq 6gGLmRl0xWXZJu0oRPbV9fX8lwQDafqj0e48y0q6VBG9X4F36ZIgbIyjRfueOT1wSI87 8r+g== X-Gm-Message-State: AKGB3mLn+KVwZY8irwvesdXvBf5OSo+IoXXITkZDzxiNfr2Ti1sX67ZR mr96lJohD20S0JXt/YbTsGVhU3PMDdp0v6PZGekHh89P X-Google-Smtp-Source: ACJfBouZdXhAyUj2wuef3LioXFo2yRrZTDbHpwBMwC993Okvs1gRdz5hlyTZUZmn0uGf+tLDR5YtFPseNBWpYQWfmj8= X-Received: by 10.223.196.6 with SMTP id v6mr1161889wrf.236.1513625083966; Mon, 18 Dec 2017 11:24:43 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.142.10 with HTTP; Mon, 18 Dec 2017 11:24:43 -0800 (PST) In-Reply-To: References: <20171217103817.GA27808@faui40p.informatik.uni-erlangen.de> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 18 Dec 2017 11:24:43 -0800 X-Google-Sender-Auth: GgzUTec3v7TXHLTWa6BbWmQrG38 Message-ID: Subject: Re: rfc4007 implementation question To: Brian E Carpenter Cc: Toerless Eckert , 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: Mon, 18 Dec 2017 19:24:47 -0000 At Mon, 18 Dec 2017 07:42:15 +1300, Brian E Carpenter wrote: > Apart from anything else, there seems to be no way to represent > the "link index" described in RFC4007 in the socket API, which > explicitly supports interface indexes. So even if a stack What do you mean by this? sockaddr_in6::sin6_scope_id has a generic name, and, *in theory* we should be able to set it to an appropriate zone ID for the address as defined in RFC4007. Whether there's an implementation that can do it is a totally different question, of course. > > Figure 1 of RFC4007 shows an example where a single link2 is > > attached to two interfaces - interface2, interface3. This is > > the one case we interface zones are different from link zones. > > > > Are there any implementations that suport this model directly ? > > Aka: Where a zone_id for the link scope would have no 1:1 equivalent > > interface id (or name) ? BSD variants try to implement the model quite hard. For example, you should be able to use a generalized utility to configure scope zone IDs: https://github.com/kame/kame/blob/master/kame/kame/scope6config/scope6config.c on FreeBSD (it's not part of the standard OS distribution so you'll need to compile it manually. I've just confirmed it built on a FreeBSD 10.3R box). You should be able to specify the same link ID for two different interfaces. That said, the kernel stack still relies on a one-to-one mapping between links and interfaces, so I'm afraid you'll have troubles if you actually configure it that way. I suspect other implementations assume the one-to-one mapping more broadly and naively. -- JINMEI, Tatuya From nobody Mon Dec 18 11:44: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 A22B51277BB for ; Mon, 18 Dec 2017 11:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 20EmexiQJol7 for ; Mon, 18 Dec 2017 11:44:47 -0800 (PST) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::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 14D26120454 for ; Mon, 18 Dec 2017 11:44:47 -0800 (PST) Received: by mail-pl0-x22a.google.com with SMTP id bi12so5447885plb.6 for ; Mon, 18 Dec 2017 11:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=p+8Cf7/u/2r3NN9W9FNu16nTrW0GlHkCn5B7K1LQXe8=; b=B8vs+HRMhXoF0tpwsK1BH+DdmOzENi/awJgMLJwxn0E9iJpb0wTxWGzA/c7kCblmTK vZRXF/U+Yl4uySont2pRYwcNrDEcVdDWSnt62fU1NmvZOeIU034U8slR/F30lZN4Zz4T savjcuKvcCMXzFZOkJpZ22IvBRc3G7XTAR524D/mOt2DebAI/eGSpXGTZPGWsygOO5vw IUuu6VZgSudaoetIjbmwQay4lmTkLpSDXHeJE0kRRut0m19jxs4AagNIiB+h3zqtu8J0 sz0aPwaHADRlLkuJI+ln5e6SphKrQRTan7Eg6Ce3XPRDQudMbuJELxxB7yBpj4Md4fkX /EZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=p+8Cf7/u/2r3NN9W9FNu16nTrW0GlHkCn5B7K1LQXe8=; b=BSC+Y93a/i12xU5mFpAMTFymSDymcnl5wlTpZj68oi/OWzdqp9CtUkyqUAiW2R+0EP 0p00rklHpXyWbPdmydFVOU+4CSJZbQnlKPSYRo1Y0qdOhwRJ3D5DNoHpSTnK21HJPUxJ ewd3CNhbwfcvSCoZoUJgB4qlI2XVuHKwNPLVCd1f9tZeR2njFtQc2AUPNGKejNyoZfsP 12EDRjrif5hFucmYRYiK3OhBPaPA3gLJFyG9B0rSpPa/b4vZHMGUnjlcjmhgCcESCDkw Z5ZuvJgTd3oz7IDcgytPzizwwLlOtJLWiqLTP6Vj3O/8YHdUynd6X5+Cc4Bstmaz82UD P/1g== X-Gm-Message-State: AKGB3mIv/qDDdayEPukn2SdJvf3uR0+6EN8pcP+iE/kpIzWhaunAGjkv eSQsmrU3BcO83ozHhhp77fyfzQ== X-Google-Smtp-Source: ACJfBotUqszxf+nj7aBLF9on/TnZvMGcxxb18AoKt0bs4DXB7QQ0dYNckreNVf2qXnkOgX0yjSKqJw== X-Received: by 10.159.197.1 with SMTP id bj1mr802045plb.118.1513626286003; Mon, 18 Dec 2017 11:44:46 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m9sm24335577pff.3.2017.12.18.11.44.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 11:44:45 -0800 (PST) Subject: Re: rfc4007 implementation question To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Toerless Eckert , IPv6 IPv6 List References: <20171217103817.GA27808@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <63b09a35-e9ca-adcc-d66e-4bf49cee56be@gmail.com> Date: Tue, 19 Dec 2017 08:44:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: Mon, 18 Dec 2017 19:44:48 -0000 On 19/12/2017 08:24, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Mon, 18 Dec 2017 07:42:15 +1300, > Brian E Carpenter wrote: >=20 >> Apart from anything else, there seems to be no way to represent >> the "link index" described in RFC4007 in the socket API, which >> explicitly supports interface indexes. So even if a stack >=20 > What do you mean by this? sockaddr_in6::sin6_scope_id has a generic > name, and, *in theory* we should be able to set it to an appropriate > zone ID for the address as defined in RFC4007. Whether there's an > implementation that can do it is a totally different question, of > course. Exactly. "The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of scoped addresses." In contrast, ipi6_ifindex is well defined as "send/recv interface index". >>> Figure 1 of RFC4007 shows an example where a single link2 is >>> attached to two interfaces - interface2, interface3. This is >>> the one case we interface zones are different from link zones. >>> >>> Are there any implementations that suport this model directly ? >>> Aka: Where a zone_id for the link scope would have no 1:1 equivalent >>> interface id (or name) ? >=20 > BSD variants try to implement the model quite hard. For example, you > should be able to use a generalized utility to configure scope zone > IDs: https://github.com/kame/kame/blob/master/kame/kame/scope6config/sc= ope6config.c > on FreeBSD (it's not part of the standard OS distribution so you'll > need to compile it manually. I've just confirmed it built on a > FreeBSD 10.3R box). You should be able to specify the same link ID > for two different interfaces. In the context of autonomic networking, where Toerless is working, there is no "you" to configure this; it needs to be automatic. I guess I could write some heuristic code to detect such a configuration. > That said, the kernel stack still > relies on a one-to-one mapping between links and interfaces, so I'm > afraid you'll have troubles if you actually configure it that way. >=20 > I suspect other implementations assume the one-to-one mapping more > broadly and naively. I think that's correct. I hooked my Windows box up this way yesterday and it promptly got two global IPv6 addresses and two link-locals, assigned of course to two different interface indexes. And of course received its own multicasts. Brian From nobody Tue Dec 19 11: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 2993D12D7FB for ; Tue, 19 Dec 2017 11:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 2-5z_S6M_USQ for ; Tue, 19 Dec 2017 11:52:16 -0800 (PST) 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 BD9C01200F1 for ; Tue, 19 Dec 2017 11:52:15 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id g17so11102731wrd.13 for ; Tue, 19 Dec 2017 11:52:15 -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=zhhz5wlbVS7Yr7J/HsYh2YPwmJ4V2m6JRceau9wDHoA=; b=eJM7/alVMZ6HorFF5C0dSBi2kHLK6BXVFH9EXHQJWkZeQh5hSY60BrqP6u5ECfI5R1 UoOaqjlhtb0tnjRlg7EbTkDFBhJ1GQL7HWMPSu565o2gvdnFgR2Op+wmO5QBi/DXG/xk Tb2JSAE49ZB87lkrU+XNMMqnK6HbjaaSxvfYTSEv2bxDM4CC26OtmQE4QIJS1iO7bt52 9FMPzj1ahJx7DjB3+F8gFHEfapw5kSs0NsngXI1VxhCPP9sAuy4tIbh9iwEe96Vg4Njj eIRAvQKRruLH31CrL8puY9lvchkCx5w43s1IdMBOR3XTOI6OFd7wYFWSzTLjVHsAGQS6 Xpiw== 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=zhhz5wlbVS7Yr7J/HsYh2YPwmJ4V2m6JRceau9wDHoA=; b=juNY8QMwcVBxnm+nukdF158MU/ckIspo29VrBIgVUEzaCsE+bzMTh50uIwn67lGrcl hlRdH6hNklH8NOysz476l3Y8mn1XYVCCAq8ht83YusGcTfetAGKgBjGf/MrYYHIBqTp/ 2mQRnoNv8+caPx1E6vbmA12d4SB/oNKUZNeYx7qMAu0BRjfbje36FAqb5a56e4yYa+B2 bAM0BZRKk7v/EuB/xI6xH/6nyO7TgrTsbkOJQuOOgQR/HWW5ePLO+J0iQvCJgGDoqf4S nc1wJVX8UDk52wbCKMkhPfBBdMkq5G8QTSH+MUq5tEZuS7GCNPKt+n8+oD+5R0Uo75la CNfQ== X-Gm-Message-State: AKGB3mISPpvI+qJvzl2I+aj4mNhVyBF0niyksSHy6qyQp4xpsc3a2Rqj m5ZaCPp9yyzsqiHGEDAJbMc/X12KRhvXIjbdvDj+PsN9 X-Google-Smtp-Source: ACJfBouNOYrbDn/Q9F5vvrMcoX/iPgrY7W0IizXwS8HFIKKj/qmol/aD70QnRiqgCtyzoc0PSvm3ri5TmBIVvCM51U4= X-Received: by 10.223.196.6 with SMTP id v6mr6005526wrf.236.1513713134089; Tue, 19 Dec 2017 11:52:14 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.142.10 with HTTP; Tue, 19 Dec 2017 11:52:13 -0800 (PST) In-Reply-To: <63b09a35-e9ca-adcc-d66e-4bf49cee56be@gmail.com> References: <20171217103817.GA27808@faui40p.informatik.uni-erlangen.de> <63b09a35-e9ca-adcc-d66e-4bf49cee56be@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 19 Dec 2017 11:52:13 -0800 X-Google-Sender-Auth: UlyRiWc6WyTBelzLfHVYDby289U Message-ID: Subject: Re: rfc4007 implementation question To: Brian E Carpenter 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: Tue, 19 Dec 2017 19:52:17 -0000 At Tue, 19 Dec 2017 08:44:42 +1300, Brian E Carpenter wrote: > > BSD variants try to implement the model quite hard. For example, you > > should be able to use a generalized utility to configure scope zone > > IDs: https://github.com/kame/kame/blob/master/kame/kame/scope6config/scope6config.c > > on FreeBSD (it's not part of the standard OS distribution so you'll > > need to compile it manually. I've just confirmed it built on a > > FreeBSD 10.3R box). You should be able to specify the same link ID > > for two different interfaces. > > In the context of autonomic networking, where Toerless is working, > there is no "you" to configure this; it needs to be automatic. I Okay. I actually wondered whether some automatic detection was assumed, but it was not clear from the original question: >>> Are there any implementations that suport this model directly ? >>> Aka: Where a zone_id for the link scope would have no 1:1 equivalent >>> interface id (or name) ? so I gave a reference to an implementation that at least supports the model with manual configuration. -- JINMEI, Tatuya From nobody Wed Dec 27 11: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 4D48B128D2E for ; Wed, 27 Dec 2017 11:08:47 -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, 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=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 33N6TPpJ6_hj for ; Wed, 27 Dec 2017 11:08:45 -0800 (PST) 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 73A19129C59 for <6man@ietf.org>; Wed, 27 Dec 2017 11:08:45 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id 33so48916438qtv.1 for <6man@ietf.org>; Wed, 27 Dec 2017 11:08:45 -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; bh=Jz/4nFPrdIac1S+/vbIHyUiEXJFJ/Pl4ZDB7O09f/y8=; b=EwKtV0zvQNSQ9LsULevnF4GKbshjmntfNnkwgjvNtmJIE1WlMp+J7uRK9tTxoIR6Es Q4VngnULorzcfG+C/dNmYGm3obX6pYByKiM+ISoREg2h949V2hH7HO8F2QfP/dJUrY5p vnQRMbt3xXE9oMoRRqP5eO4U7nwZEukQ3xNS2s6iTFWNhG4almGWLA3mcKj+MKME/4FJ 72FzmyZl/FomRFuD3/PyQdn8AScu9Wzqicpgfm7P+J1SXoyJCgkNY+lxCUMjuMKVVc+n GlMlIK9gZ77Y6uOd/TJfTBkMNpCTT18zDv5+iOxI7n7Z71zzfe3NJhq6x39kbxudL2tR B8Xw== 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=Jz/4nFPrdIac1S+/vbIHyUiEXJFJ/Pl4ZDB7O09f/y8=; b=dxx/QO+5D7k1Ngjnj4ofofd8hHV7jWx2gt4z2ZouVIKvhQVKgCqkwJwolGDAxNYYvC ENuyFCHkCmmEdtXKekiWfoFjfJTySYimRd0j2psDV1aDLiogObsk1dpj+28yDcofuR99 Uyx052JpZbdWiZCQFo4C6wmpdQ+zsriXhzj/HQWxRERavuW7fIi0tUE3rHS0H/apOupW 53+znJVS0l6YW5+ZJctS0ueqXOqSDGSfiDVfbrKBoL5hPhuo+CGUo9dk02GpgXIUffbN hw7gSDL+dUd3s7K0Ljq8ZSOPMLq6ws98IZ0jMqpzHC9/BTNN9ULXM0wlv2WcX6CDjKWY Mp8g== X-Gm-Message-State: AKGB3mLQJR73CtNETasqHyA0ZulYs7ToO8+FusS0Ag1cNAB5L7rYynV0 XSQdtjVp854kb84A2T+MUAPImKuSR3XBaJi+ejVSMg== X-Google-Smtp-Source: ACJfBosonaTjJ5mU64W1k3be3XliC91gEt6oRzeyIiZWZHnRFq7K9ykEF/t47MH1Ph24si9T5LWXvaFkDb8wEj4PeRY= X-Received: by 10.200.43.16 with SMTP id 16mr41311651qtu.44.1514401724219; Wed, 27 Dec 2017 11:08:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.121 with HTTP; Wed, 27 Dec 2017 11:08:43 -0800 (PST) In-Reply-To: <151440138086.29794.626180550016198091.idtracker@ietfa.amsl.com> References: <151440138086.29794.626180550016198091.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 27 Dec 2017 11:08:43 -0800 Message-ID: Subject: Fwd: New Version Notification for draft-herbert-6man-icmp-limits-02.txt To: 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: Wed, 27 Dec 2017 19:08:47 -0000 Hello, I posted a new version of the ICMP errors for processing limits drafts. Changes are mostly to incorporate suggestions in previous feedback (from Ron Bonica and others) These include: - Defining a destination unreachable code for aggregate header limit exceeded (previously this was a parameter problem) - Specifying a reporting priority of the relevant errors - Making pointer point to first octet beyond a byte limit so that sender can deduce the limit being enforced Thanks, Tom ---------- Forwarded message ---------- From: Date: Wed, Dec 27, 2017 at 11:03 AM Subject: New Version Notification for draft-herbert-6man-icmp-limits-02.txt To: Tom Herbert A new version of I-D, draft-herbert-6man-icmp-limits-02.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-6man-icmp-limits Revision: 02 Title: ICMPv6 errors for discarding packets due to processing limits Document date: 2017-12-27 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-02.txt Status: https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/ Htmlized: https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-herbert-6man-icmp-limits-02 Abstract: Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication so it cannot take action to address the cause of discarded packets. This document defines ICMP errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMP error may be able to modify what it sends in future packets to avoid subsequent packet discards. 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