The automatic end system creation can be either controlled , with restricted access to the host, or open, with unrestricted access to the host.
The type of AEC operation is defined via the processor file or more precisely, via the parameter ACCESS in the operand PROCESSOR-TABLE of the commands DCOPT, DCSTART and BCMOD. The function of automatic end system creation is closely related to the processor file (see also "Assigning processor and route names").
Controlled server operation
ACCESS=READ
The access to the host is restricted.
Partner end systems can only be created if at least one of the following conditions is met:
- The partner end system is included in the processor file.
- The partner end system is included with IP/IPV6 address in the FQDN file (equivalent to an entry in the processor file).
The partner end system is included in the socket host file with a socket host name of less than 9 characters.
There is an entry in DNS for the partner end system, the use of DNS is enabled and is not prohibited for the partner end system (MODIFY-DNS-ACCESS).
The server port of the connection for your own system or the partner end system is explicitly allowed (BCOPTION ... ADD(-REMOTE) SERVER-PORTS).
The IP/IPV6 address of the partner end system is within a permitted IP range (BCOPTION ... ADD/REMOVE-IP-RANGE).
BCAM firewall
If a partner end system is not accepted, its address is entered into a BCAM internal "firewall table." Detailed information on this can be found in the section "Firewall Entries in BCAM".
Open server operation
ACCESS=UPDATE:
Access to the host is unrestricted. Each partner end system is accepted.
Partner end systems that would not have been granted access with controlled server operation (ACCESS=READ) are included in the .AUT-, .LOG and ISAM files of the processor file. In addition, partner end systems that are given a dynamically generated name by the automatic end system creation (see section "Assigning processor and route names") are included in the .AUT and .LOG file, too.
ACCESS=ALLOW:
Access to the host is unrestricted. Each partner end system is accepted, but there is no entry in the .AUT, .LOG and ISAM files of the processor file. Also, partner end systems that receive a dynamically generated name through the automatic end system creation (see section "Assigning processor and route names") will not be entered.
Note:
The partner end systems whose IPv6 Interface Identifiers are temporarily and randomly generated and not, as suggested in the IPv6 Basis RFC, derived from the MAC address lead to non-unique entries in the .AUT, .LOG and ISAM files in the case of pure ACCESS=UPDATE. Precisely this is avoided with the setting ACCESS=ALLOW.
Switching to controlled server operation
Use the BCMOD command to switch from ACCESS=UPDATE or ACCESS=ALLOW to ACCESS=READ.
When switching from ACCESS=ALLOW to ACCESS=READ, no further steps are required.
When switching from ACCESS=UPDATE to ACCESS=READ, the logging in the .AUT-, .LOG and ISAM files of the processor file can be used to identify the processors that would be rejected by ACCESS=READ and to continue to grant access if wanted. You can proceed as follows for the changeover:
> | Use the BCMOD command to switch from ACCESS=UPDATE to ACCESS=READ. | |
> | With the help of the .LOG file also include the processors which are still to have access in the original processor file. | |
> | Replace the artificial processor names by the processor names you wish to use. | |
> | In order to remove the artificial processor names in the .IS1 and .IS2 files, too, use the BCMOD command to temporarily specify a processor file which is identical to the original. | |
> | Delete the derived .IS1 and .IS2 files of the original processor file. | |
> | Delete the .AUT and .LOG files of the original processor file. | |
> | Use the BCMOD command to specify the original processor file again. | |
Details on .IS1, .IS2, .AUT and .LOG files are provided on "BCAM control files" .