Should registered space or reserved space be used?

Steve Dispensa dispensa at positivenetworks.net
Fri Feb 15 00:39:54 EST 2002


[If this is not an appropriate forum for this question, I would
appreciate being pointed in the right direction.]

I am working on a VPN service provider network whose purpose is to
connect remote users over L2TP to remote networks.  All L2TP connections
and all remote networks are aggregated in a POP.  Traffic is switched in
the POP from L2TP tunnels into appropriate remote networks and back
again.  An added requirement is that the case of overlapping IP address
space among the remote networks must be handled properly.  

It seems particularly likely that many remote networks will choose to
use one or more of the RFC 1918 blocks.  Therefore, the probability of
address space collision is quite high.

The solution to this problem depends on the L2TP connections being given
"unique" addresses within the scope of the VPN service provider's
routing domain.  In other words:
 - no two L2TP connections can have the same address
 - no L2TP address can fall within any network block in use in any
remote network

One final point:  it is highly unlikely that the L2TP interfaces will
ever be given a direct (non-NATted) route to the Internet.

There are three options that I can see for addressing the L2TP
connections:
1) Since Internet routability is not a concern, use RFC 1918 space.
However, this violates the "no collisions" requirement.
2) Since Internet routability is not a concern and since no collisions
are allowed, use "illegal" addresses, such as addresses out of Class E
space or out of "permanently reserved" blocks (1/8 for instance).
However, this seems like a Bad Idea to me.
3) Address all requirements by using registered space.  However, given
the lack of need for Internet routability, this sure seems like a waste
of space.

I hate to do #3, but it seems like the best move.  This might be a
paltry number of addresses, or it might turn into a big drain on address
space.  Then again, I could be completely missing an obvious solution.
What do you think?

Thanks,

 -Steve




More information about the ARIN-PPML mailing list