netdev - Re: [patch v7, kernel version 3.2.1] net/ipv4/ip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Feb 2012 00:33:49 +0100
From:	Štefan Gula <steweg@...t.sk>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	"David S. Miller" <davem@...emloft.net>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org
Subject: Re: [patch v7, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet
 multipoint GRE over IP

2012/1/31 Stephen Hemminger <shemminger@...tta.com>:
> On Tue, 31 Jan 2012 14:21:51 +0100 (CET)
> Stefan Gula <steweg@...t.sk> wrote:
>
>> From: Stefan Gula <steweg@...il.com>
>>
>> This patch is an extension for current Ethernet over GRE
>> implementation, which allows user to create virtual bridge (multipoint
>> VPN) and forward traffic based on Ethernet MAC address information in
>> it. It simulates the Bridge behavior learning mechanism, but instead
>> of learning port ID from which given MAC address comes, it learns IP
>> address of peer which encapsulated given packet. Multicast, Broadcast
>> and unknown-multicast traffic is send over network as multicast
>> encapsulated GRE packet, so one Ethernet multipoint GRE tunnel can be
>> represented as one single virtual switch on logical level and be also
>> represented as one multicast IPv4 address on network level.
>>
>> Signed-off-by: Stefan Gula <steweg@...il.com>
>
> Have you looked at the NVGRE standard?
>  http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-00
Yes, I did.
One section from 3.1. NVGRE Endpoint:
To encapsulate an
   Ethernet frame, the endpoint needs to know location information for
   the destination address in the frame. The way to obtain this
   information is not covered in this document and will be covered in a
   different draft. Any number of techniques can be used in the control
   plane to configure, discover and distribute the policy information.
   For the rest of this document we assume that the location
   information including TNI is readily available to the NVGRE
   endpoint.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html