hahn@tolerant.com (John Hahn) (03/03/90)
I am in the midst of implementing an IP-X25 solution for my company's Unix based OS. One issue which I am trying to resolve is the actions that the IP-X25 software must take on situations which involve incoming X25call requests to IP. First of all we are dealing with non-ddn PDN world so that ip-x25 addresses are mapped from some configuration table. So all incoming call requests require a calling address which need to be mapped to an ip_address so that this particular VC will be bound to an ip_address. BUT what can you do if there is no calling address present?? This is not a required field in X25 spec and many do not bother using it. Obviously one can simply require it. One is tempted to look at the ip datagrams which will be coming through the VC and extract the src ip_addr and attempt to use it. This src ip addr ,however, may NOT be the ip addr of the remote IP-X25 host. But even this seem a lot what better than just refusing the connection. If any one can share some of their experience in this matter it would be greatly appreciated. Thanks in advance. john.
art@OPAL.ACC.COM (Art Berggreen) (03/05/90)
>I am in the midst of implementing an IP-X25 solution for my company's Unix >based OS. One issue which I am trying to resolve is the actions that >the IP-X25 software must take on situations which involve incoming X25call >requests to IP. Having been around IP-over-X.25 interfacing for several years, I'll throw in my $0.02. >First of all we are dealing with non-ddn PDN world so that ip-x25 addresses are >mapped from some configuration table. So all incoming call requests require >a calling address which need to be mapped to an ip_address so that this >particular VC will be bound to an ip_address. BUT what can you do if there >is no calling address present?? This is not a required field in X25 spec >and many do not bother using it. Obviously one can simply require it. One >is tempted to look at the ip datagrams which will be coming through the VC >and extract the src ip_addr and attempt to use it. This src ip addr ,however, >may NOT be the ip addr of the remote IP-X25 host. But even this seem a lot >what better than just refusing the connection. One other possiblity is to accept the call without an IP address bound to it. This allows incoming traffic to arrive over the circuit but requires a new outbound circuit to potentially be opened to the same endpoint. In general I'd be against looking into the IP header for determining the address binding, be one can determine if the source address corresponds to the previous hop by comparing the network part with your own address(es) for the receiving interface. Our most recent implementation of IP-over-X.25 for PDNs require that both the called and calling address be present and map to a known IP address. Also, be aware that on some PDNs the CALLED X.25 address can be received in two formats, one for local calls and one for "international" calls. >If any one can share some of their experience in this matter it would be >greatly appreciated. Thanks in advance. > >john. Make sure you support negotiating as large a packet size and packet window as possible. Major performance impacts in this area. You should also be careful about providing some configurability for the circuit inactivity timers. And if you get into managing multiple SVCs to the same endpoint, there are some non-obvious problems both for X.25 and for upper layers. Finally, you might want to look into what the IETF group on PDN Cluster routing is doing (especially X.25 addresses servers). Art Berggreen ACC