Re: DHCP support for a dialed up subnet configuration ?

[[e-mail]]

Krishnan,

I am sorry to be so late, but I have been heads down in engineering mode 
with DHCPv6 and our IPv6 stack.  I think this will be a growing problem
as the Internet grows and we can use DHCPv4 with little changes.  I
propose 3 resolution scenarios below.

>Problem Description
>There are two scenarios in which we need support in DHCP to reduce
>administrative cost & complexity of remote networks connecting to a DHCP
>cloud. An easily implementable or extensible solution is preferred.

>A. Subsidiary subnet scenario:
>Imagine a Acme Corp with a DHCP network (of say - 50,000 nodes) spread
>around 60 countries. A new subsidiary of Acme Corp has opened in
>anytown, they have 10 nodes on a local subnet. They want to use
>dial-on-demand box to connect one of their machine (& hence their
>subsidiaries network) to Corporate for the duration of the connection. 

>B. Home subnet scenario:
>Acme's employees have home networks and want to have a capability to
>connect up their home network to Corp, when they decide to work from
>home. The employee can continue working, while their siblings are able
>to use the connection to browse the Internet (thru the company) & get
>information necessary to complete their term paper.

>In the above scenarios the problem must be resolved without having to
>implement a complete DHCP server at each network point of attachment
>where dial in methods are used.  The issues are security and avoidance
>of replicated DHCP servers if possible.

I will respond without the use of replicated DHCPv4 servers.

Resolution #1:

In Scenario A or B, the remote node dials into a node that is on the
same subnet as a DHCP server.  When connected, proxy arp is used become 
an actual client on the node on the subnet.  THen the remote-node-client
does a DISCOVER for multiple addresses from that server or a server on
the network somewhere.  The addresses requested are provided back to the
remote-node-client.  Once they are provided to the ACME or Home dialed
in node they have a config program that configures their office or home
with the new addresses.  If necessary the Netsetup script is rerun to
make sure all (or some of) the nodes come up with global IP addresses.

Additives to Resolution #1:

  1.  Security is maintained via the dial in and access to the node
      on the subnet.  Security is supported at the dial in point. Then
      as a client during proxy arp the same security can be used that
      is used by anyother client on a subnet.

  2.  An optimization is that when the node dials in it receives as
      part of its dial in data the address of a specific server that
      handles the issues of ACME and Home network users.  This way
      once its a proxy arp client it can deal directly with a DHCP
      server through a new option in DHCP for these type of address 
      requests.

  3.  DHCP does not presently have a means of supporting sending
      back multiple addresses for a client interface, but this is
      something that is being requested now for dynamic renumbering
      support in the PIER WG, in the IETF ranks.  Most IPv4
      implementations today now support multiple addresses per 
      interface, so this should not be an issue.  But, I think it 
      will mean new code for both the client and server for DHCP.

  4.  The config program to distribute the addresses back to other
      nodes at ACME or the Home network (for the children who play
      on the Internet with their own PCs) could be a simple UDP address
      forward to the other nodes on the network based on the nodes
      arp table (or radix table if BSD 4.4) using each link layer 
      address on the remote network to attach a corresponding
      IP address.  

  5.  THe dial in node from scenario A or B will have to have two
      interfaces.  One to connect to the home network and one to
      communicate with other nodes on the network.  But if its only
      one node then all that is needed is one address and one 
      interface.

Resolution #2:

Each dial in point of attachment has a set of addresses that it can 
assign to remote nodes in blocks or one at a time.  The user just logs
in and runs a script with the proper security permissions and the dial
in front end sends the remote node a set of addresses back.

Addititives Resolution #2:

   1.  This scenario does not take advantage of the existing DHCP
       environment.

   2.  A system network admin needs to make sure it has a block 
       of addresses that will not be used by any DHCP server. As
       this is not standardized by DHCP anyway, that can be done.

   3.  Once the addresses are received by the remote node the Steps
       in Resolution #1 are used to config the other remote nodes
       on the ACME or Home subnet, and the remote node itself.

Resolution #3:

Simply make the remote node a relay agent over PPP to the Corporate
Network and broadcast a DISCOVER for the remote subnet into the DHCP
environment and each node on the ACME or HOME subnet become direct
clients to the remote DHCP servers located by the remote node relay
agent.  

Additives Resolution #3:

   1.  Security in this situation will be absolutely critical and
       I think would have to be encryption.  So if your remote nodes
       are under he auspices of another Government country unless you
       trust 40bit keys this will be very tough to do.

   2.  The remote node dialing in as a relay will have to support
       two interfaces so it can be a client and relay.  Even if
       its the only node then an internal socket descriptor (node
       internal) will have to be used so it can be a client and
       relay agent in DHCP.  

Summary:

I think all three have there advantages and disadvantages and making
that list would be a good exercise.  As a note this will work more
efficiently with DHCPv6 because many of the inherent needs to make this
work are inhernt in the IPv6 architecture and not in the IPv4
architecture.

/jim