Re: A patch for allowing IPv6-only or IPv4-only bridges
Landry Breuil writes: > On Mon, Jul 18, 2016 at 11:27:56AM +0200, Quentin Rameau wrote: >> Hi Martin, >> >> > As discussed with landry@ and sthen@ this won't be merged. Your problem >> > could also be solved by using a NDP proxy, that's a solution we would >> > recommend if your ISP cannot fix his setup. >> >> Thanks for the answer! >> Too bad, although that may not be the most elegant solution and kind of >> a hack, that's really more handy than seting up an NPD proxy for each >> potential host behind the router. > > I think the NDP proxy is supposed to be *on* the router itself. > >> But yeah, that's just an excuse for my broken ISP... >> I'll keep that patch on my local source tree until I've found a better >> solution. > > I'm doing the same, since that's a solution that works for now, until > someone makes a port / tries to make an NDP proxy for OpenBSD. > https://github.com/DanielAdolfsson/ndppd was a candidate, but i didnt > manage yet to trick someone to look into that. I've looked into it, it contains some Linux-specific bits. I'm not saying that it's undoable, as I didn't try too hard. However I've started writing an ND proxy that would work out of the box on OpenBSD, something basic that covers simple use cases. It is far too early to tell whether it would go in base or ports. I'll let people know how it goes. -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: A patch for allowing IPv6-only or IPv4-only bridges
On Mon, Jul 18, 2016 at 11:27:56AM +0200, Quentin Rameau wrote: > Hi Martin, > > > As discussed with landry@ and sthen@ this won't be merged. Your problem > > could also be solved by using a NDP proxy, that's a solution we would > > recommend if your ISP cannot fix his setup. > > Thanks for the answer! > Too bad, although that may not be the most elegant solution and kind of > a hack, that's really more handy than seting up an NPD proxy for each > potential host behind the router. I think the NDP proxy is supposed to be *on* the router itself. > But yeah, that's just an excuse for my broken ISP... > I'll keep that patch on my local source tree until I've found a better > solution. I'm doing the same, since that's a solution that works for now, until someone makes a port / tries to make an NDP proxy for OpenBSD. https://github.com/DanielAdolfsson/ndppd was a candidate, but i didnt manage yet to trick someone to look into that. Landry
Re: A patch for allowing IPv6-only or IPv4-only bridges
On 13/07/16(Wed) 18:28, Quentin Rameau wrote: > > Hello there, > Hi, > > > Here is my patch that adds support for creating IPv6-only or > >IPv4-only bridges. This is different from simply blocking one of the > >protocols via PF - it allows you to create a setup where IPv4 is routed > >and IPv6 is bridged (or vice versa). Both of them being filtered by the > >same set of PF rules. It adds two new bridge port options to ifconfig - > >BLOCKIPV4 and BLOCKIPV6. BLOCKIPV4 also stops ARPs requests from > >"leaking" across the bridge - something I couldn't accomplish by PF alone. > > The patch breaks the binary compatibility of ifconfig - it must be > >rebuilt with the new kernel. > > I don't know if anyone will find any use for it. For sure it is > >very useful with the second-biggest FTTH/ADSL operator in France who > >offers consumer-grade IPv6 access with an indivisible /64 network that > >must be bridged for firewalling (and a single IPv4/32 address that must > >be NATted). > > Patch is against -current, any comments are welcome. > Thank you for that, I just found it and applyed a few hours ago. > This is indeed handy for that situation. > It's working fine ATM, I'll let you know if I stumble upon problems. > That'd be nice to see that merged! As discussed with landry@ and sthen@ this won't be merged. Your problem could also be solved by using a NDP proxy, that's a solution we would recommend if your ISP cannot fix his setup.
Re: A patch for allowing IPv6-only or IPv4-only bridges
On Sun, Mar 20, 2016 at 11:55:23AM +0100, Stefan Sperling wrote: > On Sun, Mar 20, 2016 at 10:43:43AM +, Stuart Henderson wrote: > > While I do see use for this, can people also apply pressure to said > > ISP to fix their setup as well please? This is basic routing and really > > shouldn't need bridge hacks. People will need better than a single > > /64 in order to segregate their IOT crap onto a network that doesn't > > have access to their computers and the longer they get away with a > > substandard setup the harder it will be for them to fix it later. > > There's no address shortage with IPv6, this is just a business > > decision the ISP have made. > > Indeed. > And bridging the internal LAN with the internet is really not a good idea. Well, what's pf for then ? :) At some point, if ppl want widespread v6, every host will be directly reachable, so will have to be filtered at some point I dont see the issue with bridging here, but i'm all open to explanations. Landry
Re: A patch for allowing IPv6-only or IPv4-only bridges
On Sun, Mar 20, 2016 at 10:43:43AM +, Stuart Henderson wrote: > While I do see use for this, can people also apply pressure to said > ISP to fix their setup as well please? This is basic routing and really > shouldn't need bridge hacks. People will need better than a single > /64 in order to segregate their IOT crap onto a network that doesn't > have access to their computers and the longer they get away with a > substandard setup the harder it will be for them to fix it later. > There's no address shortage with IPv6, this is just a business > decision the ISP have made. Indeed. And bridging the internal LAN with the internet is really not a good idea.
Re: A patch for allowing IPv6-only or IPv4-only bridges
While I do see use for this, can people also apply pressure to said ISP to fix their setup as well please? This is basic routing and really shouldn't need bridge hacks. People will need better than a single /64 in order to segregate their IOT crap onto a network that doesn't have access to their computers and the longer they get away with a substandard setup the harder it will be for them to fix it later. There's no address shortage with IPv6, this is just a business decision the ISP have made.
Re: A patch for allowing IPv6-only or IPv4-only bridges
On Wed, Mar 16, 2016 at 08:54:22PM +0100, Momtchil Momtchev wrote:
>
> Hello there,
>
> Here is my patch that adds support for creating IPv6-only or IPv4-only
> bridges. This is different from simply blocking one of the protocols via PF
> - it allows you to create a setup where IPv4 is routed and IPv6 is bridged
> (or vice versa). Both of them being filtered by the same set of PF rules. It
> adds two new bridge port options to ifconfig - BLOCKIPV4 and BLOCKIPV6.
> BLOCKIPV4 also stops ARPs requests from "leaking" across the bridge -
> something I couldn't accomplish by PF alone.
> The patch breaks the binary compatibility of ifconfig - it must be
> rebuilt with the new kernel.
> I don't know if anyone will find any use for it. For sure it is very
> useful with the second-biggest FTTH/ADSL operator in France who offers
> consumer-grade IPv6 access with an indivisible /64 network that must be
> bridged for firewalling (and a single IPv4/32 address that must be NATted).
> Patch is against -current, any comments are welcome.
Fwiw, i've tested it here on my macppc gateway with the said ISP, and it
works fine.
$cat /etc/hostname.bridge0
add axe0
add gem0
blockipv4 gem0
rtsol
up
$ifconfig bridge0
bridge0: flags=200041
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
designated: id 00:00:00:00:00:00 priority 0
axe0 flags=3
port 5 ifpriority 0 ifcost 0
gem0 flags=103
port 2 ifpriority 0 ifcost 0
Addresses (max cache: 100, timeout: 240):
00:24:d4:b9:3c:63 axe0 1 flags=0<>
00:1e:4f:94:e1:78 gem0 1 flags=0<>
(gem0 is my LAN iface, axe0 is the ISP-side with my public v4)
On a v4-natted host on the LAN side, ifconfig em0 inet6 autoconf gets me
a pair of v6 address in the /64 netblock assigned by the ISP, and i can
ping6 outside of my gw. Of course, i can still ping outside via natted
v4 :) http://ipv6.whatismyv6.com/ gives me the correct v6 ip too.
Here's the unmangled diff without the set/unset* refactoring, manually
applied and hopefully fixed wrt style(9).
Thanks for your work on this !
Landry
Index: sbin/ifconfig/brconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/brconfig.c,v
retrieving revision 1.9
diff -u -r1.9 brconfig.c
--- sbin/ifconfig/brconfig.c18 Jul 2015 06:50:24 - 1.9
+++ sbin/ifconfig/brconfig.c20 Mar 2016 09:05:48 -
@@ -59,7 +59,7 @@
#defineIFBAFBITS "\020\1STATIC"
#defineIFBIFBITS \
-"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11SPAN"
+"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11BLOCKIPV4\12BLOCKIPV6\15SPAN"
#definePV2ID(pv, epri, eaddr) do {
\
epri = pv >> 48;\
@@ -115,6 +115,30 @@
unsetblocknonip(const char *val, int d)
{
bridge_ifclrflag(val, IFBIF_BLOCKNONIP);
+}
+
+void
+setblockipv4(const char *val, int d)
+{
+ bridge_ifsetflag(val, IFBIF_BLOCKIPV4);
+}
+
+void
+unsetblockipv4(const char *val, int d)
+{
+ bridge_ifclrflag(val, IFBIF_BLOCKIPV4);
+}
+
+void
+setblockipv6(const char *val, int d)
+{
+ bridge_ifsetflag(val, IFBIF_BLOCKIPV6);
+}
+
+void
+unsetblockipv6(const char *val, int d)
+{
+ bridge_ifclrflag(val, IFBIF_BLOCKIPV6);
}
void
Index: sbin/ifconfig/brconfig.h
===
RCS file: /cvs/src/sbin/ifconfig/brconfig.h,v
retrieving revision 1.9
diff -u -r1.9 brconfig.h
--- sbin/ifconfig/brconfig.h7 Jan 2016 15:33:56 - 1.9
+++ sbin/ifconfig/brconfig.h20 Mar 2016 09:05:48 -
@@ -25,6 +25,10 @@
void unsetdiscover(const char *, int);
void setblocknonip(const char *, int);
void unsetblocknonip(const char *, int);
+void setblockipv4(const char *, int);
+void unsetblockipv4(const char *, int);
+void setblockipv6(const char *, int);
+void unsetblockipv6(const char *, int);
void setlearn(const char *, int);
void unsetlearn(const char *, int);
void setstp(const char *, int);
Index: sbin/ifconfig/ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.266
diff -u -r1.266 ifconfig.8
--- sbin/ifconfig/ifconfig.828 Feb 2016 21:55:36 - 1.266
+++ sbin/ifconfig/ifconfig.820 Mar 2016 09:05:49 -
@@ -564,6 +564,24 @@
.It Cm -blocknonip Ar interface
Allow non-IPv4, IPv6, ARP, or Reverse ARP packets through
.Ar interface .
+.It Cm blockipv4 Ar interface
+Mark
+.Ar interface
+so that no IPv4 or ARP
+packets are accepted from it or forwarded to it from other
+bridge member interfaces. Allows the creation of IPv6-only bridges
+.It Cm -blockipv4 Ar interface
+Allow IPv4 or ARP packets through
+.Ar interface .
+.It Cm blockipv6 Ar interfa
A patch for allowing IPv6-only or IPv4-only bridges
Hello there,
Here is my patch that adds support for creating IPv6-only or
IPv4-only bridges. This is different from simply blocking one of the
protocols via PF - it allows you to create a setup where IPv4 is routed
and IPv6 is bridged (or vice versa). Both of them being filtered by the
same set of PF rules. It adds two new bridge port options to ifconfig -
BLOCKIPV4 and BLOCKIPV6. BLOCKIPV4 also stops ARPs requests from
"leaking" across the bridge - something I couldn't accomplish by PF alone.
The patch breaks the binary compatibility of ifconfig - it must be
rebuilt with the new kernel.
I don't know if anyone will find any use for it. For sure it is
very useful with the second-biggest FTTH/ADSL operator in France who
offers consumer-grade IPv6 access with an indivisible /64 network that
must be bridged for firewalling (and a single IPv4/32 address that must
be NATted).
Patch is against -current, any comments are welcome.
Index: sbin/ifconfig/brconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/brconfig.c,v
retrieving revision 1.9
diff -u -p -u -r1.9 brconfig.c
--- sbin/ifconfig/brconfig.c18 Jul 2015 06:50:24 -1.9
+++ sbin/ifconfig/brconfig.c16 Mar 2016 19:37:44 -
@@ -59,7 +59,7 @@ void bridge_showrule(struct ifbrlreq *);
#defineIFBAFBITS"\020\1STATIC"
#defineIFBIFBITS\
-"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11SPAN"
+"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11BLOCKIPV4\12BLOCKIPV6\15SPAN"
#definePV2ID(pv, epri, eaddr)do {\
epri = pv >> 48;\
@@ -93,102 +93,28 @@ char *stproles[] = {
};
-void
-setdiscover(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_DISCOVER);
-}
-
-void
-unsetdiscover(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_DISCOVER);
-}
-
-void
-setblocknonip(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BLOCKNONIP);
-}
-
-void
-unsetblocknonip(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BLOCKNONIP);
-}
-
-void
-setlearn(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_LEARNING);
-}
-
-void
-unsetlearn(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_LEARNING);
-}
-
-void
-setstp(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_STP);
-}
-
-void
-unsetstp(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_STP);
-}
-
-void
-setedge(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BSTP_EDGE);
-}
-
-void
-unsetedge(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BSTP_EDGE);
-}
-
-void
-setautoedge(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BSTP_AUTOEDGE);
-}
-
-void
-unsetautoedge(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BSTP_AUTOEDGE);
-}
-
-void
-setptp(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BSTP_PTP);
-}
-
-void
-unsetptp(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BSTP_PTP);
-}
-
-void
-setautoptp(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BSTP_AUTOPTP);
-}
-
-void
-unsetautoptp(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BSTP_AUTOPTP);
-}
-
+#define IFBIF_SETUNSET(NAME,FLAG) \
+void \
+set ## NAME (const char *val, int d) \
+{ \
+bridge_ifsetflag(val, FLAG); \
+} \
+void \
+unset ## NAME (const char *val, int d) \
+{ \
+bridge_ifclrflag(val, FLAG); \
+}
+
+IFBIF_SETUNSET(discover,IFBIF_DISCOVER)
+IFBIF_SETUNSET(blocknonip,IFBIF_BLOCKNONIP)
+IFBIF_SETUNSET(blockipv4,IFBIF_BLOCKIPV4)
+IFBIF_SETUNSET(blockipv6,IFBIF_BLOCKIPV6)
+IFBIF_SETUNSET(learn,IFBIF_LEARNING)
+IFBIF_SETUNSET(stp,IFBIF_STP)
+IFBIF_SETUNSET(edge,IFBIF_BSTP_EDGE)
+IFBIF_SETUNSET(autoedge,IFBIF_BSTP_AUTOEDGE)
+IFBIF_SETUNSET(ptp,IFBIF_BSTP_PTP)
+IFBIF_SETUNSET(autoptp,IFBIF_BSTP_AUTOPTP)
void
bridge_ifsetflag(const char *ifsname, u_int32_t flag)
Index: sbin/ifconfig/brconfig.h
===
RCS file: /cvs/src/sbin/ifconfig/brconfig.h,v
retrieving revision 1.9
diff -u -p -u -r1.9 brconfig.h
--- sbin/ifconfig/brconfig.h7 Jan 2016 15:33:56 -1.9
+++ sbin/ifconfig/brconfig.h16 Mar 2016 19:37:44 -
@@ -25,6 +25,10 @@ void setdiscover(const char *, int);
void unsetdiscover(const char *, int);
void setblocknonip(const char *, int);
void unsetblocknonip(const char *, int);
+void setblockipv4(const char *, int);
+void unsetblockipv4(const char *, int);
+void setblockipv6(const char *, int);
+void unsetblockipv6(const char *, int);
void setlearn(const char *, int);
void unsetlearn(const char *, int);
void setstp(const char *, int);
Index: sbin/ifconfig/ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.266
diff -u -p -u -r1.266 ifcon
Re: A patch for allowing IPv6-only or IPv4-only bridges
On 16/03/16(Wed) 20:54, Momtchil Momtchev wrote:
> [..]
> Here is my patch that adds support for creating IPv6-only or IPv4-only
> bridges. This is different from simply blocking one of the protocols via PF
> - it allows you to create a setup where IPv4 is routed and IPv6 is bridged
> (or vice versa). Both of them being filtered by the same set of PF rules. It
> adds two new bridge port options to ifconfig - BLOCKIPV4 and BLOCKIPV6.
> BLOCKIPV4 also stops ARPs requests from "leaking" across the bridge -
> something I couldn't accomplish by PF alone.
Interesting. It seems that some devs would have a use case for that.
However I wonder if it wouldn't make more sense to extend the rule
filtering to be able to filter on something else than the Ethernet src/dst.
Reyk, Goda what to you think? Are you also interested in blocking IPv4
and/or IPv6?
Note that Ethernet Multicast/IP Multicast are also blocked in bridge(4)
via the link0 and link1 flags. Do you think it would make sense to use
rules for that too?
> The patch breaks the binary compatibility of ifconfig - it must be
> rebuilt with the new kernel.
This is not a big deal.
> I don't know if anyone will find any use for it. For sure it is very
> useful with the second-biggest FTTH/ADSL operator in France who offers
> consumer-grade IPv6 access with an indivisible /64 network that must be
> bridged for firewalling (and a single IPv4/32 address that must be NATted).
> Patch is against -current, any comments are welcome.
Comments below, but let's see what Reyk and Goda think the right
approach is before sending a new one.
> Index: sbin/ifconfig/brconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/brconfig.c,v
> retrieving revision 1.9
> diff -u -p -u -r1.9 brconfig.c
> --- sbin/ifconfig/brconfig.c18 Jul 2015 06:50:24 -1.9
> +++ sbin/ifconfig/brconfig.c16 Mar 2016 19:37:44 -
> @@ -59,7 +59,7 @@ void bridge_showrule(struct ifbrlreq *);
>
> #defineIFBAFBITS"\020\1STATIC"
> #defineIFBIFBITS\
> -"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11SPAN"
> +"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11BLOCKIPV4\12BLOCKIPV6\15SPAN"
>
> #definePV2ID(pv, epri, eaddr)do {\
> epri = pv >> 48;\
> @@ -93,102 +93,28 @@ char *stproles[] = {
> };
>
>
> -void
> -setdiscover(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_DISCOVER);
> -}
> -
> -void
> -unsetdiscover(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_DISCOVER);
> -}
> -
> -void
> -setblocknonip(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BLOCKNONIP);
> -}
> -
> -void
> -unsetblocknonip(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BLOCKNONIP);
> -}
> -
> -void
> -setlearn(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_LEARNING);
> -}
> -
> -void
> -unsetlearn(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_LEARNING);
> -}
> -
> -void
> -setstp(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_STP);
> -}
> -
> -void
> -unsetstp(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_STP);
> -}
> -
> -void
> -setedge(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BSTP_EDGE);
> -}
> -
> -void
> -unsetedge(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BSTP_EDGE);
> -}
> -
> -void
> -setautoedge(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BSTP_AUTOEDGE);
> -}
> -
> -void
> -unsetautoedge(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BSTP_AUTOEDGE);
> -}
> -
> -void
> -setptp(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BSTP_PTP);
> -}
> -
> -void
> -unsetptp(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BSTP_PTP);
> -}
> -
> -void
> -setautoptp(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BSTP_AUTOPTP);
> -}
> -
> -void
> -unsetautoptp(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BSTP_AUTOPTP);
> -}
> -
> +#define IFBIF_SETUNSET(NAME,FLAG) \
> +void \
> +set ## NAME (const char *val, int d) \
> +{ \
> +bridge_ifsetflag(val, FLAG); \
> +} \
> +void \
> +unset ## NAME (const char *val, int d) \
> +{ \
> +bridge_ifclrflag(val, FLAG); \
> +}
Please avoid mixing a refactoring and a new feature in the same diff.
Plus this kind of abstraction are questionable and might block or delay
your diff to go in ;)
> +IFBIF_SETUNSET(discover,IFBIF_DISCOVER)
> +IFBIF_SETUNSET(blocknonip,IFBIF_BLOCKNONIP)
> +IFBIF_SETUNSET(blockipv4,IFBIF_BLOCKIPV4)
> +IFBIF_SETUNSET(blockipv6,IFBIF_BLOCKIPV6)
> +IFBIF_SETUNSET(learn,IFBIF_LEARNING)
> +IFBIF_SETUNSET(stp,IFBIF_STP)
> +IFBIF_SETUNSET(edge,IFBIF_BSTP_EDGE)
> +IFBIF_SETUNSET(autoedge,IFBIF_BSTP_AUTOEDGE)
> +IFBIF_SETUNSET(ptp,IFBIF
