IPPNP

[Bruce M. Simpson]

Ozgur Ozdemircili wrote:
> Hello,
>
> I have a network of 10.10.10.0 and the gw is at 10.10.10.1. GW is
> giving out ip with DHCP. If the client pc is configured with DHCP they
> can get the ip from the server and go out to internet easily. But if
> the client has* static Ip configured*, for example 192.168.0.2 with gw
> 192.168.0.1, they cannot find the GW and cannot go out. I need the
> clients to be able to find the gw and *go out to internet without
> changing their ip configurations.
> *
> I have searched for technology behind this and it seems like IPPNP is
> the solution. This technology is implemented in most of the hotspot
> gateways (nomadix, dlink etc)
>   

This sounds like another buzzword that the vendors just made up when 
everyone with a clue wasn't looking. Someone's created a Sourceforge 
project for it which is still empty, and search engine matches find many 
vendors describing this feature as 'unique'. The way it has been 
verbally beaten on Linux related lists is something I can't disagree 
with. :^)
    http://article.gmane.org/gmane.linux.network.bridge.ebtables.user/896

The short answer is that this appears to be some kind of MAC based 
gateway protocol; basically, an 'internet access device' (stub router 
for home/small office) will forward any traffic it sees for a subnet 
which it isn't configured with, by spoofing ARP traffic so as to make it 
appear as though it is on that subnet.

This sounds like a configuration nightmare to implement correctly, and 
goodness help you if you have more than one of these things connected to 
the same network. Whilst it probably can be done in the network stack, I 
speculate it couldn't be turned on at the same time as a number of other 
features such as Proxy ARP, or CARP, and may have problems scaling to 
more than a two-armed router (that is, 1 WAN uplink, and 1 Ethernet 
interface running this stuff). It also seems to rely on a few  
assumptions (subnet is a /24, and 0 is the subnetwork address). I think 
it also assumes that the network is 802.1x or MAC address ACL 
authenticated, and that clients are directly attached to the Layer 2 
domain to which the interface which runs the quirk is attached.

I see no IETF standard for this quirk, and it doesn't seem to have been 
as well thought out as the Zeroconf proposals.

So whilst it may seem like a quick fix, it would have to be implemented, 
and the easiest thing for FreeBSD users to do in this situation is 
probably just to configure a separate network alias on their internal 
LAN interface -- something which is obviously more difficult to do with 
the kind of device the quirk is intended for.

Now that I think on it, if IPv4 addresses are scoped, it might be 
possible to implement a knob which says "All IPv4 addresses learned on 
*this* interface have local scope", which in turn implies a 1:M NAT. It 
relies of course on the NAT module e.g. pf being able to join the dots 
and notice that an IP address outside of a configured subnet is being 
used on that interface, however, it would stop the forwarding code doing 
the wrong thing and forwarding the datagram back out the WAN interface 
again after pf has demuxed the inbound datagram there.

To implement this feature properly requires that the forwarding code is 
changed to allow it. The changes required are similar to those needed 
for doing unnumbered IP. An interim solution could probably be 
implemented in userland using bpf which would stash the appropriate 
firewall rules to rewrite the outgoing traffic i.e. make the FreeBSD 
router appear on the subnet which the client thinks it's on.

Regards,
BMS