[PATCH net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[PATCH net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[Thomas Graf]

Routing of 127/8 is tradtionally forbidden, we consider
packets from that address block martian when routing and do
not process corresponding ARP requests.

This is a sane default but renders a huge address space
practically unuseable.

The RFC states that no address within the 127/8 block should
ever appear on any network anywhere but it does not forbid
the use of such addresses outside of the loopback device in
particular. For example to address a pool of virtual guests
behind a load balancer.

This patch adds a new interface option 'route_localnet'
enabling routing of the 127/8 address block and processing
of ARP requests on a specific interface.

Note that for the feature to work, the default local route
covering 127/8 dev lo needs to be removed.

Example:
  $ sysctl -w net.ipv4.conf.eth0.route_localnet=1
  $ ip route del 127.0.0.0/8 dev lo table local
  $ ip addr add 127.1.0.1/16 dev eth0
  $ ip route flush cache

Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
 Documentation/networking/ip-sysctl.txt |    5 +++++
 include/linux/inetdevice.h             |    2 ++
 net/ipv4/arp.c                         |    3 ++-
 net/ipv4/devinet.c                     |    5 ++++-
 net/ipv4/route.c                       |   30 +++++++++++++++++++++---------
 5 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 6f896b9..99d0e05 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -862,6 +862,11 @@ accept_local - BOOLEAN
 	local interfaces over the wire and have them accepted properly.
 	default FALSE
 
+route_localnet - BOOLEAN
+	Do not consider loopback addresses as martian source or destination
+	while routing. This enables the use of 127/8 for local routing purposes.
+	default FALSE
+
 rp_filter - INTEGER
 	0 - No source validation.
 	1 - Strict mode as defined in RFC3704 Strict Reverse Path
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 597f4a9..67f9dda 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -38,6 +38,7 @@ enum
 	IPV4_DEVCONF_ACCEPT_LOCAL,
 	IPV4_DEVCONF_SRC_VMARK,
 	IPV4_DEVCONF_PROXY_ARP_PVLAN,
+	IPV4_DEVCONF_ROUTE_LOCALNET,
 	__IPV4_DEVCONF_MAX
 };
 
@@ -131,6 +132,7 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
 #define IN_DEV_PROMOTE_SECONDARIES(in_dev) \
 					IN_DEV_ORCONF((in_dev), \
 						      PROMOTE_SECONDARIES)
+#define IN_DEV_ROUTE_LOCALNET(in_dev)	IN_DEV_ORCONF(in_dev, ROUTE_LOCALNET)
 
 #define IN_DEV_RX_REDIRECTS(in_dev) \
 	((IN_DEV_FORWARD(in_dev) && \
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index cda37be..2e560f0 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -790,7 +790,8 @@ static int arp_process(struct sk_buff *skb)
  *	Check for bad requests for 127.x.x.x and requests for multicast
  *	addresses.  If this is one such, delete it.
  */
-	if (ipv4_is_loopback(tip) || ipv4_is_multicast(tip))
+	if (ipv4_is_multicast(tip) ||
+	    (!IN_DEV_ROUTE_LOCALNET(in_dev) && ipv4_is_loopback(tip)))
 		goto out;
 
 /*
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 10e15a1..378c28b 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1500,7 +1500,8 @@ static int devinet_conf_proc(ctl_table *ctl, int write,
 
 		if (cnf == net->ipv4.devconf_dflt)
 			devinet_copy_dflt_conf(net, i);
-		if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1)
+		if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1 ||
+		    i == IPV4_DEVCONF_ROUTE_LOCALNET)
 			if ((new_value == 0) && (old_value != 0))
 				rt_cache_flush(net, 0);
 	}
@@ -1617,6 +1618,8 @@ static struct devinet_sysctl_table {
 					      "force_igmp_version"),
 		DEVINET_SYSCTL_FLUSHING_ENTRY(PROMOTE_SECONDARIES,
 					      "promote_secondaries"),
+		DEVINET_SYSCTL_FLUSHING_ENTRY(ROUTE_LOCALNET,
+					      "route_localnet"),
 	},
 };
 
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 98b30d0..7509acc 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2023,9 +2023,13 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 		return -EINVAL;
 
 	if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
-	    ipv4_is_loopback(saddr) || skb->protocol != htons(ETH_P_IP))
+	    skb->protocol != htons(ETH_P_IP))
 		goto e_inval;
 
+	if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev)))
+		if (ipv4_is_loopback(saddr))
+			goto e_inval;
+
 	if (ipv4_is_zeronet(saddr)) {
 		if (!ipv4_is_local_multicast(daddr))
 			goto e_inval;
@@ -2266,8 +2270,7 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	   by fib_lookup.
 	 */
 
-	if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
-	    ipv4_is_loopback(saddr))
+	if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr))
 		goto martian_source;
 
 	if (ipv4_is_lbcast(daddr) || (saddr == 0 && daddr == 0))
@@ -2279,9 +2282,17 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	if (ipv4_is_zeronet(saddr))
 		goto martian_source;
 
-	if (ipv4_is_zeronet(daddr) || ipv4_is_loopback(daddr))
+	if (ipv4_is_zeronet(daddr))
 		goto martian_destination;
 
+	if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
+		if (ipv4_is_loopback(daddr))
+			goto martian_destination;
+
+		if (ipv4_is_loopback(saddr))
+			goto martian_source;
+	}
+
 	/*
 	 *	Now we are ready to route packet.
 	 */
@@ -2520,9 +2531,14 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
 	u16 type = res->type;
 	struct rtable *rth;
 
-	if (ipv4_is_loopback(fl4->saddr) && !(dev_out->flags & IFF_LOOPBACK))
+	in_dev = __in_dev_get_rcu(dev_out);
+	if (!in_dev)
 		return ERR_PTR(-EINVAL);
 
+	if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev)))
+		if (ipv4_is_loopback(fl4->saddr) && !(dev_out->flags & IFF_LOOPBACK))
+			return ERR_PTR(-EINVAL);
+
 	if (ipv4_is_lbcast(fl4->daddr))
 		type = RTN_BROADCAST;
 	else if (ipv4_is_multicast(fl4->daddr))
@@ -2533,10 +2549,6 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
 	if (dev_out->flags & IFF_LOOPBACK)
 		flags |= RTCF_LOCAL;
 
-	in_dev = __in_dev_get_rcu(dev_out);
-	if (!in_dev)
-		return ERR_PTR(-EINVAL);
-
 	if (type == RTN_BROADCAST) {
 		flags |= RTCF_BROADCAST | RTCF_LOCAL;
 		fi = NULL;

Re: [PATCH net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[David Miller]

What's the different between this patch and the one you posted
half a day ago?

Re: [PATCH net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[Thomas Graf]

On Fri, Jun 08, 2012 at 01:23:38PM -0700, David Miller wrote:
> 
> What's the different between this patch and the one you posted
> half a day ago?

There is no difference. I didn't see my own mail appear in
my netdev folder and assumed git send-email had failed so
I did send it again. Sorry for the double post.

Re: [PATCH net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[David Miller]

From: Thomas Graf <tgraf@suug.ch>
Date: Fri, 8 Jun 2012 06:18:59 -0400

> -		if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1)
> +		if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1 ||
> +		    i == IPV4_DEVCONF_ROUTE_LOCALNET)

Why does one value get tested using "X - 1" indexing and the
other gets tested using plain "X" indexing?

[PATCHv2 net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[Thomas Graf]

Routing of 127/8 is tradtionally forbidden, we consider
packets from that address block martian when routing and do
not process corresponding ARP requests.

This is a sane default but renders a huge address space
practically unuseable.

The RFC states that no address within the 127/8 block should
ever appear on any network anywhere but it does not forbid
the use of such addresses outside of the loopback device in
particular. For example to address a pool of virtual guests
behind a load balancer.

This patch adds a new interface option 'route_localnet'
enabling routing of the 127/8 address block and processing
of ARP requests on a specific interface.

Note that for the feature to work, the default local route
covering 127/8 dev lo needs to be removed.

Example:
  $ sysctl -w net.ipv4.conf.eth0.route_localnet=1
  $ ip route del 127.0.0.0/8 dev lo table local
  $ ip addr add 127.1.0.1/16 dev eth0
  $ ip route flush cache

V2: Fix invalid check to auto flush cache (thanks davem)

Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
 Documentation/networking/ip-sysctl.txt |    5 +++++
 include/linux/inetdevice.h             |    2 ++
 net/ipv4/arp.c                         |    3 ++-
 net/ipv4/devinet.c                     |    5 ++++-
 net/ipv4/route.c                       |   30 +++++++++++++++++++++---------
 5 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 6f896b9..99d0e05 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -862,6 +862,11 @@ accept_local - BOOLEAN
 	local interfaces over the wire and have them accepted properly.
 	default FALSE
 
+route_localnet - BOOLEAN
+	Do not consider loopback addresses as martian source or destination
+	while routing. This enables the use of 127/8 for local routing purposes.
+	default FALSE
+
 rp_filter - INTEGER
 	0 - No source validation.
 	1 - Strict mode as defined in RFC3704 Strict Reverse Path
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 597f4a9..67f9dda 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -38,6 +38,7 @@ enum
 	IPV4_DEVCONF_ACCEPT_LOCAL,
 	IPV4_DEVCONF_SRC_VMARK,
 	IPV4_DEVCONF_PROXY_ARP_PVLAN,
+	IPV4_DEVCONF_ROUTE_LOCALNET,
 	__IPV4_DEVCONF_MAX
 };
 
@@ -131,6 +132,7 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
 #define IN_DEV_PROMOTE_SECONDARIES(in_dev) \
 					IN_DEV_ORCONF((in_dev), \
 						      PROMOTE_SECONDARIES)
+#define IN_DEV_ROUTE_LOCALNET(in_dev)	IN_DEV_ORCONF(in_dev, ROUTE_LOCALNET)
 
 #define IN_DEV_RX_REDIRECTS(in_dev) \
 	((IN_DEV_FORWARD(in_dev) && \
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index cda37be..2e560f0 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -790,7 +790,8 @@ static int arp_process(struct sk_buff *skb)
  *	Check for bad requests for 127.x.x.x and requests for multicast
  *	addresses.  If this is one such, delete it.
  */
-	if (ipv4_is_loopback(tip) || ipv4_is_multicast(tip))
+	if (ipv4_is_multicast(tip) ||
+	    (!IN_DEV_ROUTE_LOCALNET(in_dev) && ipv4_is_loopback(tip)))
 		goto out;
 
 /*
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 10e15a1..44bf82e 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1500,7 +1500,8 @@ static int devinet_conf_proc(ctl_table *ctl, int write,
 
 		if (cnf == net->ipv4.devconf_dflt)
 			devinet_copy_dflt_conf(net, i);
-		if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1)
+		if (i == IPV4_DEVCONF_ACCEPT_LOCAL - 1 ||
+		    i == IPV4_DEVCONF_ROUTE_LOCALNET - 1)
 			if ((new_value == 0) && (old_value != 0))
 				rt_cache_flush(net, 0);
 	}
@@ -1617,6 +1618,8 @@ static struct devinet_sysctl_table {
 					      "force_igmp_version"),
 		DEVINET_SYSCTL_FLUSHING_ENTRY(PROMOTE_SECONDARIES,
 					      "promote_secondaries"),
+		DEVINET_SYSCTL_FLUSHING_ENTRY(ROUTE_LOCALNET,
+					      "route_localnet"),
 	},
 };
 
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 842510d..655506a 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1960,9 +1960,13 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 		return -EINVAL;
 
 	if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
-	    ipv4_is_loopback(saddr) || skb->protocol != htons(ETH_P_IP))
+	    skb->protocol != htons(ETH_P_IP))
 		goto e_inval;
 
+	if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev)))
+		if (ipv4_is_loopback(saddr))
+			goto e_inval;
+
 	if (ipv4_is_zeronet(saddr)) {
 		if (!ipv4_is_local_multicast(daddr))
 			goto e_inval;
@@ -2203,8 +2207,7 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	   by fib_lookup.
 	 */
 
-	if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
-	    ipv4_is_loopback(saddr))
+	if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr))
 		goto martian_source;
 
 	if (ipv4_is_lbcast(daddr) || (saddr == 0 && daddr == 0))
@@ -2216,9 +2219,17 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 	if (ipv4_is_zeronet(saddr))
 		goto martian_source;
 
-	if (ipv4_is_zeronet(daddr) || ipv4_is_loopback(daddr))
+	if (ipv4_is_zeronet(daddr))
 		goto martian_destination;
 
+	if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
+		if (ipv4_is_loopback(daddr))
+			goto martian_destination;
+
+		if (ipv4_is_loopback(saddr))
+			goto martian_source;
+	}
+
 	/*
 	 *	Now we are ready to route packet.
 	 */
@@ -2457,9 +2468,14 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
 	u16 type = res->type;
 	struct rtable *rth;
 
-	if (ipv4_is_loopback(fl4->saddr) && !(dev_out->flags & IFF_LOOPBACK))
+	in_dev = __in_dev_get_rcu(dev_out);
+	if (!in_dev)
 		return ERR_PTR(-EINVAL);
 
+	if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev)))
+		if (ipv4_is_loopback(fl4->saddr) && !(dev_out->flags & IFF_LOOPBACK))
+			return ERR_PTR(-EINVAL);
+
 	if (ipv4_is_lbcast(fl4->daddr))
 		type = RTN_BROADCAST;
 	else if (ipv4_is_multicast(fl4->daddr))
@@ -2470,10 +2486,6 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
 	if (dev_out->flags & IFF_LOOPBACK)
 		flags |= RTCF_LOCAL;
 
-	in_dev = __in_dev_get_rcu(dev_out);
-	if (!in_dev)
-		return ERR_PTR(-EINVAL);
-
 	if (type == RTN_BROADCAST) {
 		flags |= RTCF_BROADCAST | RTCF_LOCAL;
 		fi = NULL;

Re: [PATCHv2 net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[Neil Horman]

On Tue, Jun 12, 2012 at 06:44:01AM -0400, Thomas Graf wrote:
> Routing of 127/8 is tradtionally forbidden, we consider
> packets from that address block martian when routing and do
> not process corresponding ARP requests.
> 
> This is a sane default but renders a huge address space
> practically unuseable.
> 
> The RFC states that no address within the 127/8 block should
> ever appear on any network anywhere but it does not forbid
> the use of such addresses outside of the loopback device in
> particular. For example to address a pool of virtual guests
> behind a load balancer.
> 
> This patch adds a new interface option 'route_localnet'
> enabling routing of the 127/8 address block and processing
> of ARP requests on a specific interface.
> 
> Note that for the feature to work, the default local route
> covering 127/8 dev lo needs to be removed.
> 
> Example:
>   $ sysctl -w net.ipv4.conf.eth0.route_localnet=1
>   $ ip route del 127.0.0.0/8 dev lo table local
>   $ ip addr add 127.1.0.1/16 dev eth0
>   $ ip route flush cache
> 
> V2: Fix invalid check to auto flush cache (thanks davem)
> 
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Just out of curiosity, would it be more efficient to implement this by
optionally adding a prohibit route to the local table for 127.0.0.0/8 to every
interface that was brought up, based on weather or not that interfaces
route_localnet bool was true or not?  It would save the additional checks in the
routing path I think.  Not sure how much a savings that is, but I thought I
would ask.

Regards
Neil

Re: [PATCHv2 net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[Thomas Graf]

On Tue, Jun 12, 2012 at 07:14:44AM -0400, Neil Horman wrote:
> Just out of curiosity, would it be more efficient to implement this by
> optionally adding a prohibit route to the local table for 127.0.0.0/8 to every
> interface that was brought up, based on weather or not that interfaces
> route_localnet bool was true or not?  It would save the additional checks in the
> routing path I think.  Not sure how much a savings that is, but I thought I
> would ask.

It's not that simple because we also use the local table for source
address selection and local address verification. So we would have to
exclude/include such routes conditionally based on some route lookup
purpose indicator. Such a prohibit route would have to be valid only
in the output context.

Re: [PATCHv2 net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[Neil Horman]

On Tue, Jun 12, 2012 at 07:31:15AM -0400, Thomas Graf wrote:
> On Tue, Jun 12, 2012 at 07:14:44AM -0400, Neil Horman wrote:
> > Just out of curiosity, would it be more efficient to implement this by
> > optionally adding a prohibit route to the local table for 127.0.0.0/8 to every
> > interface that was brought up, based on weather or not that interfaces
> > route_localnet bool was true or not?  It would save the additional checks in the
> > routing path I think.  Not sure how much a savings that is, but I thought I
> > would ask.
> 
> It's not that simple because we also use the local table for source
> address selection and local address verification. So we would have to
> exclude/include such routes conditionally based on some route lookup
> purpose indicator. Such a prohibit route would have to be valid only
> in the output context.

ah, understood, so that doesn't really save us anything, it just moves the point
at which we do the check.

Acked-by: Neil Horman <nhorman@tuxdriver.com>

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCHv2 net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[Rick Jones]

On 06/12/2012 03:44 AM, Thomas Graf wrote:
> Routing of 127/8 is tradtionally forbidden, we consider
> packets from that address block martian when routing and do
> not process corresponding ARP requests.

I'd go beyond "traditionally forbidden" and call it something considered 
fundamental.  That 127.0.0.1 (et al) can only be reached by entities on 
the same system is rather deeply ingrained in the collective 
consciousness after 30-odd years.

> This is a sane default but renders a huge address space practically
> unuseable.

This change would make 127/8 a de facto RFC 1918 address right?  It 
would not be publicly routable.  Are there actually entities who have 
exhausted 10/8, 172.16/12 and 192.168/16?

Are there any other stacks which can do this, or would this be an "RFC 
1918" network between (newer)Linux systems only?  (Assuming 
non-newer-linux-based routers would be happy with it)

I cannot say that I'm all that good about practicing the preaching, but 
IPv6 cannot be held-off indefinitely.

rick jones

Re: [PATCHv2 net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[Thomas Graf]

On Tue, Jun 12, 2012 at 11:13:12AM -0700, Rick Jones wrote:
> I'd go beyond "traditionally forbidden" and call it something
> considered fundamental.  That 127.0.0.1 (et al) can only be reached
> by entities on the same system is rather deeply ingrained in the
> collective consciousness after 30-odd years.

I absolutely agree with regard to 127.0.0.1 but I do not fully
agree with regard to 127/8 in general.

> This change would make 127/8 a de facto RFC 1918 address right?  It
> would not be publicly routable.  Are there actually entities who
> have exhausted 10/8, 172.16/12 and 192.168/16?

This is not about enabling 127/8 to become publicly routeable.
This is about enabling 127/8 for host internal routing, f.e.
virtual bridges, ifb devices, or dummy devices.

The problem with 10/8, 172.162/12 and 192.168/16 is that these
ranges are often in use by VPNs and thus unavailable. None of these
addresses are guaranteed to be available on a random system.

An example for such usage would be virtualization where you want
to assign addresses to guests which are guaranteed to be available
in host scope as well.

Yes, if someone enables this on a publicly facing interface that
will enable the possibility to violate the RFC but he might as well
do that by using a raw socket.

> Are there any other stacks which can do this, or would this be an
> "RFC 1918" network between (newer)Linux systems only?  (Assuming
> non-newer-linux-based routers would be happy with it)

AFAIK none but I could be wrong. Again, this option is not intended
to be used on any public interfaces. However, if you want to enable
this in your own private network, fine with me again.

Re: [PATCHv2 net-next] ipv4: Add interface option to enable routing of 127.0.0.0/8

[David Miller]

From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 12 Jun 2012 08:32:38 -0400

> On Tue, Jun 12, 2012 at 07:31:15AM -0400, Thomas Graf wrote:
>> On Tue, Jun 12, 2012 at 07:14:44AM -0400, Neil Horman wrote:
>> > Just out of curiosity, would it be more efficient to implement this by
>> > optionally adding a prohibit route to the local table for 127.0.0.0/8 to every
>> > interface that was brought up, based on weather or not that interfaces
>> > route_localnet bool was true or not?  It would save the additional checks in the
>> > routing path I think.  Not sure how much a savings that is, but I thought I
>> > would ask.
>> 
>> It's not that simple because we also use the local table for source
>> address selection and local address verification. So we would have to
>> exclude/include such routes conditionally based on some route lookup
>> purpose indicator. Such a prohibit route would have to be valid only
>> in the output context.
> 
> ah, understood, so that doesn't really save us anything, it just moves the point
> at which we do the check.
> 
> Acked-by: Neil Horman <nhorman@tuxdriver.com>

Applied, thanks guys.