From nobody Mon Aug 12 14:57:20 2019 Return-Path: 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 2ACCA120ED0 for ; Mon, 12 Aug 2019 14:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pieNum6R5G-x for ; Mon, 12 Aug 2019 14:57:15 -0700 (PDT) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55E3120BB1 for ; Mon, 12 Aug 2019 07:30:08 -0700 (PDT) Received: by mail-wm1-f53.google.com with SMTP id l2so11981889wmg.0 for ; Mon, 12 Aug 2019 07:30:08 -0700 (PDT) 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=tStMPGZDYNBSynvKd/PCnjI2iGVlm4CAAmBwOFAjuS0=; b=lhNlbz7PwlEMp3FsTRkTvVnsDhwGhUYx5r+VkupL8NkhgL5VMERNfiy7hTS8B5y9aY GC17J/eDGHCxKJBn+/4tC3QtANFStWBwMQjpa/PdAzN2owzB6FnIhfezjSh7VLQas+ft U4WvS/R0V5X+vXbS4iSkaLRVqCDTFilAs1yBBUc6z3kGH/4c3hZsePQgXBc4spoZgZ+W 4NYEy1yttS6BPHc/Q/YY4e2TcFj/9Sm28aOe76+qZgPy2fK5DNKEwtTFzoY7E8zFbzxT moHLWtaoPUBx6PK2nh4ZmE6sf5PMW8inP/v3BFmTXYtkgyZegFPw0LpIi/KO/9H/HPpJ FUtg== X-Gm-Message-State: APjAAAXNlxXR455HPP3u5e8yS5dm0uocsLq6BAGHJ211T7p012nFxTca bzuDsCaF3jf8bsMq3GTNuYJbcoerdRzUkErHpqE= X-Google-Smtp-Source: APXvYqwErfmL6MV/ubcTDRg/InQoAEFbuyrNpw6dsTQ4899fgsKRN7bb6tfTsb3SGv01VUyqLV43ZWptctLxw6tdqC8= X-Received: by 2002:a1c:f914:: with SMTP id x20mr29152483wmh.142.1565620206913; Mon, 12 Aug 2019 07:30:06 -0700 (PDT) MIME-Version: 1.0 From: Erik Nygren Date: Mon, 12 Aug 2019 10:29:55 -0400 Message-ID: To: Jordi Palet Martinez , "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000494b7f058fec5cd0" Archived-At: Subject: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches concerns, including a potential major security vulnerability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 21:57:18 -0000 --000000000000494b7f058fec5cd0 Content-Type: text/plain; charset="UTF-8" Some comments on draft-palet-v6ops-464xlat-opt-cdn-caches from the perspectives of having a $dayjob at a CDN.... This comes down to three general concerns, plus a major security concern: 1) Will this do more harm than good? (ie, creating brokenness which motivates content to switch back to IPv4-only) 2) Stateless EAMT just won't work due to the typical rate of changes of A/AAAA pairings in the DNS 3) The IPv4:IPv6 associations may not be adequately 1:1 and client behavior may be hard to anticipate 4) Poisoning risks/vulnerability (a major security consideration, which may make the DNS approach not viable) TL;DR is that the security issue (an attacker being able to poison the EAMT cache, which can also happen non-maliciously as well) may mean the DNS-based approach is far too dangerous to deploy. For #1 (the risk/concern factor)... I worry really worry that while the DNS association option is a clever hack, that it will turn out to be highly fragile and problematic in reality. It only takes some corner-cases that are missed or one bad implementation for it to do much more harm than good. (I wrote this even before I realized the security issue listed below.) One of the biggest challenges I'm already seeing on getting video content dual-stacked in some parts of the world is consumer electronics with poor IPv6 implementations interacting badly with buggy CPE/ISP/home-router configurations. Even if IPv6 is generally faster (and may be more available if a good happy eyeballs implementation is used), it only takes a relatively small number of subscribers with some Smart TV + ISP configuration that breaks in the face of dual-stack content to cause a content provider to get enough calls to switch the content back to IPv4-only. I've seen this happen in at least both the Nordics and East Asia. I worry that this optimization feature could introduce an entirely new class of problems like this if poorly implemented. If the only recourse content providers have is to switch their content back to being IPv4-only (as that *may* make the difference between content appearing broken to IPv4 users and between it appearing to be working), then this could hinder IPv6 usage much more than it helps. One approach that might help this would be to have hostname "allowed" lists, allowing a ISPs to turn this on for select content. That could still be problematic if the "allowed" list of hostnames overlaps on the same IPs as other content. It might at least provide for a way for ISPs to use this feature with their own STB+content combinations, such as for their own "walled garden" use-cases where they control both the IPv4-only devices and the content being delivered. (Getting robust IPv6 support onto the devices would obviate the need for this, however.) Another possibility might be some opt-in mechanism? (eg, if an additional DNS record is looked up that indicates that this translation is supported?) For #2 (the stateless/stateful factor)... The A/AAAA IPs returned in DNS can be very dynamic. For example, many CDNs have DNS TTLs in the 20 second to 300 second range. At least for Akamai, the assignments for which addresses are returned for A and AAAA lookups are done independently. As such, frequent churn in associations should be expected. If the churn only impact new TCP connections then this part might work some (much?) of the time (minus other caveats below). However if the translation is stateless then this is going to be breaking TCP connections all the time and will make this solution unusable. It sounds like the current EAM Table (EAMT) lookups are stateless? This means that each time an association is removed or changed that it will break all of the long-lived connections using that association. That seems likely to result in lots of timeouts and rebuffering (ie, as streams will start playing and then will fail when the association changes or disappears and the connection breaks). I think a requirement for this solution to work would be for the EAMT table lookups to result in stateful NAT entries on the home router. (ie, the lookups are just used to create stateful NAT entries for the 4-tuple for the duration of that session/connection.) For #3 (IPv4:IPv6 associations may not be adequately 1:1 and client behavior may be hard to anticipate) This issue has a longer subset of concerns/issues. The doc seems to touch on a bunch of them, but I worry if there are lots of lurking corner-cases, each one of which could cause problems. Without a good way to fix or disable bad implementations, each one could be a major problem: * Not all clients are good at obeying DNS TTLs. Some are really bad. (eg, Java will sometimes just do a single DNS lookup and use it for the duration of the process lifetime. Many major browsers also will use a connection for the duration of its lifetime even if the TTL has changed. In the best-case (with stateful translation) this just results in more IPv4 due to less cache entries. In a bad case (without stateful translation) it could mean that connections are pretty much guaranteed to break when they pass their TTLs and the EAMT entries time out but the clients keep using them. * The aliasing issue (where the IPv4:IPv6 associations between hostnames are far from 1:1) is real and will result in brokenness. The doc has a bunch of heuristics that help. but given how clients often don't obey TTLs there may not be enough information available to detect and fix enough of these cases. It seems like there are lots of possibilities for timing and race conditions for cache entries. As an example, I know of one case where IPv4 is shared by lots of hostnames and SNI is used to determine which TLS certificate to hand out, but on the IPv6 side the address determines which TLS certificate to return. This or similar may be fairly common as IPv4 is much more address-constrained. The result is that a bad association will return in clints seeing the wrong certificate. There are lots of similar but more subtler corner-cases here. * Related to the previous, it will be tricky to figure out how to handle a set of IPv4 addresses from A records and sets of IPv6 addresses from AAAA records. It will be important to make sure to have some permutations of the association to avoid hotspotting. * The aliasing issue may result in effectively dual-stacking some IPv4-only content which would also be a serious problem. (This is related to #4 below as well.) For #4 (major security risk / vulnerability): It seems like a malicious actor can cause one client (eg, a browser visiting web sites) to create lots of bad associations by returning A/AAAA associations unrelated to them. If done for IPv4-only content and in a consistent manner, this seems like it can be used to hijack this content. This vulnerability may be a death-nail for this DNS approach, at least without a hostname allowlist. * Take an IPv4-only site "www.example.com" which returns an IPv4 address "192.0.2.2" (with a fairly short DNS TTL) * Malicious attacker tricks a client in the same network to resolve " hostile.example.net" (eg, as a single-pixel ad) which has {"2001:db8::2:2","192.0.2.2"} but with long DNS TTLs. The attacker doesn't need to have any relationship to the IPv4 address to perform this attack. * Now clients (even dual-stack clients) trying to visit "192.0.2.2" will have their traffic sent to the attacker-controlled IPv6 address ("2001:db8::2:2"), which could be a middlebox for surveillance, or something to try and phish the user, or even a DDoS target. This also potentially is a problem when the same IPv4 address has a mixture of dual-stack and IPv4-only hostnames pointing to it. Using DNS to remove EAMT entries might help a little here (eg, if IPv4-only hostnames with NODATA are found for AAAA lookups), but given that this is also a security vulnerability and given other issues (eg, widely differing DNS client behaviors and TTLs) it seems highly likely that this is very exploitable. Best regards, Erik --000000000000494b7f058fec5cd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some comments on draft-palet-v6ops-464xlat-opt-cdn-caches from t= he perspectives of having a $dayjob at a CDN....
This comes down = to three general concerns, plus a major security concern:

1) Will this= do more harm than good?=C2=A0 (ie, creating brokenness which motivates con= tent to switch back to IPv4-only)
2) Stateless EAMT just won't work due = to the typical rate of changes of A/AAAA pairings in the DNS
= 3) The IPv4:IPv6 associations may not be adequately 1:1 and client behavior= may be hard to anticipate
4) Poisoning risks/vulnerability=C2=A0 (a maj= or security consideration, which may make the DNS approach not viable)
TL;DR is that the security issue (an attacker being able to poiso= n the EAMT cache, which can
also happen non-maliciously as well) may mean th= e DNS-based approach is far too dangerous to deploy.

For #1=C2=A0 (the risk/concern factor)...

=
I= worry really worry that while the DNS association option is a clever hack,= that it will turn out to be highly fragile and problematic in reality.=C2= =A0 It only takes some corner-cases that are missed or one bad implementati= on for it to do much more harm than good.=C2=A0 (I wrote this even before I= realized the security issue listed below.)

One of the biggest chall= enges I'm already seeing on getting video content dual-stacked in some = parts of the world is consumer electronics with poor IPv6 implementations i= nteracting badly with buggy CPE/ISP/home-router configurations.=C2=A0 Even = if IPv6 is generally faster (and may be more available if a good happy eyeb= alls implementation is used), it only takes a relatively small number of su= bscribers with some Smart TV + ISP configuration that breaks in the face of= dual-stack content to cause a content provider to get enough calls to swit= ch the content back to IPv4-only.=C2=A0 I've seen this happen in at lea= st both the Nordics and East Asia.=C2=A0 I worry that this optimization fea= ture could introduce an entirely new class of problems like this if poorly = implemented.=C2=A0 If the only recourse content providers have is to switch= their content back to being IPv4-only (as that *may* make the difference b= etween content appearing broken to IPv4 users and between it appearing to b= e working), then this could hinder IPv6 usage much more than it helps.

<= /div>
O= ne approach that might help this would be to have hostname "allowed&qu= ot; lists, allowing a ISPs to turn this on for select content.=C2=A0 That c= ould still be problematic if the "allowed" list of hostnames over= laps on the same IPs as other content. It might at least provide for a way = for ISPs to use this feature with their own STB+content combinations, such = as for their own "walled garden" use-cases where they control bot= h the IPv4-only devices and the content being delivered.=C2=A0 (Getting rob= ust IPv6 support onto the devices would obviate the need for this, however.= )=C2=A0 Another possibility might be some opt-in mechanism?=C2=A0 (eg, if a= n additional DNS record is looked up that indicates that this translation i= s supported?)


For #2=C2=A0 (the state= less/stateful factor)...

The A/AAAA IPs retu= rned in DNS can be very dynamic.=C2=A0 For example, many CDNs have DNS TTLs= in the 20 second to 300 second range.=C2=A0 At least for Akamai, the assig= nments for which addresses are returned for A and AAAA lookups are done ind= ependently.=C2=A0 As such, frequent churn in associations should be expecte= d.

If the churn only impact new TCP connections then this part might wor= k some (much?) of the time (minus other caveats below).
However if the t= ranslation is stateless then this is going to be breaking TCP connections a= ll the time and will make this solution unusable.
It sounds l= ike the current EAM Table (EAMT) lookups are stateless?
This means= that each time an association is removed or changed that it will break all= of the long-lived connections using that association.=C2=A0 That seems lik= ely to result in lots of timeouts and rebuffering=C2=A0 (ie, as streams wil= l start playing and then will fail when the association changes or disappea= rs and the connection breaks).

I think a requi= rement for this solution to work would be for the EAMT table lookups to res= ult in stateful NAT entries on the home router.=C2=A0=C2=A0=C2=A0 (ie, the = lookups are just used to create stateful NAT entries for the 4-tuple for th= e duration of that session/connection.)


For #3 (IPv4:IPv6 associations may not be adequately 1:1= and client behavior may be hard to anticipate)
This issue has a longer = subset of concerns/issues.=C2=A0 The doc seems to touch on a bunch of them,= but I worry if there are lots of lurking corner-cases, each one of which c= ould cause problems.=C2=A0 Without a good way to fix or disable bad impleme= ntations, each one could be a major problem:

* Not all clients are good = at obeying DNS TTLs.=C2=A0 Some are really bad.=C2=A0 (eg, Java will someti= mes just do a single DNS lookup and use it for the duration of the process = lifetime.=C2=A0 Many major browsers also will use a connection for the dura= tion of its lifetime even if the TTL has changed.=C2=A0 In the best-case (w= ith stateful translation) this just results in more IPv4 due to less cache = entries.=C2=A0 In a bad case (without stateful translation) it could mean t= hat connections are pretty much guaranteed to break when they pass their TT= Ls and the EAMT entries time out but the clients keep using them.
=

* The aliasing issue (where the IPv4:IPv6 associations = between hostnames are far from 1:1) is real and will result in brokenness.= =C2=A0 The doc has a bunch of heuristics that help. but given how clients o= ften don't obey TTLs there may not be enough information available to d= etect and fix enough of these cases.=C2=A0 It seems like there are lots of = possibilities for timing and race conditions for cache entries.=C2=A0=C2=A0= As an example, I know of one case where IPv4 is shared by lots of hostname= s and SNI is used to determine which TLS certificate to hand out, but on th= e IPv6 side the address determines which TLS certificate to return.=C2=A0 T= his or similar may be fairly common as IPv4 is much more address-constraine= d.=C2=A0 The result is that a bad association will return in clints seeing = the wrong certificate.=C2=A0 There are lots of similar but more subtler cor= ner-cases here.

* Related to the previous, it will be tricky to figure o= ut how to handle a set of IPv4 addresses from A records and sets of IPv6 = addresses from AAAA records.=C2=A0 It will be important to make sure to hav= e some permutations of the association to avoid hotspotting.

* The alias= ing issue may result in effectively dual-stacking some IPv4-only content wh= ich would also be a serious problem.=C2=A0 (This is related to #4 below as = well.)


For #4 (major security risk / vulnerability):

<= div style=3D"font-family:tahoma,sans-serif" class=3D"gmail_default">It seem= s like a malicious actor can cause one client (eg, a browser visiting web s= ites) to create lots of bad associations by returning A/AAAA associations u= nrelated to them.=C2=A0 If done for IPv4-only content and in a consistent m= anner, this seems like it can be used to hijack this content.=C2=A0 This vu= lnerability may be a death-nail for this DNS approach, at least without a h= ostname allowlist.=C2=A0

* Take an IPv4-only site "www.example.com" which returns an IPv4 add= ress "192.0.2.2" (with a fairly short DNS TTL)
* Malicious att= acker tricks a client in the same network to resolve "hostile.example.net" (eg, as a single-pixel= ad) which has {"2001:db8::2:2","192.0.2.2"} but with l= ong DNS TTLs.=C2=A0 The attacker doesn't need to have any relationship = to the IPv4 address to perform this attack.
* Now clients (even dual-stack c= lients) trying to visit "192.0.2.2" will have their traffic sent = to the attacker-controlled IPv6 address ("2001:db8::2:2"), which = could be a middlebox for surveillance, or something to try and phish the us= er, or even a DDoS target.

This also potent= ially is a problem when the same IPv4 address has a mixture of dual-stack a= nd IPv4-only hostnames pointing to it.
Using DNS to remove EAMT= entries might help a little here (eg, if IPv4-only hostnames with NODATA a= re found for AAAA lookups), but given that this is also a security vulnerab= ility and given other issues (eg, widely differing DNS client behaviors and= TTLs) it seems highly likely that this is very exploitable.

Best regar= ds, Erik

=C2=A0
--000000000000494b7f058fec5cd0-- From nobody Tue Aug 20 08:10:28 2019 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7332120949; Tue, 20 Aug 2019 08:10:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156631382684.465.16386178399777035146.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 08:10:26 -0700 Archived-At: Subject: [v6ops] v6ops - New Meeting Session Request for IETF 106 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 15:10:27 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: spring, lsr, 6man, intarea, idr Key Participant Conflict: rtgwg, tsvarea, panrg, grow, tsvwg People who must be present: Fred Baker Ron Bonica Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Aug 27 11:23:21 2019 Return-Path: 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 DD576120089 for ; Tue, 27 Aug 2019 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVYljSBow6mC for ; Tue, 27 Aug 2019 11:23:17 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 645EE1200C7 for ; Tue, 27 Aug 2019 11:23:17 -0700 (PDT) Received: from [192.168.1.7] (ppp-94-64-234-190.home.otenet.gr [94.64.234.190]) by calypso.otenet.gr (ESMTP) with ESMTPA id C0175138131 for ; Tue, 27 Aug 2019 21:23:13 +0300 (EEST) To: v6ops@ietf.org References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> From: Yannis Nikolopoulos Message-ID: Date: Tue, 27 Aug 2019 21:23:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7B83213F303DC81826160E34" Content-Language: en-US Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 18:23:20 -0000 This is a multi-part message in MIME format. --------------7B83213F303DC81826160E34 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit (late to the party) +1 On 7/23/19 4:13 PM, Lorenzo Colitti wrote: > On Tue, Jul 23, 2019 at 4:29 AM Fred Baker > wrote: > > Do we agree to take draft-linkova-v6ops-nd-cache-init as a working > group draft? > > > I support adopting this draft as a WG document. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------7B83213F303DC81826160E34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit (late to the party) +1

On 7/23/19 4:13 PM, Lorenzo Colitti wrote:
On Tue, Jul 23, 2019 at 4:29 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:
Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group draft?

I support adopting this draft as a WG document. 

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

--------------7B83213F303DC81826160E34-- From nobody Tue Aug 27 12:11:37 2019 Return-Path: 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 621E8120145 for ; Tue, 27 Aug 2019 12:11:35 -0700 (PDT) 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, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFPGVP-L29IX for ; Tue, 27 Aug 2019 12:11:34 -0700 (PDT) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECA512012E for ; Tue, 27 Aug 2019 12:11:33 -0700 (PDT) Received: by mail-wr1-f50.google.com with SMTP id q12so19866458wrj.12 for ; Tue, 27 Aug 2019 12:11:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ytGJSriDOAE7/3xPNWqK7Xepk5mmiZM8ahIrmL+vYk=; b=VfEDYIKmfYmvL84fbCm4emkItTNajudGuMXCFclxk0/6gzqZRMTS3p5Doj7o0MP0Id SGOaU1WqVuHtZeVK78JyDsjr8pzvVlGeQ0pWx7YqvXP7ItBiUED1aFqsKR1UsyIBripX UmQNj43wl4858UdelVfcljyJ5rJ6EKY6O2GVJpPoV2yeUmdG0kDVZr8B+I0OdIted5YY jEPzh5oScyxPbLFVCuBdltJ8okM6bqLenemGA2mN2PDJI16G4rVTV+AEZIb6NeveRegs g9UxfNsKs3rgtjinMHcRfEzNdjG3ucCL5ZbC0TmOkgGVIczZHFhe4+obxgEklr9Q3hzY hJOQ== X-Gm-Message-State: APjAAAVz0LXmwtzCSulNMXMZiLd2Qa+3grtH+tX8shVkmtvfPD1bJvoo FltnSF1hoFX/ARUIMzZgVgc8BhFb/GmLUlJcCYU= X-Google-Smtp-Source: APXvYqyRCSatk7xR5UOiXkxdwWnM608QKblpO9ytHBPB7H4hKW1NbphfGCBORPCVLREyD7vpOMC7SkxNe8wdhy66/WE= X-Received: by 2002:adf:9e09:: with SMTP id u9mr31536615wre.169.1566933092127; Tue, 27 Aug 2019 12:11:32 -0700 (PDT) MIME-Version: 1.0 References: <351E8A83-734C-448D-B0C6-212C09D564F4@gmail.com> In-Reply-To: From: Erik Nygren Date: Tue, 27 Aug 2019 15:11:21 -0400 Message-ID: To: Yannis Nikolopoulos Cc: "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="00000000000057d8d505911e0a20" Archived-At: Subject: Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:11:36 -0000 --00000000000057d8d505911e0a20 Content-Type: text/plain; charset="UTF-8" Also +1 to adopting. On Tue, Aug 27, 2019 at 2:23 PM Yannis Nikolopoulos wrote: > (late to the party) +1 > > On 7/23/19 4:13 PM, Lorenzo Colitti wrote: > > On Tue, Jul 23, 2019 at 4:29 AM Fred Baker > wrote: > >> Do we agree to take draft-linkova-v6ops-nd-cache-init as a working group >> draft? >> > > I support adopting this draft as a WG document. > > _______________________________________________ > v6ops mailing listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000057d8d505911e0a20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also +1 to adopting.

On Tue, Aug 27, 2019 at 2:23 PM Ya= nnis Nikolopoulos <yanodd@otenet.gr<= /a>> wrote:
=20 =20 =20
(late to the party) +1

On 7/23/19 4= :13 PM, Lorenzo Colitti wrote:
=20
Do we agree to = take draft-linkova-v6ops-nd-cache-init as a working group draft?

I support adopting this draft as a WG document.=C2=A0

= 
____________=
___________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf=
.org/mailman/listinfo/v6ops

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