Subject: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

From: The IESG <[email-masked]>
Date: Tue, 29 May 2012 07:39:00 -0700

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)'
  <draft-ietf-v6ops-ra-guard-implementation-04.txt> as Best Current
Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-06-12. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly
   employed to mitigate attack vectors based on forged ICMPv6 Router
   Advertisement messages.  Many existing IPv6 deployments rely on RA-
   Guard as the first line of defense against the aforementioned attack
   vectors.  However, some implementations of RA-Guard have been found
   to be prone to circumvention by employing IPv6 Extension Headers.
   This document describes the evasion techniques that affect the
   aforementioned implementations, and formally updates RFC 6105, such
   that the aforementioned RA-Guard evasion vectors are eliminated.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 29 May 2012 12:38:05 -0400

>  <draft-ietf-v6ops-ra-guard-implementation-04.txt> as Best Current

While I generally support publication of this document, there is 
a blocking issue that ought to be resolved prior to publication.

1) Layer-2 Processing Rule causes valid IPv6 packets to be dropped

  MULTIPLE ISSUES:

  Rule #4 in this document is overly restrictive.  Implementing
  this rule has the effect of changing the IPv6 specifications
  to prohibit otherwise legitimate packets that violate this new
  and somewhat arbitrary rule, which is an unreasonable change.  
  In effect, this cure (i.e. Rule 4) is worse operationally than 
  the potential disease.

  This rule can cause entirely legitimate IPv6 packets to be dropped,
  neither because they are invalid, nor because those packets 
  violate IPv6 specifications, nor because their header chain is
  too long (from a specification & legitimacy perspective),
  nor because they are security risks.  Instead, such packets are
  dropped because a Layer-2 device lacks sufficient information
  to perform a Layer-3 function (i.e. packet parsing/inspection).

  Further, Layer-2 only devices (e.g. Ethernet bridges/switches) are 
  commonly, correctly, and legitimately used to interconnect different 
  segments of the same IPv6 subnetwork.  So a Layer-2 device cannot 
  know whether a particular RA Advertisement is valid or not -- that 
  information is simply not available at Layer-2 in a dependable way.
  Absent manual configuration that tells the Layer-2 device which ports
  might connect to routers, the Layer-2 device separately cannot know
  which "ports ... are not allowed to send ICMPv6 Router Advertisement
  messages".  

  Separately, in a network that contains wireless elements, routers
  might connect to different Layer-2 base stations at different times.
  In turn, those different Layer-2 base stations are very likely to 
  connect to different Layer-2 ports on different Layer-2 switches/bridges.
  Such Layer-2 switches/bridges generally cannot know that a wireless
  aspect exists in the deployment.  So this is another reason that a
  Layer-2 only device is not the correct place to be trying to filter
  ICMPv6 RA packets.

  Removing this rule creates no new security risk as the any actual
  problem packet can be detected and dropped later -- either by an 
  IPv6-capable router or an IPv6-capable firewall -- one that is 
  located at an IPv6 subnetwork boundary.

  There are existing openly specified, legitimate, IPv6 Destination
  Options that can be somewhat large in size (notably: CALIPSO).
  While such packets are not common, they are entirely legitimate
  and valid.  A BCP from an operationally focused WG ought not
  be recommending that valid IPv6 packets be dropped, as this will
  impede deployment of IPv6.

  PROPOSED ACTION:

  The current Rule #4 should be have its meaning inverted (i.e. If a
  Layer-2 device is unable to identify whether the packet is an ICMPv6
  Router Advertisement, then the packet should be transmitted without
  modification) and text referring to that rule also should be edited 
  heavily to outline the issues noted above as the reason for the
  "transmit if in doubt" policy for a Layer-2 device.

OBSERVATION:
  The only fully secure networks are those that move no packets at all.
  So our goal ought not be a "fully secure" network.  Instead, the goal
  should be taking reasonable, practical steps to reduce operational
  risks to an acceptable level -- while allowing all valid IPv6 packets
  to use the network.

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Tue, 29 May 2012 17:21:39 -0300

Hi, Ran,

Thanks so much for your comments!

Meta-answer: This document is a BCP on how to implement RA-Guard, *not*
a BCP that RA-Guard should be deployed. -- i.e., we're not saying
whether you should or should not deploy ra-guard, but rather "if you
implement ra-guard, you should do it this way".

-- I'm just double-checking that this is the angle from which you've
read the document...

More comments inline...

>   In effect, this cure (i.e. Rule 4) is worse operationally than 

To some extent, RA-Guard does firewalling at layer-2. This means that,
as with stateless filtering, there's a point at which you need to draw a
line that says what you consider acceptable, and what not... and as with
layer-3 stateless firewalls, there is (at leasttheoretically speaking) a
risk of false positives. If those false positives outweigh the benefits
of firewalling in the first place, you simply do not deploy the firewall
(or in this case, RA-Guard)

(more comments below)

>   information is simply not available at Layer-2 in a dependable way.

I those scenarios, you either manually configure every layer-2 device in
an appropriate way, or you simply do not deploy ra-guard.

>   which "ports ... are not allowed to send ICMPv6 Router Advertisement

Exactly. You should manually configure the device with this information,
*and* you should manually enable ra-guard.

>   Layer-2 only device is not the correct place to be trying to filter

In those scenarios, you'd simply not deploy ra-guard.

As noted at the beginning of this e-mail, my take is that you assume
that we're encouraging ra-guard deployment for the general case, But
this document simply specifies how you should *implement* ra-guard, and
doesn't argue in favor (or against) its deployment.

>   located at an IPv6 subnetwork boundary.

How would you block malicious RAs originating from the local subnetwork?

>   Options that can be somewhat large in size (notably: CALIPSO).

My take is that if you setup employs CALIPSO, and it leads to packets
with a header chain that spans multiple local MTUs, then you'd simply
not deploy RA-Guard.

That say, would CALIPSO packets really lead to IPv6 header chains that
would span past 1500 bytes, or even past 1280 bytes?

>   "transmit if in doubt" policy for a Layer-2 device.

As noted above, this document just specifies how to implement RA-Guard,
When it comes to actual deployment, there are may be trade-offs (as
discussed above). But if you do decide to deploy RA-Guard, you probably
do not want a "default allow" rule (because attackers would certainly
use any of the evasion techniques described in the document)...

Please do let me know what you think...

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 29 May 2012 21:02:35 -0400

> -- I'm just double-checking that this is the angle from which you've

Yes.  If a Layer-2 device that implements the RA Guard feature is unable 
to discern whether a packet contains an RA or not -- then that device 
ought to bridge/transmit the uncertain packet rather than drop it.

> To some extent, RA-Guard does firewalling at layer-2.

No.  It doesn't.  If one wants to raise the issue of options,
optional headers, and fragmentation, then one really really
has some Layer-3 capabilities -- or ought to.

> This means that,as with stateless filtering, there's a point at which you
> need to draw a line that says what you consider acceptable, and what not...
> and as with layer-3 stateless firewalls, there is (at least theoretically
> speaking) a risk of false positives. If those false positives outweigh the
> benefits of firewalling in the first place, you simply do not deploy the firewall

Not a good comparison.  Many stateless firewalls that are widely 
deployed transmit uncertain packets, rather than dropping them.

Separately, folks do NOT want IPv6 to be broken and balkanised
in the way that IPv4 was.  This spec can be fixed.  The earlier
note described a simple and sufficient fix.

> an appropriate way, or you simply do not deploy ra-guard.

That doesn't work, as I noted in the original post.

> *and* you should manually enable ra-guard.

However, this document doesn't require that such implementations
even possess the capability of being configured with that data.
So again, not a good reason.

> In those scenarios, you'd simply not deploy ra-guard.

That is not noted in Security Considerations for this document.

> that we're encouraging ra-guard deployment for the general case,

No I don't. 

> But this document simply specifies how you should *implement* ra-guard, and

The proposed implementation is broken.  It requires that RA-Guard
implementations drop completely valid non-RA IPv6 packets in some 
situations.

> How would you block malicious RAs originating from the local subnetwork?

With a real RA Guard, implemented properly, that knows it is dropping
packets that (1) contain an RA message type and (2) are invalid.

The problem is with your concept of a Layer-2 only device that
is an RA Guard.  The functions needed to make a correct determination
about packets aren't available in (most, all) Layer-2-only devices.

Devices that implement RA Guard need to have at least sufficient 
Layer-3 capabilities to distinguish RA packets from non-RA packets.
With such correct implementations, Rule 4 being inverted is a hop.
With incorrect implementations, Rule 4 being inverted ensures that
valid IPv6 packets are not dropped.

> As noted above, this document just specifies how to implement RA-Guard,

...which specification is incomplete or wrong, as I noted in my
previous note.

> use any of the evasion techniques described in the document)...

(ASIDE:  "Security Considerations" needs more specific and detailed 
discussion of those deployment and operational trade-offs than it has
at present.)

I know of lots of folks who'd be interested in RA-Guard, if the 
specification weren't broken in a way that can cause valid IPv6 packets 
that are not RA packets to be dropped.  So they would prefer the 
inversion of Rule 4.

One of the main advantages of IPv6 is that it is not currently broken
by lots of mis-specified (pseudo-)security devices.  Please change
this document so that it won't cause valid IPv6 non-RA packets to
be dropped.  Please don't break IPv6.

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Wed, 30 May 2012 02:55:04 -0300

Hi, Ran,

> ought to bridge/transmit the uncertain packet rather than drop it.

But that would essentially break RA-Guard's ability of mitigating
RA-based attacks...

> has some Layer-3 capabilities -- or ought to.

Well, strictly speaking, one already needs some layer-3 capabilities
just to parse the layer-3 header...

> deployed transmit uncertain packets, rather than dropping them.

I didn't say "*all* stateless firewalls". That aside, I'm generally of
the idea that if you do deploy a firewall, you should do "default deny"
(rather than 'default allow').

> note described a simple and sufficient fix.

People are already filtering stuff in v6. From ICMPv6, to unrecognized
extension headers.

Packets in which the IPv6 header chain spans multiple fragments already
break things such as state-less translators (which, given the level of
v6 deployment, we should expect to be able to live with for quite some
time). That aside, since they would essentially make state-less
filtering impossible, I really doubt you can assume that they will pass
stateless filters.

While, packets in which the IPv6 header chain spans multiple packets
are, strictly speaking, legitimate, I wonder whether this was actually
intended. -- Recent discussions regarding the IPv6 MTU seem to indicate
that the magic number '1280' came up from expecting the full IPv6 packet
(plus outer headers for tunnels) to fit within the the common 1500-byte
MTU. For instance, if the IPv6 header chain spans multiple packets, you
end up having more than 50% overhead...

> That doesn't work, as I noted in the original post.

Not sure what you mean. You can deploy RA-Guard only in those scenarios
in which you know that the router will be connected to a specific
layer-2 port (such that you can configure the layer-2 device to allow
RAs only on that port). If, for some reason, you cannot tell beforehand
on which layer-2 port you will connect your local router, then RA-Guard
is not appropriate for your scenario, and you shouldn't deploy/enable it.

> So again, not a good reason.

Well, I assumed this to be a 'requirement' ("implication", if you want)
from  RFC 6105. But I agree that we might need to make this explicit in
this document -- I'd also have no problem with adding that the RA-Guard
feature should be 'off' by default, too.

> That is not noted in Security Considerations for this document.

Good point. I'll craft some text about this, and post it for review...

> implementations drop completely valid non-RA IPv6 packets in some 

There's certainly a possibility of false positives (for instance, this
is already noted in the document). However, that's the trade-off for
being able to prevent RA-based attacks. And it's something that you
deploy in your local network -- not some filter that you deploy in the
middle of the network.

> packets that (1) contain an RA message type and (2) are invalid.

Then you wouldn't block them. I'd just add multiple extension headers,
and fragment the resulting packet...

> Layer-3 capabilities to distinguish RA packets from non-RA packets.

The only way to do RA-Guard with zero possibility of false positives is
to have the ra-guard device implement layer-3 reassembly. But since RAs
are supposed to operate on a subnet, such devices is not supposed to be
there, and hence such approach wouldn't be purist, either.

> With such correct implementations, Rule 4 being inverted is a hop.

If it's a hop, then you should decrement the Hop Limit. And the RA would
be discarded (since the Hop LImit would not be 255, as currently required).

> that are not RA packets to be dropped.  So they would prefer the 

We essentially have to options here:

1) Have RA-Guard be effective to mitigate RA-based attacks, accepting
the fact that there's a possibility for false positives.

2) Have RA-Guard have a "default allow" policy, at which point it
becomes useless for mitigating RA-based attacks.

I have no problem with elaborating on the issue of false positives, and
being more explicit about considerations that should be made when
enabling RA-guard. But specifying a "security" devices that cannot
handle well-known evasion techniques (for which there are even publicly
available tools) doesn't seem to make much sense.

Regarding false positives: Do you have any estimates regarding how large
e.g. CALIPSO options could be in practice?

> by lots of mis-specified (pseudo-)security devices.

Well, strictly speaking, you're right: it is broken by mis-behaving(?)
devices. ICMPv6 is reportedly broken, and devices are already filtering
unrecognized headers.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 30 May 2012 09:34:25 +0200 (CEST)

Hello,

Just focussing on this rule #4 :
Seems to me that packets that would match this rule
might be theoretically valid, but in practice : questionable/dubious
packets.

If a packet is constructed is such a way that, before the end of the first
fragment is reached, one cannot determine if it is a RA,
I do have my questions about the nature (malicious ?) of this packet.

Compare it to IPv4 "options" : I always configured my routers to drop
IPv4 packets that had any options.  Not needed for any "production
traffic".
(unfortunately, such a simple solution does not exist, for IPv6 ...)

(out of scope for this document, but in reply to statement made)
About IPv6 not being broken by security devices :
I wonder how many security devices actually implement some kind of
security for IPv6 and if, to what extend.
Fact is that most vendors I had contact with claim to support IPv6,
but when starting to ask some further questions, it is usually
"back to some guru in the back office", with usually a "not yet"
response afterwards.

Kind regards,

Marc Lampo
Security Officer
EURid

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]] 
Sent: 30 May 2012 03:03 AM
To: Fernando Gont
Cc: [email-masked]
Subject: Re: [v6ops] Last Call:
<draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice
for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

...

I know of lots of folks who'd be interested in RA-Guard, if the
specification weren't broken in a way that can cause valid IPv6 packets
that are not RA packets to be dropped.  So they would prefer the inversion
of Rule 4.

One of the main advantages of IPv6 is that it is not currently broken by
lots of mis-specified (pseudo-)security devices.  Please change this
document so that it won't cause valid IPv6 non-RA packets to be dropped.
Please don't break IPv6.

Yours,

Ran

---

From: Ray Hunter <[email-masked]>
Date: Wed, 30 May 2012 10:16:05 +0200

+1 Agree with Fernando. Disagree with Ran. I don't agree that this is a 
blocking factor, and believed the WG had reached rough consensus.

IMHO Initially, I was also concerned about false-positives, but after 
careful consideration I believe that if someone has chosen to implement 
RA Guard then the benefit of day 0 attack protection from 
false-negatives is worth far more than the downside of potentially 
dropping some false-positive link-local-only ICMPv6 packets.

Operational experience has proven a "drop unknown by default" rule to be 
necessary: the reason this ID was written was because previous RA-Guard 
implementations which only filtered on positive identification were 
being bypassed in the wild.

Flipping the default behaviour to "allow unknown by default" as Ran 
suggests, would IMVHO require tightening up the spec for an RA message 
so that they could always be 100% reliably parsed in all instances 
(including end host implementations) for RA Guard to remain useful, but 
that is outside the scope of the ID and would also limit future 
developments.

If as an end user you don't like this compromise, don't buy a L2 switch 
that implements RA-Guard. Or turn it off globally. Or configure the port 
to be a router port (that allows all messages).

regards,
RayH

---

From: Washam Fan <[email-masked]>
Date: Wed, 30 May 2012 16:39:06 +0800

Hi,

There is definitely theoretically false positives. But the possibility
should be very slim if rule 1-3 has been passed. Please note that only
if pass the previous 3 rules, the rule #4 would apply.

Thanks,
washam

2012/5/30 Ray Hunter <[email-masked]>:
> careful consideration I believe that if someone has chosen to implement RA
> Guard then the benefit of day 0 attack protection from false-negatives is
> worth far more than the downside of potentially dropping some false-positive
> link-local-only ICMPv6 packets.
>
> implementations which only filtered on positive identification were being
> bypassed in the wild.
>
> suggests, would IMVHO require tightening up the spec for an RA message so
> that they could always be 100% reliably parsed in all instances (including
> end host implementations) for RA Guard to remain useful, but that is outside
> the scope of the ID and would also limit future developments.
>
> If as an end user you don't like this compromise, don't buy a L2 switch that
> implements RA-Guard. Or turn it off globally. Or configure the port to be a
> router port (that allows all messages).
>
> regards,
> RayH
>
> Fernando Gont wrote:
>>
>> Hi, Ran,
>>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "George, Wes" <[email-masked]>
Date: Wed, 30 May 2012 12:29:33 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marc Lampo
> Sent: Wednesday, May 30, 2012 3:34 AM
>
>
> IPv4 packets that had any options.  Not needed for any "production traffic".

[WEG] I think there's a point of clarification here that makes this an invalid comparison. There's a very big difference between telling your router to *ignore* any IP Options it sees in packets going through the box (e.g. process/forward the packet as normal, but without taking any actions manipulated by the options) and in telling it to actually drop the packets altogether, either in general for all traffic through the box, or more specifically on "for us" packets destined for the router's control plane.
"ip options ignore" in Cisco parlance does the former, not the latter, mainly to prevent packets from being sent to the punt path and creating a DoS attack vector.  Indiscriminately Blocking/dropping packets with options configured is not a good idea unless you are operating a device whose position in the network means that you will definitely know whether or not there are any legitimate uses of options on the traffic traversing the device. Unless you have a very tight control on all of the uses of the network such that you know exactly what the traffic does and does not look like, making assumptions like that tend to get us into situations like we find ourselves in with legitimate ICMPv4 traffic being blocked by overzealous security admins. A recommendation in a BCP can't assume that much about the network, and therefore must be very careful in covering this in its recommendations.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 May 2012 12:40:42 -0400

I do see the importance of being apply to apply RAGuard in a device 
which does not accumulate fragment state.  (I don't want to try to 
analyze the potential DoS attack of having such state.)

However, the proposal introduces a network limtiation, essentially a 
protocol change, in the network.  I did not think v6Ops was free to 
recommend behaviors (dropping unclassifiable fragments) which basically 
violate the base IPv6 spec.

It seems that the right answer was discussed much earlier, namely 
changing the protocol behavior (a 6man activity) to tell hosts to reject 
RA and ND packets which were received in fragments.

If that is the right answer, then we have to be very careful about 
creating long-lived restrictions as a remediation until such a solution 
can be adopted.

Yours,
Joel

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 30 May 2012 15:32:51 -0400

Joel,

On the one hand, I don't think that v6ops is overstepping its charter. It isn't modifying IPv6. It is merely identifying a combination of IPv6 features that might spell trouble used in the same datagram. 

On the other hand, I would be thrilled if the 6man WG would update RFC 4443 to say something like "ICMPv6 packets MUST NOT be fragmented unless the ICMPv6 Type, Code and Checksum all fit in the first fragment".

                                                      Ron
                                                    <Speaking as individual contributor>

> Of Joel M. Halpern
> Sent: Wednesday, May 30, 2012 12:41 PM
> To: 'Fernando Gont'
> Cc: [email-masked]
> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-
> implementation-04.txt> (Implementation Advice for IPv6 Router
> Advertisement Guard (RA-Guard)) to Best Current Practice
> 
> changing the protocol behavior (a 6man activity) to tell hosts to
> reject RA and ND packets which were received in fragments.
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 30 May 2012 16:38:49 -0300

On 05/30/2012 01:40 PM, Joel M. Halpern wrote:
> protocol change, in the network.  

It's not a protocol change, but an operational mitigation. -- for
instance, there is no change in the way the sending router or the
receiving hosts process RAs.

Cheers,

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 30 May 2012 14:55:19 -0700

On 5/30/12 12:32 , Ronald Bonica wrote:
> Joel,
> 
> On the one hand, I don't think that v6ops is overstepping its
> charter. It isn't modifying IPv6. It is merely identifying a
> combination of IPv6 features that might spell trouble used in the
> same datagram.

It's saying that that packets matching the criterion should be discarded
in order to protect yourself from damage. That is to my mind a fairly
operational recommendation.

> On the other hand, I would be thrilled if the 6man WG would update
> RFC 4443 to say something like "ICMPv6 packets MUST NOT be fragmented
> unless the ICMPv6 Type, Code and Checksum all fit in the first
> fragment".

+1

> Ron <Speaking as individual contributor>
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Joel M. Halpern Sent:
>> Wednesday, May 30, 2012 12:41 PM To: 'Fernando Gont' Cc:
>> [email-masked] Subject: Re: [v6ops] Last Call:
>> <draft-ietf-v6ops-ra-guard- implementation-04.txt> (Implementation
>> Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best
>> Current Practice
>> 
>> I do see the importance of being apply to apply RAGuard in a
>> device which does not accumulate fragment state.  (I don't want to
>> try to analyze the potential DoS attack of having such state.)
>> 
>> However, the proposal introduces a network limtiation, essentially
>> a protocol change, in the network.  I did not think v6Ops was free
>> to recommend behaviors (dropping unclassifiable fragments) which
>> basically violate the base IPv6 spec.
>> 
>> creating long-lived restrictions as a remediation until such a
>> solution can be adopted.
>> 
>> Yours, Joel _______________________________________________ v6ops
>> mailing list [email-masked] 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>