[consume-routing] IP addressing idea

[Mike Brodbelt]

Adam Laurie wrote:
> 
> Mike Brodbelt wrote:
> >
> > Peter Galbavy wrote:
> >
> > <snip>
> >
> > > The problem is neither the NAT nor the routeing; it is the use of "private"
> > > addresses across enterprises with different allocation and assignment
> > > policies.
> >
> > I can even provide an example. I have an ADSL connection, and behind it,
> > I have a NAT'ed RFC 1918 netblock for my machines (192.1678.1/24). I'd
> > like to set up a consume node. If a roaming user with a laptop connects
> > to my node, the last thing I'd want is for their machine to be
> > configured to be a part of 192.168.1/24. Given the number of people
> > using NAT out there, this is bound to bite someone. Having a designated,
> > unique block of NAT'able addresses for node "subscribers" will remove
> > any potential conflict, and theoretically help consume users to roam
> > between nodes without their machines needing to change IP address
> > (although to make this work would require magic at the node end).
> 
> This is covered by my original posting. Since you allocate the
> individual IPs for machines connecting to your node yourself, from the
> range you were allocated from the node database, which you ensured did
> not conflict with the range(s) you already use, this is not an issue. If
> a conflict arises at a later date, you will be able to go back to the
> node database and relinquish your address range and get another one. A
> one line change in your DHCP server config and you are back in business.

Is there not sufficient value in maintaining a single address block for
node clients to justify the allocation of one class C netblock? Your
proposal would require each node to use a block of RFC1918 address
space, and, quite possibly, each node would choose a different block. In
terms of node setup, it would make for added simplicity to simply be
able to say "use these addresses".

Secondly, if a consume node is misconfigured such that it allows these
RFC 1918 addresses to leak onto the backbone, all kinds of grief could
conceivably ensue. If all consume nodes were configured to use the same
/24, then it would be simple to only accept these addresses when they
originated from the 802.11 side of things. As many organisations wishing
to operate consume nodes may already be using RFC 1918 addresses, and so
filtering leaked addresses that collide with an organisations own
internal address space might well be a harder job, and the source of any
problems would almost certainly be less obvious.

While your approach is certainly technically feasible, I tend to feel
that we may be making a rod for our own backs for the sake of saving a
single class C. If Peter can acquire a PI block for us, I'd say we
should jump at it.

My 2p worth,

Mike.