Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 31 July 2020 14:37 UTC

Return-Path: <Fred.L.Templin@boeing.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 691963A13C7; Fri, 31 Jul 2020 07:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 hGMn8LOoS0wG; Fri, 31 Jul 2020 07:37:21 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 774243A13AE; Fri, 31 Jul 2020 07:37:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06VEbGZO016274; Fri, 31 Jul 2020 10:37:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596206237; bh=iw0hVFkc4Mtq5Gqp4q+Dk/EeKv6rpDxRKobRbFyj+fE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Adyi/qP965/PqVIEMN8snAMLyKpFUQSVN/9leG1pgL8By3THYqG7fW05ALsWdXdoP /+lPxIe89EVsAylBDXlREaGzz4h62weMU42J1DbGyLrjswybjKG+fixwC42sgsma2G 1mZ2+75NkQcZn3zW7J0M5yuOjfFVsQ7FQ9QmOmELcEm6akxU0F28uLdUgGS0t6h3c0 /xIJNSjS5visk6o0/0K49rKkMLliHC/r0zvITRvCEn7XaGcn/Dyjy638PmBg6MRwEF gjXduVq4jLj4yZ0ryets6MrhWTFxx/b7TGOUKtyMXbB0+8xLu+s7YUOMGAqrbVdnx2 CNwL0rL10A5Gg==
Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06VEaxRp013690 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 10:36:59 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Fri, 31 Jul 2020 07:36:57 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Fri, 31 Jul 2020 07:36:57 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, "Mark Smith" <markzzzsmith@gmail.com>
CC: v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Thread-Topic: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns
Thread-Index: AQHWZkg+bCqL1AqpGEC9totP9gCMpakf412AgACQQgCAAC8SAIAAEaZdgAENTIA=
Date: Fri, 31 Jul 2020 14:36:57 +0000
Message-ID: <dfb9ccbfd87140cfba01c69447581aef@boeing.com>
References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <CAFU7BARePzdeU5DFgoOWyrF0xZCj67_xkC2t8vMN2nH0d8aUig@mail.gmail.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <CAFU7BATiD8RkiWXjrxGuAJU-BUwRQCErYZivUPZ-Mc_up_qGxQ@mail.gmail.com> <aebc46c9b813477b9ae0db0ef33e7bd9@huawei.com>, <CAO42Z2yL7+GbO6QRaNzFYoBXLF-JZ2NfwgTTt2zerKhJLwt2Lw@mail.gmail.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com>
In-Reply-To: <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 1BA0310AC6AFFFE9EAE76A6711E033F667EF2FEFE4976ABB5531A987A7C4CC902000:8
Content-Type: multipart/alternative; boundary="_000_dfb9ccbfd87140cfba01c69447581aefboeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/UZi9FHiqT1W7SEdNM2gPuVmwFu0>
Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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, 31 Jul 2020 14:37:29 -0000

Hi Pascal,

I wish this group could open its eyes. ND as defined in the last century is not suited for modern fabrics, virtual machines and wireless. It is a pain for silicon-based forwarding. Time to upgrade is overdue.

There is nothing broken with IPv6 ND that needs changing; it just needs a new option.
We have seen how that is possible through publications like RFC8801.

BTW, IPv6 itself is a last-century technology but the architects had the wisdom to allow
for future extensions without needing to modify the core architecture.

Thanks - Fred

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, July 30, 2020 3:26 PM
To: Mark Smith <markzzzsmith@gmail.com>
Cc: v6ops list <v6ops@ietf.org>rg>; 6man <ipv6@ietf.org>
Subject: [EXTERNAL] Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns


This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.




I disagree with the analogy, Mark.

I support GRAND because it is better than nothing and progressing just that at 6MAN seems to be an incredible achievement already.

But in a world we’re all addresses are proactively installed the router could easily defeat the remote DOS against the cache (that’s an RFC 8505-only network and dhcpv6 vs autoconf is orthogonal to that, we are talking about provisioning the cache not forming the address)
For the insider impersonation attack, SeND may be dead but https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/ Is very much alive. The sad point from an IETF perspective is that it did not come from 6MAN.

Bottom line is that the spoon done right would not leak the soup.

To Jen’s reference we did not only do gleaning in the switch. We also do enforcement. And RA guard. And RA throttling. But an enforcement based on a snooped state is imperfect because we could miss stuff. And it’s all proprietary so it might become a bad idea retrospectively should the protocol change. This is why 10+ years ago we (the group who designed and implemented all this in Cisco routers) proposed the registration model that ended up as RFC 8505.

I wish this group could open its eyes. ND as defined in the last century is not suited for modern fabrics, virtual machines and wireless. It is a pain for silicon-based forwarding. Time to upgrade is overdue.

In the meantime, keep safe.

Pascal


Le 30 juil. 2020 à 23:24, Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>> a écrit :


On Fri, 31 Jul 2020, 04:35 Vasilenko Eduard, <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
Hi Jen,
OK. IPv6 SLAAC subnet is not secure in principle and we should abandon any attempt to improve it.

GRAND's goal is not and has never been to improve the security of ND. There is no statement such as "The goal of GRAND is to improve the security of ND."

This draft describes the problem space.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/

There are some useful security benefits of the way it will prepopulate routers' ND caches with nodes' new addresses. However, if none of those benefits existed, it wouldn't invalidate GRAND as a solution to the problem GTAND is designed to solve.

Making the primary criticism of GRAND being about ND security is like criticising a spoon for being a terrible knife.

Regards,
Mark.



Because so many people already spent so much time on this matter - it is just does not make sense to talk again and again.
And the primary solution that they found is the stateful "binding table" on the switch to monitor all NDs (like DHCP/ARP in IPv4), that not many use anyway - we need to fix unsecure solution.

Then your dilemma is not important, 7sec traffic hijacking could not happen unintentionally - probability for address collision on /64 is too low, whatever Interface IDs would be used (collection of RFCs exist).
Eduard
-----Original Message-----
From: Jen Linkova [mailto:furry13@gmail.com<mailto:furry13@gmail.com>]
Sent: 30 июля 2020 г. 12:58
To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>
Cc: 6man <ipv6@ietf.org<mailto:ipv6@ietf.org>>; v6ops@ietf.org<mailto:v6ops@ietf.org>
Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security concerns

On Thu, Jul 30, 2020 at 6:05 PM Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
> Then it is not logical for me:
> Many people understand that "Unsolicited NA" is a big security hole
> per se, But instead of fixing it (may be even deprecate - should be
> investigated)

There are many attacks possible within the same L2 segment. It's not new. That's why you shall either block p2p with the LAN (if you do not trust endpoints in general) or - better - hosts shall use end2end encryption.

> Additional functionality is building on top of it.

Sorry, I'm not sure I understand why unsolicited NA is the problem here.. The mechanism I described in my previous email is using
*solicited* NA to override the neighbor cache on the router.

> It would additionally challenge this security problem resolution in the future!
>
> Again: "Unsolicited NA" with Override bit set - is a disaster now.

As well as Solicited, right? ;) Shall we look at SEND again? ;) It would be great but I'm not aware of implementations being widely deployed.

> IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for the case of MAC address change on legitimate host.
> May be we could think about other solutions.
> But if additional functionality would be built on top of "Unsolicited NA" - less options would be available ("deprecate" would be not a choice anymore).
>
> If something is ill - it should be cured first - bodybuilding make sense only after this.
>
> Jen, I have not understood below why you did mention RA Guard. Intruder does not need it. He just claim (by Unsolicited NA) that his MAC is connected to GUA of victim.

Yes, to intercept traffic *to* the victim. How is it going to intercept packets sent by the victim?

> Intruder could claim it every 5 seconds to keep cache in STALE state (for the case of very careful vendor implementation of ND).
> As you mentioned - no help from MLD snooping on switches - it would be enough to just listen to DAD. Switch could not help in principle.

Strictly speaking, if the switching infrastructure implements MLD snooping, the attacker would need either to guess the lower 24 bits of the victim's address or to join 2^24 solicited node multicast address groups.

> The first modified DNS response would convert traffic flow to bi-directional for Intruder.

That's why DNSSEC and DNS over TLS and HTTPS are good for security.

> -----Original Message-----
> From: Jen Linkova [mailto:furry13@gmail.com<mailto:furry13@gmail.com>]
> Sent: 30 июля 2020 г. 5:07
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>
> Cc: 6man <ipv6@ietf.org<mailto:ipv6@ietf.org>>; v6ops@ietf.org<mailto:v6ops@ietf..org>
> Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional
> security concerns
>
> On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
> > You did ask a feedback yesterday about severity of 7sec security hole that has very low probability.
> > I have intention here to show that probability is 100%, 7sec could be prolonged to forever, and the final result is the full interception of innocent host traffic by intruder (successful "man-in-the-middle").
> >
> > Pre-request for success:
> > - no multicast snooping (MLD) and filtering on a switch, that is
> > perfectly possible
> > - Intruder should be already on the same subnet (gained control over
> > other host by exploiting of different vulnerability)
> > - intruder should suppress DAD on Intruder's controlled host (is
> > Windows firewall capable to filter out DAD?)
> > - We assume that we are talking about the future when this draft is
> > used by majority of nodes (victim should use it)
> >
> > Procedure:
> > Intruder's controlled host does listen to all-routers multicast address (ff02::2).
> > As soon as it would eavesdrop unsolicited NA from victim node (probably after boot) - Intruder would immediately (a few milliseconds) duplicate NA in router's direction, but with 2 changes: (1) his LLA (MAC); (2) Override bit set.
> > Intruder has time only up to the point that response to victim's traffic would be returned from the Internet (from tens of milliseconds to many seconds if victim would not start sending immediately), - but it is enough time: local communication should be faster.
> > Theoretically, RetransTimer should be imposed on unsolicited NA (section 7.2.6), but low chances that this timer is checked on receiving side (router), because RetransTimer is specified for transmission side.
> > According RFC 4681 section 7.2.5 clause II: O bit set should not just rewrite ND cache, but additionally mark ND record as REACHABLE. According to section 7.2.6: " The Override flag (for unsolicited NA) MAY be set to either zero or one". Despite it contradicts to the logic of the whole RFC 4681 (O bit should not be set in unsolicited NA - it is mentioned in a few places of RFC 4681). But because section 7.2.5 and section 7.2.6 clearly permit to use Override flag - higher probability that particular implementation would not just rewrite LLA on router, but additionally put it into REACHABLE.
> > Intruder could be sure that at least STALE state would be created according to section 7.2.5 clause I, - this ND record would be against his LLA anyway.
> > After receiving return traffic (if it was created as STALE, not REACHABLE) - router would ask intruder about reachability (solicited NS-NA) - intruder would confirm his LLA - it would finally put ND cache record into REACHABLE.
>
> 1) the 7 seconds corner case was for 'preventing address collision for Optimistic DAD', not for any intentional attacks case. Because:
> 2) What you are describing could be done today, now, anytime w/o the changes described in the draft. If there is no MLD snooping then the intruder would see the DAD packet from the victim, so it would know the victim address anyway  - no reason even to join ff02::2. Now all the attacker needs to do is to keep sending NA with S=1, O=1 - hoping that when the first packet of the return flows arrive and the router creates an INCOMPLETE entry and sends an NS, the attacker's packet would come before the victim's NA. Done, the  entry is changed to REACHABLE, all traffic goes to the attacker.
> Actually even simpler. The attacker does not need to deal with timing.
> Let's say the router has an NC entry for the victim address in any other state than INCOMPLETE. The attacker sends an NA with S=1, O=1, Target address = the victim's IPv6 address, the TLLA = the attacker MAC address.  Done. The router updates the cache entry and changes it to REACHABLE state.
>
> There is nothing new here. We have the same issue with ARP - the attacker can override ARP entry on the router.
>
> > That's it: upstream traffic of victim host is going to router, traffic back is going through Intruder.
> > I have consulted with penetration tests professional (these are people with the same qualification as hackers but they play on legal side): what he would be doing next? He said that he would return traffic to legitimate host - victim should not see performance degradation. He would collect cookies and some other valuable information. He would finally see DNS response, change it and redirect everything to himself on the permanent basis - he does want to see both directions of victim exchange. He has qualified Man-in-the-middle as full fiasco - it does open many opportunities for him. He has mentioned very good feature of this draft that there is no any interruption for victim's traffic flow, no any excessive traffic to victim, that is very rear benefit for hacker's tool.
>
> For all that doom and gloom the attacker would also need to see the traffic *from* the victim. Assuming the network has RA Guard in place it would be a bit harder. If the network does not have RA Guard our poor victim has much bigger problems already.
>
> > What to do about it?
> > 1. Potentially it is possible to do RPF-like check for Source LLA addresses. Upstream traffic from victim's SLLA would not be in ND cache - such traffic could be discarded. It is better to block communication than permit intruder to exploit vulnerability.
>
> > 2. Increase RetransTimer and ask receiver side (router) to check on sending side delay between ND record override (for the same SLLA). But how long should be the timer? Host could wait a lo-o-o-ng time before it would request 1st information from internet. It would decrease probability, but would not completely eliminate attack vector.
> >
> > My proposition for this draft is disruptive:
> > I believe that ND is very complicated (some could say "fragile") - it is better not to touch it.
> > Additionally I do not like to wait till all hosts would refresh to new draft (to get new functionality).
>
> Well, only hosts which want to connect to the network faster need to implement this. So host OS developers have pretty good incentive here.
> Please keep in mind that the proposed behavior is not currently prohibited. We are not changing any MUST NOT to anything else. All we are doing is to making some recommendations more explicit.
>
> > I propose to change only router behavior: check Source LLA (MAC) for every packet, if this SLLA is absent in ND cache - then request solicited NS-NA immediately. It would probably resolve faster than traffic would return from the internet.
>
> Have you checked the problem statement draft?
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-0
> 3#section-3.7
> specificatlly?
> What you are proposing does make sense, however it would not help in case of multiple routers. Also I recall some people having strong opinions on performance implications.
>
> > Effectively I do proposed the same SLLA RPF that is needed to fix current solution, but:
> > - without any modification to host OSes
> > - without any modification of standard (it is local recommendation
> > for router, NS-NA is exactly the same from RFC 4681, NA is unicast -
> > it is important for security)
> > - without any risk to break ND fragile algorithm
> > - it could be optional, or even configurable on the router as "value
> > add feature" in competitive tender Because it is just best practice recommendation - may be it make sense to move it to "v6ops"?
>
> See
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-0
> 3
>
> > PS: Looking to the above - unsolicited NA should be really delayed by additional big timer (not by RetransTimer that is used for solicited NS/NA) and checked on receiver side - this modification of standard is really needed to close Unsolicited NA vulnerability.
> > Somebody said on the call that it is already a feature of some OS (Android?) - it is bad: it means that this OS is already vulnerable.
>
> I was saying that some routing platforms have this already implemented.. Search for 'glean' here:
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configura
> tion/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html
>
> AFAIK there are implementations which are also prepopulating NC from DAD packets but I can not find you a reference right now.
>
> > From: ipv6 [mailto:ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>] On Behalf Of Jen Linkova
> > Sent: 27 июля 2020 г. 7:49
> > To: 6man <ipv6@ietf.org<mailto:ipv6@ietf.org>>
> > Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt
> >
> > Hello,
> >
> > The -01 version addresses comments received (thanks everyone who provided feedback). Also, Section 3 (Avoiding Disruption) has been expanded and discussed a corner case when two devices start using the same address almost at the same time (the second device configures an optimistic address after the rightful owner sent some packets but before the return traffic arrives).
> > Feedback on the updated section 3.3
> > (https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is very much appreciated.
> >
> > On Sun, Jul 26, 2020 at 10:14 AM <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > > This draft is a work item of the IPv6 Maintenance WG of the IETF.
> > >
> > >         Title           : Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
> > >         Author          : Jen Linkova
> > >         Filename        : draft-ietf-6man-grand-01.txt
> > >         Pages           : 12
> > >         Date            : 2020-07-25
> > >
> > > Abstract:
> > >    Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
> > >    link-layer addresses of neighboring nodes as well as to discover and
> > >    maintain reachability information.  This document updates RFC4861 to
> > >    allow routers to proactively create a Neighbor Cache entry when a new
> > >    IPv6 address is assigned to a node.  It also updates RFC4861 and
> > >    recommends nodes to send unsolicited Neighbor Advertisements upon
> > >    assigning a new IPv6 address.  The proposed change will minimize the
> > >    delay and packet loss when a node initiate connections to off-link
> > >    destination from a new IPv6 address.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-6man-grand/
> > >
> > > There are also htmlized versions available at:
> > > https://tools.ietf.org/html/draft-ietf-6man-grand-01
> > > https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01
> > >
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-grand-01
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > >
> > > ------------------------------------------------------------------
> > > -- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org>
> > > Administrative
> > > Requests: https://www..ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
> > > ------------------------------------------------------------------
> > > --
> >
> >
> >
> > --
> > SY, Jen Linkova aka Furry
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative
> > Requests: https://www.ietf..org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
> > --------------------------------------------------------------------
>
>
>
> --
> SY, Jen Linkova aka Furry



--
SY, Jen Linkova aka Furry
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops