Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes

[Andrew 👽 Yourtchenko <[e-mail]>]

On 9/19/14, Nalini Elkins <[e-mail]> wrote:
>
>>A directed broadcast ping on IPv4 gives pretty much the same result.
>>Did you test the effects of that ?
>
> I had not.  But, since you mentioned it, I did it on two different Windows
> machines.  The one that is the server in question had the following results:
>
> C:\Users\Administrator>ping x.x.x.255
>
> Pinging x.x.x.255 with 32 bytes of data:
> Request timed out.
> Request timed out.
> Request timed out.
> Request timed out.
>
> Ping statistics for x.x.x.255:
>     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
>
> Arp cache was not updated.   I did a packet trace in the background and
> indeed no ICMP replies were seen.
>
> I did the same ping x.x.x.255 on one of my client PCs and saw:
>
> Pinging x.x.x.255 with 32 bytes of data:
> Request timed out.
> Request timed out.
> Request timed out.
> Request timed out.
>
> But this time the packet trace showed that actually ICMP replies were sent.
>

So, besides this cosmetic difference the behavior is identical for the
case of IPv4 ping ?

>>Of course, private VLANs or (if we are talking VMs) or just using p2p
>>links with /128s would help this in the environments where the hosts
>>can not be trusted - and this of course is not virtual/physical
>>specific.
>
> Yes.  We wanted to bring up the topic of isolation of nodes for discussion.

This is a useful topic in general - especially in light of the
MLD-related thread, but the draft seems to focus on a very corner case
- there are many much better reasons not to do large L2 networks.

>
>>If we're talking specifically virtual environment, here's an approach
>>on how to use ebtables to isolate the hosts:
>
>>ebtables -P FORWARD DROP
>>ebtables -F FORWARD
>>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow
>>from uplink to any ports
>>ebtables -A FORWARD -o $uplinkPort -j ACCEPT # let the traffic flow
>>from any ports to uplink
>
>>(source:http://serverfault.com/questions/388544/is-it-possible-to-enable-port-isolation-on-linux-bridges)
>
> I think this is very good.  But, unfortunately not very well known.   Also,
> is this possible for all platforms or just Linux?

This was just my first google.com search result when searching for
"private vlans linux".

The first google.com search result on "private vlans windows" brings
up http://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-isolation.aspx
which seems to document similar technique.

"private vlan vmware" results in
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010691
as its first hit.

Would an IETF publication be easier to find than the above ?

>
>>So looks like the question at hand is:
>
>>"Should IPv6 nodes respond to Ping to FF0x::1?"
>
>>Which can be rephrased differently to ease the start of the discussion:
>
>>"What are the legitimate uses of a ping to ff0x::1 ?"
>
>>Right ?
>
> Yes.

Allright, so I'll mention my use of ping6 ff0x::1:

* quick check to find "a few hosts that are alive on this link"
(obviously not to be done on large segments).

* A way to trigger the remote side's ND process without having to do
one myself (I know the multicast packet to all-hosts *will* usually
get received regardless of the underlying issues with the L2.5
infrastructure (snooping, etc.)

* A way to further debug malfunctioning L2.5 infra, by comparing the
reaction to pings to ff02::1, solicited node multicast, other
multicast groups, etc.

Summary: the ff02::1 current ping behavior does help in a non-trivial
amount of cases.

The security aspects the draft mentions indeed do exist, but in a
properly configured network can be easily mitigated as I've shown
above. So I'd be against changing the functionality in the existing
stacks.

On the education side: the existing search results
https://www.google.com/?gws_rd=ssl#q=ping6+ff02::1 show
8000-something results - so indeed probably this behavior may be
highlighted more during the IPv6 education. However: every IPv6 course
I've heard says "there is no broadcast in IPv6, but there is all-hosts
multicast" which should not make the behavior the draft describes a
major surprise.

--a

>
> --a
>
>
> On 9/19/14, [e-mail] <[e-mail]> wrote:
>> A new draft has been posted, at
>> http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes.
>> Please take a look at it and comment.
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>