Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Fri, 20 October 2017 14:28 UTC

Return-Path: <dmudric@avaya.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C351331D9; Fri, 20 Oct 2017 07:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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 q_Y11_RaQR3m; Fri, 20 Oct 2017 07:28:30 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 B3F611241F3; Fri, 20 Oct 2017 07:28:28 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2FhAABbB+pZ/yYyC4dcGQEBAQEBAQEBAQEBBwEBAQEBgm8iIC5kbicHgzBDggaIGY8/gXqWNxCBIgMZQAMKGAEJhRkCGoQhPxgBAgEBAQEBAQEDaCiCajcDDCEIAwEBAQEBAQEBAQIBAR8BAQEBAQEBAQEBAQEBHAIPLxIBARgBAQEBAgEBAQoGCAEICkELBQcEAgEGAg0EBAEBCw8CBQEGAwICAiQBCxQJCAIEAQ0EAQgBGYkaXAgBD4wskn2KaoInIQKKfgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DLoIHgVGFEoMygRcVKQUHCR8CBh8CgXg9L4IyBYdNg06NVIhwAodhh0WHXl2FHINzhVOBS41ChFGDZ4E5HzlPgQx6FR8qgmQJgho5HIFndgEBAQFehzoCJQSBCAGBEAEBAQ
X-IPAS-Result: A2FhAABbB+pZ/yYyC4dcGQEBAQEBAQEBAQEBBwEBAQEBgm8iIC5kbicHgzBDggaIGY8/gXqWNxCBIgMZQAMKGAEJhRkCGoQhPxgBAgEBAQEBAQEDaCiCajcDDCEIAwEBAQEBAQEBAQIBAR8BAQEBAQEBAQEBAQEBHAIPLxIBARgBAQEBAgEBAQoGCAEICkELBQcEAgEGAg0EBAEBCw8CBQEGAwICAiQBCxQJCAIEAQ0EAQgBGYkaXAgBD4wskn2KaoInIQKKfgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DLoIHgVGFEoMygRcVKQUHCR8CBh8CgXg9L4IyBYdNg06NVIhwAodhh0WHXl2FHINzhVOBS41ChFGDZ4E5HzlPgQx6FR8qgmQJgho5HIFndgEBAQFehzoCJQSBCAGBEAEBAQ
X-IronPort-AV: E=Sophos;i="5.43,405,1503374400"; d="scan'208,217";a="218885937"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Oct 2017 10:28:21 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2017 10:28:20 -0400
Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0352.000; Fri, 20 Oct 2017 10:28:20 -0400
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Lorenzo Colitti <lorenzo@google.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
Thread-Index: AQHTLJkvHyV/vgiRe0WkRYLcTMM3MKKzTQFQgABVIwCAI2c7kIAABjYQgAhZRYD//4wjYIAAE+kQgACTEYD//7Yl4IAJuHYA//+S70AAEjLrgAAM2xBQABzuogAAB4wtQABJLXOA
Date: Fri, 20 Oct 2017 14:28:19 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E4585AE2635@AZ-US1EXMB03.global.avaya.com>
References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> <CAKD1Yr00obLxByQEgQkXKnD=W+Kvd0XKtYAdF=Na-dLfo1MHQA@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E4585AD4EAA@AZ-US1EXMB03.global.avaya.com> <a2a87abaee9c4555819927515f9e93b1@XCH15-06-08.nw.nos.boeing.com> <9142206A0C5BF24CB22755C8EC422E4585ADD02C@AZ-US1EXMB03.global.avaya.com> <e143fba64d6f4c0f996a4fa164a7dee6@XCH15-06-08.nw.nos.boeing.com> <63f8038c61fb40c39cc4e89e94611c77@XCH15-06-08.nw.nos.boeing.com> <9142206A0C5BF24CB22755C8EC422E4585ADD259@AZ-US1EXMB03.global.avaya.com> <003d287daa534621a5b3ab5c01db84d4@XCH15-06-08.nw.nos.boeing.com> <9142206A0C5BF24CB22755C8EC422E4585AE0A24@AZ-US1EXMB03.global.avaya.com> <99d2d187a808422ca4d0cb999f0bc9ca@XCH15-06-08.nw.nos.boeing.com> <9142206A0C5BF24CB22755C8EC422E4585AE0B05@AZ-US1EXMB03.global.avaya.com> <f0f5e734a3734fd3bae3fed47b1a9746@XCH15-06-08.nw.nos.boeing.com> <9142206A0C5BF24CB22755C8EC422E4585AE0E03@AZ-US1EXMB03.global.avaya.com> <f3f6e13f07154e62912a9718b77cbdb2@XCH15-06-08.nw.nos.boeing.com>
In-Reply-To: <f3f6e13f07154e62912a9718b77cbdb2@XCH15-06-08.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 10.0.250.9
dlp-reaction: no-action
x-originating-ip: [135.11.85.50]
Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E4585AE2635AZUS1EXMB03glob_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/qx76LKKW78OxeQ6wJqCCbNXxlmE>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Oct 2017 14:28:36 -0000

Hi Fred,

Please find inlined.

Thanks,
Dusan.

From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Wednesday, October 18, 2017 4:32 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: v6ops@ietf.org; internet-drafts@ietf.org
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

[[Dusan]] The section 7 wording depends on the host H1 knowledge about the prefix type. If the host knows it is individual or delegated prefix, there is no need for ND DAD and address resolution on the upstream link. Since avoiding DAD and the address resolution is very important, we should have a mechanism in place to provide that knowledge to the hosts. I could not find the RFC that defines the prefix types. rfc3769 does not define the delegated prefix type. It just assumes the router knows if the prefix is assigned to it, it is the delegated prefix. If the delegated prefix is assigned to hosts, how they will know it is the delegated vs. individual prefix vs shared prefix? What are advantages of delegated prefixes over individual prefixes to hosts? Or, should the host have these two prefix types? Should these two prefixes be treated as the same type by hosts? One way or the other, hosts should know it is shared vs (individual/delegated) prefix and take the advantage of the (individual/delegated) prefixes. For example, https://tools.ietf.org/html/rfc4861#section-4.6.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4861-23section-2D4.6.2&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=BoYLHzx6Y_ftZaZNIXHlyP821J99H7FX_pp9bp8lloA&s=Z9djxUOB-Betmy0ioHjc74Gn-ctR0dQX31EZD4ys8cE&e=> can define a reserved bit to distinguish between the two prefixes, shared vs (individual/delegated). If the bit is set (meaning (individual/delegated) prefix), don’t do DAD and address resolution.

Ah yes, your comment is related to ‘draft-pioxfolks-6man-pio-exclusive-bit’. That document
suggests an ‘X’ (“eXclusive”) bit added to the PIO flags.
[[Dusan]] So, the idea is already documented. Did not follow this discussion. Thanks for the reference.
The procedures for defining a new
bit in the PIO flags field are given in ‘draft-troan-6man-ndpioiana’.

But, more is required than just informing the host that the prefix has been delegated.
‘draft-templin-v6ops-pdhost’ says that prefix delegation entails: “1) the communication
of a prefix from a delegating router to a requesting router, 2) a representation of the
prefix in the delegating router's routing table, and 3) a control messaging service
between the delegating and requesting  routers to maintain prefix lifetimes”.

So, even if the router has a way to tell the host that the prefix is delegated (e.g., via
an ‘X’ bit in the PIO flags) there still needs to be a control messaging service between
the host and the router, and (in the case of IPv6 ND) simple RS/RA messaging is not
sufficient. In the case of DHCPv6 PD, there are a set of control messages including
Request/Reply/Renew/Rebind/Release/Reconfigure (the “six R’s” of PD) that are
explicitly provided for that purpose.
[[Dusan]] Can you please provide these host specific details in the draft-templin-v6ops-pdhost? I expected that RS/RA can do all DHCPv6 does: Request (RS)/Reply (RA)/Renew (RA)/Rebind (RA)/Release (RA)/Reconfigure (RA). If there is more to it, please describe in the draft-templin-v6ops-pdhost.
And, if the ‘exclusive’ bit for the delegated prefix is set, the host is no longer required to do the address resolution for the ‘individual’ prefixes:
“When a node receives a shared or individual prefix with "L=1" and has
a packet to send to an IPv6 destination within the prefix, it is
required to use the IPv6 ND address resolution function over the
upstream interface to resolve the link-layer address of a neighbor
that configures the address.
Can you further polish  this part please?

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]
Sent: Wednesday, October 18, 2017 9:46 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>; Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

As always, thanks for your help. Please see inline for the new comment.

Regards,
Dusan.

From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Tuesday, October 17, 2017 5:54 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

I don’t expect the H1 host to send a packet to outgoing interface using P1 based address. ‘L=1’ becomes irrelevant for the individual prefix. ND on the hosts is never needed. Did I miss something? What is the use case for this statement?
“When a node receives a shared or individual prefix with "L=1" and has
a packet to send to an IPv6 destination within the prefix, it is
required to use the IPv6 ND address resolution function over the
upstream interface to resolve the link-layer address of a neighbor
that configures the address.

Would it satisfy the concern if I were to remove the words “shared” and “individual”
from the above statement, i.e., change it to:

  “When a node receives a Prefix Information Option in a Router Advertisement with “L=1”
   and has a packet to send to an IPv6 destination within the prefix, …”

[[Dusan]] Good point. Thanks. Is there a way for the host to figure out this is an individual prefix and there is no need for DAD?

The only way for the host to know that the prefix is intended for its own exclusive
use (and hence no need for DAD) would be if the host were to engage in some sort
of prefix delegation messaging. This means that the host would need some additional
functionality beyond just RFC4861. But then, it would be a delegated prefix and not
an individual prefix.

[[Dusan]] The section 7 wording depends on the host H1 knowledge about the prefix type. If the host knows it is individual or delegated prefix, there is no need for ND DAD and address resolution on the upstream link. Since avoiding DAD and the address resolution is very important, we should have a mechanism in place to provide that knowledge to the hosts. I could not find the RFC that defines the prefix types. rfc3769 does not define the delegated prefix type. It just assumes the router knows if the prefix is assigned to it, it is the delegated prefix. If the delegated prefix is assigned to hosts, how they will know it is the delegated vs. individual prefix vs shared prefix? What are advantages of delegated prefixes over individual prefixes to hosts? Or, should the host have these two prefix types? Should these two prefixes be treated as the same type by hosts? One way or the other, hosts should know it is shared vs (individual/delegated) prefix and take the advantage of the (individual/delegated) prefixes. For example, https://tools.ietf.org/html/rfc4861#section-4.6.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4861-23section-2D4.6.2&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=BoYLHzx6Y_ftZaZNIXHlyP821J99H7FX_pp9bp8lloA&s=Z9djxUOB-Betmy0ioHjc74Gn-ctR0dQX31EZD4ys8cE&e=> can define a reserved bit to distinguish between the two prefixes, shared vs (individual/delegated). If the bit is set (meaning (individual/delegated) prefix), don’t do DAD and address resolution.

The prefix type knowledge might help for the further security improvements. For example, a host would know it should not add NCE for the addresses that start with the prefix delegated to the host. I am sure there will be more ideas around it.

[[Dusan]] Ok. Can you add a note please in the security section about the impact of delegated and individual prefixes on the address privacy? That will help decide whether to use “the prefix as on-link” when stable or temporary addresses are needed.

Sure, I will add something.

About your other points, I think they are now fixed in the -15 modulo the discussion
points above. If you see something in the -15 that still looks broken let me know so
I can fix it in a -16.

Thanks - Fred



From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]
Sent: Tuesday, October 17, 2017 1:50 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>; Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Please see inlined

Thanks,
Dusan.

From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Tuesday, October 17, 2017 3:36 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

Question about the first sentence in section 7:
“When a node receives a shared or individual prefix with "L=1”
Why would the individual prefix have “L=1”?

What makes an individual prefix an individual prefix is merely the fact that
the router advertises the prefix to exactly one node and does not advertise
it to any other nodes. In that case, the setting or not setting of the ‘L’ bit is
up to the router and beyond the scope of what we are trying to convey in
this document.
[[Dusan]] The router should never assign more than one individual prefix to more than one host. When sending a packet from H1 to a an on-link destination H2, using an individual prefix P2, the H1 host should not have the P2 prefix in its prefix list. Since the prefix list has only one prefix P1 (this is my assumption; suggest defining this behavior for delegated prefix too; the node needs to know if it is possible to get other prefixes if it is assigned individual or delegated prefix; if router can assign a combo of prefixes, this needs to be defined), the H2 destination is considered off-link and the packet is sent to the first hop router.

I don’t expect the H1 host to send a packet to outgoing interface using P1 based address. ‘L=1’ becomes irrelevant for the individual prefix. ND on the hosts is never needed. Did I miss something? What is the use case for this statement?
“When a node receives a shared or individual prefix with "L=1" and has
a packet to send to an IPv6 destination within the prefix, it is
required to use the IPv6 ND address resolution function over the
upstream interface to resolve the link-layer address of a neighbor
that configures the address.

I don’t understand why https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-12#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D12-23section-2D4&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=oXYlcovo9etCYLf5ReCeD4gdzkL1wdDovM5mC0M92Ag&s=IVnlMA0rEI49jpUNYU_SegkbY7MLEuGchNU2HrvwcdM&e=> requires DAD for the individual prefix:
   Since the
   address is composed by the subscriber device itself, it will need to
   verify that the address is unique on the shared network.
If there is no node on the link with the individual prefix, why is DAD required?

My understanding is that an unmodified host that receives a prefix with “A=1; L=0”
will autoconfigure one or more addresses from the prefix and assign them to the
interface over which the prefix was received. But, since “L=0” in itself conveys
no indication as to whether the prefix is individual or shared, the host has to do
DAD under the assumption that other hosts may have received the same prefix.
[[Dusan]] Good point. Thanks. Is there a way for the host to figure out this is an individual prefix and there is no need for DAD?


[[Dusan]] I check the section 7. It only talks about the “on-link node” redirects. Can you please add something about the first hop router redirects (e.g. for a better route)?

Not sure I see a problem with the text as it is written. It already mentions the first hop
router as the one that would send any redirects.


Regarding the redirects, for a better security, can hosts have an option to ignore them? There are already out-of-band options to set the hosts to ignore redirects. Should that be mentioned in the security section?

Yes, certainly. Routers need not send redirects, and hosts need not listen to them.
That is the same as for any link. I can add something to Security Considerations.


[[Dusan]] Question about “For delegated prefixes and individual prefixes that are not considered on-link”. If the “the router delivers all packets that match the prefix to the unicast link-layer address of the node”, doesn’t this violate the address privacy in RFC4941?

It is the same consideration as for any router that receives a delegated prefix. The
routing system will unconditionally deliver all packets that match the prefix to the
router, and it is up to the router to drop the packet and (optionally) return DU
“address unreachable” if the address is not in use. If the address is in use, though,
the router will deliver the packet to the end system that configures the address
even for privacy addresses. That is just the way routers work.
[[Dusan]] Ok. Can you add a note please in the security section about the impact of delegated and individual prefixes on the address privacy? That will help decide whether to use “the prefix as on-link” when stable or temporary addresses are needed.


[[Dusan]] ping6 should go the first hope router on the upstream interface, without the address resolution. There is no another node assigned the same prefix. There is no need for the address resolution for 2001:db8:1:2::20.

You are right; I made a mistake in the -14 version of the document but it should now
be fixed in the -15. Can you check again to verify?
[[Dusan]] I think this needs to be changed. Please see the arguments above:
7.  IPv6 Neighbor Discovery Implications

   When a node receives a shared or individual prefix with "L=1" and has
   a packet to send to an IPv6 destination within the prefix, it is
   required to use the IPv6 ND address resolution function over the
   upstream interface to resolve the link-layer address of a neighbor
   that configures the address.
Even if “a neighbor that configures the address” is a router, the node should already know the router’s link layer address and there is no need for the address resolution.

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]
Sent: Tuesday, October 17, 2017 11:39 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>; Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Thanks for the updates.

Question about the first sentence in section 7:
“When a node receives a shared or individual prefix with "L=1”
Why would the individual prefix have “L=1”?

I don’t understand why https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-12#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D12-23section-2D4&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=oXYlcovo9etCYLf5ReCeD4gdzkL1wdDovM5mC0M92Ag&s=IVnlMA0rEI49jpUNYU_SegkbY7MLEuGchNU2HrvwcdM&e=> requires DAD for the individual prefix:
   Since the
   address is composed by the subscriber device itself, it will need to
   verify that the address is unique on the shared network.
If there is no node on the link with the individual prefix, why is DAD required?

For other comments, please find the responses inlined.

Thanks,
Dusan.

From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Wednesday, October 11, 2017 5:35 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

Responses below:

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]
Sent: Wednesday, October 11, 2017 11:37 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>; Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Thanks for further clarifying the router and host behaviors.

Questions about the latest “-14” updates:


-          General questions:

o   Should the new definitions for the ‘individual prefix’ be in draft-ietf-v6ops-unique-ipv6-prefix-per-host document?


>  I cannot speak for that document.



o   In the Security section, can you add more about:

•  DAD security benefits (e.g. when a node does not use DAD, so it cannot be attached with DAD),

•  NCE security benefits (e.g. when a number of NCE entries is limited to one per advertised prefix, or so),


>  Certainly yes about these items.



•  Malicious redirects (e.g. when the redirect is not required, so a node cannot be attached with redirects), and

•  and rogue RAs?


>  Redirects and RAs are only accepted from the first-hop router. So, a malicious redirect

>  or RA would be one that spoofs the source address of the first-hop router. But, that

>  is a general link-layer security concern for IPv6 ND in general and not necessarily

>  specific to this document. Or, do you see it differently?

[[Dusan]] I check the section 7. It only talks about the “on-link node” redirects. Can you please add something about the first hop router redirects (e.g. for a better route)?



Regarding the redirects, for a better security, can hosts have an option to ignore them? There are already out-of-band options to set the hosts to ignore redirects. Should that be mentioned in the security section?



These clarifications will help define when nodes should not use DAD, redirect, …


>  My opinion is that a node should not do DAD unless it has to.



-          ‘individual prefix’






The router that advertises the prefix can consider the prefix as on-link or


not on-link. In the former case, the router performs address


resolution so that it only forwards those packets that match one


of the node's configured addresses.”


You introduced extra flexibility for the unique prefix. What is the motive for the on-link prefix, that requires extra address resolution and NCEs? To “prevent unwanted IPv6 packets from reaching the node”?


>  Yes, the benefit would be to prevent unwanted IPv6 packets from reaching the node.


And, provide security benefits of stable and private addresses?.


>  Whatever type of addresses the host configures, the router would use address resolution to

>  ensure that the host actually responds to the given address before sending any packets.

[[Dusan]] Question about “For delegated prefixes and individual prefixes that are not considered on-link”. If the “the router delivers all packets that match the prefix to the unicast link-layer address of the node”, doesn’t this violate the address privacy in RFC4941?


Can these benefits be added to ‘individual prefix’ definition?


>  I will add something.


Should these benefits go into the ‘unique ipv6 prefix per host’ draft?


>  There did not seem to be consensus to add anything to that draft.



-          7. IPv6 Neighbor Discovery Implications

“When a node receives a shared or individual prefix, it is required to
use the IPv6 ND address resolution function over the upstream
interface to determine the link-layer address of a neighbor”

The address resolution is done for ‘Send’ algorithm. Why is it needed for the prefix assignment?


>  That is correct – address resolution is part of the sending algorithm and not

>  part of prefix assignment. I will make sure to clarify that point.

Why is the address resolution required for the ‘individual’ prefix? Should not the node using the individual prefix send the packets to the first hop router (the on-link neighbor has a different ‘individual’ prefix and that prefix is not in the node’s prefix list)?


>  What I am meaning to say is that, if the node receives the individual prefix

>  2001:db8:1:2::/64 and configures the address 2001:db8:1:2::10, but then

>  tries to ping6 the non-existent address 2001:db8:1:2::20, it has to do

>  address resolution on the upstream interface which will fail. Do I have

>  that right, or did I make a mistake?

[[Dusan]] ping6 should go the first hope router on the upstream interface, without the address resolution. There is no another node assigned the same prefix. There is no need for the address resolution for 2001:db8:1:2::20.

“For delegated prefixes and individual prefixes that are not
considered on-link, the router delivers all packets that match the
prefix”
To where? Node’s link-layer unicast address?


>  The node’s IPv6 link-local address will be listed as the next hop in the

>  router’s forwarding table. So, address resolution for the link-local

>  address would reveal the node’s link-layer address and all packets

>  that match the prefix would be sent to the node’s link-layer address


Thanks a lot for your help,
Dusan.

From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Wednesday, October 11, 2017 12:52 PM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

Thanks again for your useful comments - I updated ‘pdhost’ to resolve your questions
(see below). Please review and let me know if your points are addressed.

Thanks - Fred



-----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Sent: Wednesday, October 11, 2017 9:49 AM
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
Subject: I-D Action: draft-templin-v6ops-pdhost-14.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.





        Title           : IPv6 Prefix Delegation for Hosts

        Author          : Fred L. Templin

                Filename        : draft-templin-v6ops-pdhost-14.txt

                Pages           : 12

                Date            : 2017-10-11



Abstract:

   IPv6 prefixes are typically delegated to requesting routers which

   then use them to number their downstream-attached links and networks.

   This document considers the case when the requesting router is a node

   that acts as a host on behalf of its local applications and as a

   router on behalf of any downstream networks.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dtemplin-2Dv6ops-2Dpdhost_&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=oQyz4ZL7nRjl4w-UOFD__FEq9BAVOErk4zKfvNKywB8&e=>



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-templin-v6ops-pdhost-14<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dtemplin-2Dv6ops-2Dpdhost-2D14&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=t7h-qAzKyeNXj52Bd1ocM55trXAM-ULOYOm9iZ2zj-k&e=>

https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-14<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dtemplin-2Dv6ops-2Dpdhost-2D14&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=S0EAFQmdkX8K5N4Yw3j_zskqWcKgjxJRPdNwKKRZzX4&e=>



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-14<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dtemplin-2Dv6ops-2Dpdhost-2D14&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=YGvZUUnvUW8TAoMb0lR163KBfGBXY_QXFnvkEmYOQV0&e=>





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/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=t5HXG7Zhdj3axBFViESNpLbI0Hnc5WtFi3i1CpmpvOg&e=>



_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>

https://www.ietf.org/mailman/listinfo/i-d-announce<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=HLsphMfYQJWMfLeqogtP5AjCpZMwq9aukzt2zk94jRc&e=>

Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=0dssRxnxQaRH8ufnu48Y41lXLOs83K2I2LSPNIOTp3w&e=>

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Eb5XUfV0A6sClwFnQpF5SxJ_Gak1PdPgbP9tLj33U9k&s=HAzlvpqBO4auAT3RoRaJyqI0mDMZS6nRNGQQi-eY0TY&e=>


From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
Sent: Wednesday, October 11, 2017 8:46 AM
To: Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>>; Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Mudric,

Thanks for the comments, and see below for responses. I will work new
text into the ‘pdhost’ draft and post a new version soon.

Fred

From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]
Sent: Wednesday, October 11, 2017 8:34 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>; Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,


Good point. Can you please provide some text explaining the security advantages of 2) and 3) over 1)?



>   Yes, I can work on this and add something to the draft.



'draft-templin-v6ops-pdhost' defines "shared", "individual", and "delegated" prefixes, where "individual” prefixes are introduced by ietf-v6ops-unique-ipv6-prefix-per-host. This draft should clearly state when and why some “individual” prefix algorithms are, and are NOT, run (i.e. DAD, neighbor discovery, …). This will clarify the impact of this draft on hosts.



>   The draft currently talks about DAD and ND considerations for item 3), but can be

>   extended to compare with DAD/ND considerations for the other options.



Thanks,

Dusan.


From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Friday, October 06, 2017 11:08 AM
To: Mudric, Dusan (Dusan); Lorenzo Colitti
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Dusan,

To my understanding, we have 1) shared prefixes, 2) individual (“unique”) prefixes and 3) delegated prefixes.
‘ietf-v6ops-unique-ipv6-prefx-per-host’ talks about 1) and 2), while ‘templin-v6ops-pdhost’ talks about 3).

Do you want to also consider delegated prefixes?

Thanks - Fred

From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]
Sent: Friday, October 06, 2017 7:48 AM
To: Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>; Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Hi Fred,

Should it be mentioned that even though a ‘shared’ prefix with L=0 makes hosts send packets over the first hope router, the unique prefix per host is preferred mechanism in the environments where security is of a concern?

Thanks,
Dusan.

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: Wednesday, September 13, 2017 6:04 PM
To: Templin, Fred L
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

I would instead say the opposite, i.e., call attention to what is in fact one of the the main benefits of this document. Suggested text:

The practices described in this document make it very simple for networks to implement robust isolation between clients at layer 2. The network can simply ensure that devices cannot send packets to each other except through the first-hop router. This will automatically provide robust protection against attacks between devices that rely on link-local ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious redirects, and rogue RAs. This form of protection is much more scalable and robust than alternative mechanisms such as DAD proxying, forced forwarding, or ND snooping.



On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
Please add the following to Security Considerations:

  "While the practices described herein encourage L3 operations that would
    forward all traffic through a provider managed First Hop Router, peer to peer
    communications are still possible unless L2 mechanisms are also employed
    in some fashion outside the scope of this document."

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>] On Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
> Sent: Wednesday, September 13, 2017 7:04 AM
> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
> Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
>
>         Title           : Unique IPv6 Prefix Per Host
>         Authors         : John Jason Brzozowski
>                           Gunter Van De Velde
>       Filename        : draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>       Pages           : 9
>       Date            : 2017-09-13
>
> Abstract:
>    This document outlines an approach utilising existing IPv6 protocols
>    to allow hosts to be assigned a unique IPv6 prefix (instead of a
>    unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
>    IPv6 prefix over a unique service provider IPv6 address include
>    improved host isolation and enhanced subscriber management on shared
>    network segments.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost_&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=Z0NT1ldV3az-PlcrolYWmpzjzXI-e9gIFUUG7GqakVA&e=>
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D08&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=iwcdOKuejV0qgA7XtQEwy-NPAasakqiys1hP46IrLVs&e=>
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D08&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=JGWGoSnzdqBvDMseLJY0jyuaFE1nd-c6bZD9ehddnQo&e=>
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-08<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-2Dper-2Dhost-2D08&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=KKbJOoGAffY7kkEZ1sT7fHIl09DX2kdlChL3_Ox38mY&e=>
>
>
> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=7APWKVKyyoeqrSUx4M-UUhMlzxXL3hkgcCmZSRUxoPI&e=>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=AxI18cu2PadGwT3HHZOGQbNC7idjhV_I_q466Ssm15E&e=>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org<mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=gfIYhPTUIDst9iCDPwjpqx-FJKKNJ9ney-huyDVfwy4&e=>


_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=PlXnFjk4NtNYXkaHFxRI86HSymtz8QLmdZMdwJQhLUY&s=gfIYhPTUIDst9iCDPwjpqx-FJKKNJ9ney-huyDVfwy4&e=>