Detailed Design Specification
© 2006 Ingres Corporation
Project Name
IPv6 Networking Support
Author Bruce Lunsford
Last Saved Date
March 9, 2016
Revision 1.4
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Responsibility List
Assigned To
Bruce Lunsford
Teresa King, Bill
Maimone, Steve
Ball
Chris Rogers
David Reed
Pam Fowler,
Nick Makos
Dave Dargo
Elaine Greico
Deb Woods
Tony DeCicco
Action
Owner
Peer Review
Responsibility
Engineer/Architect
Development Manager
Peer Review
Peer Review
Peer Review
QA Manager
Level 2 Support Manager
Level 1 Support Manager
Peer Review
Peer Review
Peer Review
Peer Review
Office of the CTO
Tech Writer
Product Manager
Services
Note: The Responsibility List reflects those required to review and provide feedback
for the document. .
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 2 of 42
Change History:
Revision Date
Last Revision By
Description of Change
May 13, 2006
Bruce Lunsford
Initial version
Aug 16, 2006
Bruce Lunsford
1.1 – 1st real full draft
Aug 16, 2006
Bruce Lunsford
1.2 – (1) Section 2.1.1.4: Updated JDBC/.Net section.
(2) Section 2.1.2: This section was a duplicate of
section 2.1.1; it has now been updated for “approach 2”.
(3) Section 4.1: Added paragraph regarding lack of IPv6
support in the current Ingres Corp network. (4) Section
4.2.4: Added 2 new paragraphs discussing logic to
handle multiple concurrent network listens…at least one
must be successful at startup and queuing network
listens completed prior to receiving the next
GCA_LISTEN. (5) Section 4.8: Updated and added to
References. (6) Section 6.1: At the end, replace “such
as GCC messages in errlog” with “not aware of any
changes needed”. (7) Section 6.2: Filled in list of
possible test combinations between client and server.
(8) Sections 2.1 & 3.3: Clarify that the sections are
organized by approach (1 & 2).
Aug 18, 2006
Bruce Lunsford
1.3 – (1) Section 2.5: added several paragraphs at end
of section re. building and running on platforms that
don’t support IPv6. Also updated remaining minimum
OS requirements. (2) Section 3.3: added paragraph
discussing IPv4-mapped IPv6 addresses. (3) Section
4.2.1: inserted new section on sockets. (4) Section
4.2.2: added more detail regarding the use of the new
IPv6 address structure with the socket-related functions
including the flowinfo field. (5) Section 4.2.5: 2nd
paragraph- added info about AI_PASSIVE and
INADDR_ANY on listen processing. (6) Section 4.8:
updated references. (7) Section 6.3 & 6.3.1: Misc
updates to regression/backward compatibility issues,
such as applications on Unix/Linux that statically link
Ingres.
Aug 23, 2006
Bruce Lunsford
1.4 – Changes from DDS Review + misc. (1) minor
spelling, formatting changes throughout. (2) Section
1.4: Added approach 3, which is to back up current
driver as ‘tcp_ipv4’. Added “Con” item to approach 2 to
highlight risk of using new IPv6 for Local IPC on
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 3 of 42
Revision Date
Last Revision By
Description of Change
Unix/Linux. (3) Section 2.1.3: Added approach 3. (4)
Add Sections 2.1.4 and 2.1.4.1: Propose config.dat
setting for IPv4 and IPv6 only. Also, discuss why vnode
connection attribute not a viable option for controlling IP
version. (5) Section 2.2: Update diagram for chosen
approach 3 and add note re. tcp_ipv4 to diagram. (6)
Section 3.2 and 4.2.5: Clarify that all addresses for a
server will listen on the same, standard Ingres port. (7)
Section 3.3.3: Added approach 3. (8) Section 3.5: DDS
Review summary. (9) Section 4.2.2: Use
sockaddr_storage for both IPv4 and IPv6. (10) Section
4.2.5: Added 2 paragraphs discussing concern over
connection time due to unsuccessful connection
addresses and a proposed cache solution. Added
paragraph discussing IPv4-mapped IPv6 addresses.
(11) Section 4.2.8 inserted: IPv6 colon hex address
formats and use in URLs. Also mentioned in Section
3.1. (12) Section 5.2: Filled in Documentation section.
(13) Section 6.3: If testing indicates new driver unstable
or slow for local IPC on Unix/Linux, change default to
TCP_IPv4.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 4 of 42
TABLE OF CONTENTS
1
INTRODUCTION .................................................................................................................. 6
1.1
1.2
1.3
1.4
2
ARCHITECTURE ............................................................................................................... 14
2.1
2.2
2.3
2.4
2.5
2.6
3
ESTIMATED EFFORT ........................................................................................................ 30
PROGRAMMING ............................................................................................................... 30
RESOURCES AND FILES ................................................................................................... 35
INTERFACE ...................................................................................................................... 35
UI RESOURCE/PROPERTIES FILES ................................................................................... 36
BITMAP RESOURCES ....................................................................................................... 36
ICON FILES ...................................................................................................................... 36
REFERENCES. .................................................................................................................. 36
IMPACT SUMMARY ......................................................................................................... 38
5.1
5.2
6
USER PERSPECTIVE ......................................................................................................... 23
ADMINISTRATION PERSPECTIVE ..................................................................................... 23
MIGRATION ISSUES ......................................................................................................... 24
SECURITY IMPACT ........................................................................................................... 28
CHANGES INITIATED BY REVIEWS/INSPECTIONS/WALKTHROUGHS............................... 28
INTERNAL SPECIFICATION .......................................................................................... 30
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
5
OVERVIEW....................................................................................................................... 14
SAMPLE FLOW/EXECUTION DIAGRAM ............................................................................ 19
I18N SPECIFIC ISSUES ...................................................................................................... 20
DESIGN LIMITATION AND ASSUMPTIONS ........................................................................ 20
PLATFORM SPECIFIC ISSUES............................................................................................ 20
PATENT INFORMATION .................................................................................................... 22
EXTERNAL SPECIFICATION ......................................................................................... 23
3.1
3.2
3.3
3.4
3.5
4
SCOPE ................................................................................................................................ 7
DEFINITIONS, ACRONYMS AND ABBREVIATIONS ............................................................. 8
REFERENCES ..................................................................................................................... 9
NOTEWORTHY ISSUES ....................................................................................................... 9
PRODUCT/COMPONENT IMPACTS .................................................................................... 38
DOCUMENTATION ........................................................................................................... 38
QUALITY ISSUES .............................................................................................................. 39
6.1
6.2
6.3
UNIT TESTING SUMMARY ............................................................................................... 39
TESTING RECOMMENDATIONS ........................................................................................ 39
REGRESSION RISK ASSESSMENT ..................................................................................... 40
7
PACKAGING AND INSTALLATION IMPACT ............................................................ 41
8
SUPPORT IMPACT ............................................................................................................ 42
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 5 of 42
PREFACE
This document describes external functional specifications as well as design
specifications for one component or design entity of a project. There will be many
Detailed Design Specifications (DDS) for each project, one for each major
feature described in the Software Requirements Specification (SRS). The SRS is
the master document for the entire project.
This is intended to be a living document. The product development cycle is a
dynamic process in which our understanding of the project and its criteria for
success are refined over time. It is therefore expected that the completed
Detailed Design Specification will undergo many revisions during the course of a
project as requirements; resources and constraints evolve.
The Development Manager is responsible for the contents of this document.
Deliverables that must be completed prior to releasing this document are:

Software Requirements Specification
All template instructions can be identified by their gray italic type. This information
may be removed after completing the necessary project information.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 6 of 42
1 INTRODUCTION
1.1 SCOPE
IPv6 (Internet Protocol version 6) is a new network standard for exchanging data
between machines and is intended to replace the current IP implementation
known as IPv4. There is currently little usage of IPv6, but it is expected that IPv6
will become the standard. In fact, there are government standards that dictate
usage of IPv6 by specified dates. The purpose of this project is to make the
changes necessary to Ingres such that it will support IPv6. The development
effort is localized to the following areas:
1. Ingres/Net protocol driver for TCP/IP on the various operating systems, which
is part of the compatibility library.
2. Ingres JDBC (Java) and .Net (C#) drivers -- these implement direct TCP/IP
communications with the Ingres Data Access Server.
3. Ingres Configuration utilities used to define network protocol information for
vnodes, such as netutil, netu, and vdba.
4. Ingres General Communications Facility (GCF) to ensure that IPv6 addresses
can be stored and transported without problem. These addresses are longer
and formatted differently than IPv4 addresses. Since GCF already provides
interchangeable usage of hostnames and IPv4 addresses, it is expected that
there will be few, if any, changes required to support the IPv6 addresses.
Some advantages of IPv6 over IPv4 are:



Larger (4x) network addresses. The internet is running out of available
addresses for IPv4 devices (computers, cell phones, and other mobile
equipment); the current address is 4 bytes long. Companies often must
set up private networks using Network Address Translator (NAT) to work
around the address limitations; unfortunately, NAT has some limitations of
its own. IPv6 has sufficient addresses for the future, without a need for
NAT.
New header format designed to minimize header overhead by moving
nonessential and optional fields to extension headers following the IPv6
header. This provides for more efficient processing at intermediate
routers.
Efficient and hierarchical addressing and routing infrastructure that
enables backbone routers on the internet to have much smaller routing
tables.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 7 of 42




Stateless and stateful address configuration. Even without DHCP, which
implements a stateful address configuration, hosts on a link can
automatically configure themselves.
Built-in security. Support for IPSec is an IPv6 protocol suite requirement.
Improved quality of service (QoS). New fields in the header define how
traffic is handled so QoS can be easily achieved even when the data is
encrypted with IPSec.
Packets are no longer limited to 64KB, which may improve performance
over high-throughput networks.
1.2 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
GCA: General Communications API. The communications module embedded
in GCF based applications and servers which enables local inter-process
communications.
GCC: General Communications Server. A GCF server which provides
network communications between client applications and Ingres DBMS servers
in separate Ingres installations (generally on separate machines).
GCF: General Communications Facility. A collection of communications
modules and servers which provide local and network communications
capabilities in an Ingres installation.
IP: Internet Protocol. (From Wikipedia) A data-oriented protocol used for
communicating data across a packet-switched internetwork. IP is a network
layer protocol in the internet protocol suite and is encapsulated in a data link
layer protocol (e.g., Ethernet). Data from an upper layer protocol, such as TCP,
is encapsulated inside one or more packets/datagrams.
IPv4: Internet Protocol version 4. (From Wikipedia) The fourth iteration of the
Internet Protocol (IP) and it is the first version of the protocol to be widely
deployed. IPv4 is the dominant network layer protocol on the internet and, when
ignoring its successor-- IPv6, it is the only protocol used on the internet.
IPv6: Internet Protocol version 6. (From Wikipedia) A network layer standard
used by electronic devices to exchange data across a packet-switched
internetwork. It follows IPv4 as the second version of the Internet Protocol to be
formally adopted for general use. Ipv6 was originally known as IPng (next
generation) and was adopted by the Internet Engineering Task Force (IETF) in
1994.
Protocol Driver: Network protocol drivers in Ingres provide the interface
between GCC and GCD servers’ transport layer (TL) and the host OS network
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 8 of 42
protocol API. There is generally a protocol driver for each network protocol such
as TCP/IP, SNA LU62, DECNET, etc.
Sockets, or Internet socket, or network socket. (From Wikipedia) A
communication end-point unique to a machine communicating on an Internet
Protocol (IP)-based network. Internet sockets are composed of an IP address
and a transport protocol port number. Operating systems generally provide an
API based on the Berkeley Sockets API for inter-application communication.
TCP: Transmission Control Protocol. (From Wikipedia) One of the core
protocols of the Internet protocol suite. Using TCP, applications on networked
hosts can create connections to one another, over which they can exchange
data in packets. The protocol guarantees reliable and in-order delivery of data
from sender to receiver. TCP is the intermediate layer between the Internet
Protocol (IP) below it, and an application above it, usually via a sockets API.
1.3 REFERENCES
N/A.
1.4 NOTEWORTHY ISSUES

IPv4 and IPv6 headers are not interoperable and the IPv6 protocol is not
backward compatible with the IPv4 protocol. Hence, hosts and routers
must support both. Applications, such as Ingres, ideally should support
both as well.

There are several possible ways to implement IPv6 in Ingres, one of
which must be chosen:
1. Add a new network protocol driver to Ingres that supports IPv6
only.
2. Add support for IPv6 to the existing Ingres ‘tcp_ip’ driver.
3. Rename the current driver to ‘tcp_ipv4’ for “backup” purposes and
create a new ‘tcp_ip’ driver that supports both IPv4 and IPv6. This is
essentially approach 2 with a “backoff” plan.
** Approach 3 was chosen. **
Initially, I was of the opinion and “assumed” that IPv6 would be
implemented as a new and separate network protocol for Ingres.
However, after reviewing the (abundant) IPv6 literature, I now believe we
should instead enhance the current Ingres tcp_ip network protocol driver
to support both IPv4 and IPv6. The designers of IPv6 went to great
lengths to provide for an easy and almost transparent migration from IPv4
to IPv6. The APIs have been enhanced to enable an application to
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 9 of 42
support both protocols concurrently. It was anticipated that the network
(hosts, routers and applications) will gradually shift from IPv4 to IPv6 with
a long period of time where the two protocols would coexist in a network.
A goal was to make this as transparent as possible to the end user. For
instance, when a particular host machine converts from IPv4 to IPv6, the
end user should be unaware. I think it is important for us to strive for that
goal as well. With that in mind, the following are some pros and cons of
the three approaches:
1. New Protocol Driver for IPv6 only
Pros:
-
Straightforward approach because Ingres has an easily extensible
architecture for multiple protocol drivers.
-
Similar to approach taken when Winsock2 (referred to as “tcp_ip”)
protocol driver was developed for Windows; prior driver was
Winsock1-based and referred to as “wintcp”.
-
Less chance of affecting current Ingres installations that are
running fine on IPv4. The IPv4 protocol driver would have no
changes in it AND the user would only begin using the new
protocol driver when he specifically requests it via configuration
changes.
Cons:
-
Significant amount of reconfiguration required by users as they
migrate to IPv6; see section “3.3 Migration Issues” below for
more details. Users (or administrators) will need to manually
change “tcp_ip” to “tcp_ipv6” (or similar string) in all pre-defined
vnode definitions via one of the Ingres configuration utilities on all
client machines as the target (server) machines shift to IPv6.
Also, applications that use dynamic vnodes will require changing.
Users may need to set up merged vnodes that define both a
“tcp_ip” and a “tcp_ipv6” protocol. Additionally, the config.dat will
need to be changed on all machines to enable the new protocol.
This could also get quite complicated for users as it is likely that
not all machines would migrate at the same time. Users are likely
to experience some down time as the manual changes must be
timed to coincide with network changes and manual changes
always introduce the chance of errors. NOTE that the manual
reconfiguration problem is being encountered today by users
wishing to switch from “wintcp” to “tcp_ip” on Windows. Some
utilities and/or configuration settings could be developed to
simplify this process, but this would require additional
programming effort.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 10 of 42
-
Administrative tools that configure vnodes (netutil, etc) and those
that configure Ingres/Net (cbf, vcbf) will need to have the new
protocol identifier (e.g., “tcp_ipv6”) added as a valid option.
-
New protocol drivers must be created that are 90% the same as
the existing tcp_ip drivers. Although the goal would be to share
code as much as possible, it is likely that there will be some code
which will be the same but must now be supported in two places.
This may result in higher ongoing support costs.
-
Due to the migration difficulties, the new code does not get as
much testing initially as users continue to run with the old driver.
Hence, problems do not get shaken out as quickly, leading to a
longer time period that the old driver must be kept around.
-
May get user complaints when other applications “transparently”
migrate to IPv6 but Ingres doesn’t.
2. Enhance Current Protocol Driver (essentially reverse the above pros
and cons)
Pros:
-
Straightforward approach because the socket APIs have been
designed to encourage applications to support both IP stacks
concurrently.
-
Migration of the user’s network to IPv6 is fairly transparent in that
it does not require Ingres configuration changes.
-
I sampled a couple of other databases and they seem to have
taken this approach.
-
Ingres utilities do not need to change to support a new protocol
driver.
Cons:
-
Slightly more complex coding required to support both IPv4 and
IPv6 in the same driver.
-
More difficult to separate IPv4 processing from IPv6 processing. I
suggest a config.dat parameter be added to enable only IPv4 or
IPv6, primarily for testing and debugging purposes.
-
IPv6 may get used unintentionally as the user’s network topology
changes with respect to IPv6 support and introduce unexpected
problems (though it shouldn’t). NOTE that the literature
recommends use of IPv6 over IPv4 when both protocols are
supported, which is the approach the Ingres driver would take.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 11 of 42
-
Connections from an IPv6-capable Ingres to older releases of
Ingres that don’t support IPv6 but reside on a machine that DOES
support IPv6 may take longer than currently. The recommended
address connection protocol algorithm (see RFC 3484) provides
all possible connection source/destination pairs in a preferred
order, with IPv6 connections being generally preferred over IPv4.
This means that the initial connection attempt to the destination’s
IPv6 address(es) will fail. Eventually, when the IPv4-to-IPv4 pair
in the address list is reached, the connection will succeed. It is
not clear how significant this overhead may be. However, it may
be worthwhile to provide some sort of mechanism to minimize this
impact—either a vnode connection attribute or an in-memory
cached dynamic table in the protocol driver that would remember
failed connection attempts and avoid the IPv6 address(es) for
future connection attempts; the in-memory cache would be
cleared, of course, when Ingres/Net is recycled. Other options for
clearing the cache could also be implemented – such as an
iimonitor command (now that iimonitor can talk to GCF servers) or
a timeout period where entries get cleared after a specified or
hard-coded period of time.
-
HIGH degree of risk to switch from proven existing IPv4-only
protocol driver to new IPv6 driver for local IPC on Unix and Linux.
Since network access is really not needed for the local IPC unless
‘connection_type = direct’ vnode attribute is being used, there is
no real benefit to implementing IPv6 support for the local IPC.
The exception may be when and if IPv4 support is ever dropped,
which is unlikely for a LONG time.
3. Rename the current driver to ‘tcp_ipv4’ for “backup” purposes and
create a new ‘tcp_ip’ driver that supports both IPv4 and IPv6.
Pros:
-
Same as approach 2.
-
Customers can back off to the old driver if needed. Hence, less
risk.
Cons:
-
Same as approach 2.
-
Administrative tools that configure vnodes (netutil, etc) and those
that configure Ingres/Net (cbf, vcbf) will need to have the new
“backup” protocol identifier (“tcp_ipv4”) added as a valid option.
Unlike approach 1, this new option does not need to be added to
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 12 of 42
the documentation, but will need at least internal documentation
so that Customer Support can advise customers if needed.
-
New protocol drivers must be created that are 90% the same as
the existing tcp_ip drivers. Although the goal would be to share
code as much as possible, it is likely that there will be some code
which will be the same but must now be supported in two places.
This may result in higher ongoing support costs. However, since
the ‘tcp_ipv4’ driver will not be enhanced and only fixed as
needed, very little maintenance to this code will be required;
eventually, it should be deprecated

If approach 1 (new driver) is taken, what string value should be used to
represent IPv6? The options proposed are ‘tcp_ip6’ or ‘tcp_ipv6’. This
compares with value ‘tcp_ip’ for the current IPv4 protocol on most
platforms, though there are variations such as ‘wintcp’. While ‘tcp_ip6’
seems short and straightforward for the user, ‘tcp_ipv6’ is more
“technically” correct as it relates to general industry usage in that the new
protocol is typically referred to as “IPv6”. ‘tcp_ipv6’ was the preferred
option chosen in the DDS review.

Because the protocol drivers are part of the CL and are, for the most part,
standalone entities from the perspective of the GCF servers, it would not
be difficult to port IPv6 support to an earlier release, if needed. Also note
that IPv6 support is very isolated in the code and so is unlikely to disrupt
other processing. While it is conceivable that IPv6 support may be
requested by customers for earlier releases, there are no current plans to
do so.

Support for IPv6 in the Ingres protocol drivers will need to be added
separately for each major platform type since they are part of the CL and
have slightly different implementations on each -- at least for the major CL
groups: Unix/Linux, Windows, VMS and mainframe (EDBC). This is also
the basic order that the protocol drivers should be implemented:
Unix/Linux and Windows first, VMS next, mainframe EDBC last. Lack of
support in VMS and/or mainframe EDBC should not hold up release of
IPv6 on the other platforms.

I thought that there may be some special facilities (such as rmcmd,
TNGapi, and Ingres/ICE) in Ingres that did their own networking and did
not use the Ingres/Net communication facilities. Investigation showed
that rmcmd and TNGapi use the normal GCA facilities to communicate
across Ingres installations, so do not require any changes. Ingres/ICE
was not researched, but is not supported any longer (as I understand it).
I am not aware of any other occurrences in the Ingres code that have
implemented their own networking.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 13 of 42
2 ARCHITECTURE
2.1 OVERVIEW
Three (3) approaches are discussed below in sections 2.1.1, 2.1.2 and 2.1.3
respectively. That is, all of the 2.1.1.* sections pertain to approach 1, 2.1.2.* ==>
approach 2, and 2.1.3.* ==> approach 3.
2.1.1
Approach 1: Add new Ingres/Net protocol driver for IPv6 only
IPv6 will be implemented as a new Ingres network protocol driver. It will be
referenced as ‘tcp_ipv6’.
2.1.1.1 Ingres Network Protocol Drivers
Ingres network protocol drivers are implemented as standalone drivers in the
GC CL. Ingres/Net, DAS and the Bridge server contain a table of protocol
drivers for network communications as well as for local communications on
Unix and Linux. Regardless of GCF server or remote versus local
communications, the same protocol driver is used per protocol. This
modularity is a big advantage since a new network protocol driver can be
written once for a particular CL platform and then used in various contexts.
Also, the implementations on all Unix and Linuxes are the same.
Unfortunately, the driver for different platform groups are not the same
(Windows vs. VMS vs. Unix/Linux for instance); these will each require
separate, but similar, coding efforts.
Since the IPv6 implementation uses the same function calls as IPv4, it
appears that the only difference is that the structures for the socket (IP
connection) control blocks are different between the 2 versions of IP. This
means that the code for the existing IPv4 protocol drivers will be used with
only minimal changes; it is expected that the source code will be shared.
2.1.1.2 Server Configuration
A new protocol option called ‘tcp_ipv6’ will be added in the configuration
utilities (CBF and VCBF) for Bridge Servers, Data Access Servers, and Net
Servers. As with other existing protocols, both Status and Listen Port may be
configured.
Additionally, for platforms that support it (Unix and Linux), II_GC_PROT must
also support ‘tcp_ipv6’ to enable the local IPC to run on IPv6. This will affect
all Ingres servers including the DBMS. However, it is implemented at the GC
CL layer, so should be transparent to the servers. At this time, it is planned
to keep the IPv4 protocol driver as the default in the local IPC table
(gcaptbl.c), but this may need to be revisited in the future.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 14 of 42
2.1.1.3 VNODE Configuration
A new protocol option called ‘tcp_ipv6’ will be added in the network utilities
(ingnet, netutil, and netu) to enable users to configure the new protocol. As
with other existing protocols, both hostname/ip address and Listen Port may
be configured. Due to the longer ip address, the hostname/ip address field
may need to be expanded. Any edits will need to support the new IP address
format. Dynamic vnodes don’t affect any utilities, but just need to ensure that
all fields are long enough and, if edited, will accept the new IP address
format.
2.1.1.4 JDBC and .Net Drivers
The connection logic will need to be enhanced to support both IPv4 and IPv6,
particularly the multiple address feature. If the approach is taken to keep the
current IPv4 and IPv6 code separate, then a new configuration setting will be
required to give the user control over which protocol to use. Presumably, this
would be a new JDBC driver attribute, and something similar for .Net.
2.1.2
Approach 2: Enhance existing Ingres/Net protocol driver
IPv6 will be implemented in the current Ingres network protocol driver
identified as ‘tcp_ip’ to support both IPv4 and IPv6 concurrently.
2.1.2.1 Ingres Network Protocol Drivers
The current ‘tcp_ip’ Ingres network protocol driver will be enhanced to use the
function calls required for IPv6, which, it so happens, were designed to be
used for both IPv4 and IPv6. The required changes that would have been
needed anyway for a new separate driver (see approach 1) will work for IPv4.
The result is that the driver will support BOTH IPv4 and IPv6.
The existing driver must be upgraded to support multiple addresses for
connecting and listening. This is probably the biggest change.
2.1.2.2 Server Configuration
Since no new protocol identifier is being added, there are no new or modified
settings required. An optional one is planned that will enable suppression of
IPv4 or IPv6 addresses.
2.1.2.3 VNODE Configuration
Existing vnode definitions will continue to work without any changes. Due to
the longer ip address, the hostname/ip address field may need to be
expanded. Any edits will need to support the new IP address format.
Dynamic vnodes don’t affect any utilities, but just need to ensure that all fields
are long enough and, if edited, will accept the new IP address format.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 15 of 42
2.1.2.4 JDBC and .Net Driver Configuration
The connection logic will need to be enhanced to support both IPv4 and IPv6,
particularly the multiple address feature. No associated configuration
changes are needed.
2.1.3
Approach 3: Rename current driver to ‘tcp_ipv4’ for “backup” and
enhance existing Ingres/Net protocol driver
(The “Chosen One”)
Rename the current driver to ‘tcp_ipv4’ for “backup” purposes and create a
new ‘tcp_ip’ driver that supports both IPv4 and IPv6. This is essentially
approach 2 with a “backoff” plan.
2.1.3.1 Ingres Network Protocol Drivers
The current ‘tcp_ip’ Ingres network protocol driver will be renamed/copied to
‘tcp_ipv4’ and used as a backup in case customers run into problems with the
new driver. This means that the network procedure driver tables
(local=gcaptbl.c, and network=gccptbl.c) must be modified to add ‘tcp_ipv4’.
The current ‘tcp_ip’ Ingres network protocol driver will be enhanced to use the
function calls required for IPv6, which, it so happens, were designed to be
used for both IPv4 and IPv6. The required changes that would have been
needed anyway for a new separate driver (see approach 1) will work for IPv4.
The result is that the new driver will support BOTH IPv4 and IPv6.
The existing driver must be upgraded to support multiple addresses for
connecting and listening. This is probably the biggest change.
2.1.3.2 Server Configuration
A new protocol option called ‘tcp_ipv4’ will be added in the configuration
utilities (CBF and VCBF) for Bridge Servers, Data Access Servers, and Net
Servers. As with other existing protocols, both Status and Listen Port may be
configured. It is not planned to document ‘tcp_ipv4’ in the Ingres manuals; it
will only be available internally for Customer Support to provide, as needed,
to customers.
Additionally, for platforms that support it (Unix and Linux), II_GC_PROT must
also support ‘tcp_ipv4’ to enable the local IPC to run on IPv4 only—ie, the
“back off” capability. Availability of ‘tcp_ipv4’ as an II_GC_PROT option is
automatically accomplished by adding the protocol to the local IPC protocol
table (see 2.1.3.1 section). This will affect all Ingres servers including the
DBMS. However, it is implemented at the GC CL layer, so should be
transparent to the servers. It is planned to keep ‘tcp_ip’ as the default
protocol driver in the local IPC table, so the new IPv6 support will be picked
up automatically. It is not planned to document ‘tcp_ipv4’ as an II_GC_PROT
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 16 of 42
option in the Ingres manuals; it will only be available internally for Customer
Support to provide, as needed, to customers.
An optional config.dat parm is planned that will enable suppression of IPv4 or
IPv6 addresses.
2.1.3.3 VNODE Configuration
Existing vnode definitions will continue to work without any changes. Due to
the longer ip address, the hostname/ip address field may need to be
expanded. Any edits will need to support the new IP address format.
Dynamic vnodes don’t affect any utilities, but just need to ensure that all fields
are long enough and, if edited, will accept the new IP address format.
A new protocol option called ‘tcp_ipv4’ will be added in the network utilities
(ingnet, netutil, and netu) to enable users to configure the old protocol.
2.1.3.4 JDBC and .Net Driver Configuration
The connection logic will need to be enhanced to support both IPv4 and IPv6,
particularly the multiple address feature. If the approach is taken to keep the
current IPv4-only code separate, then a new configuration setting will be
required to give the user control over which protocol to use. Presumably, this
would be a new JDBC driver attribute, and something similar for .Net. My
suggestion for the attribute would be to provide 3 choices: (default)
IPv6+IPv4, IPv4 only, IPv6 only.
2.1.4
Miscellaneous items common to more than one of the above
approaches
2.1.4.1 Enable only IPv4 or IPv6 protocol
It may be desirable to enable only one of the protocols: IPv4 or IPv6. This
might be useful in the following scenarios:
-
Only one protocol is supported between client and server –
eliminate wasted processing trying to use unsupported protocol.
-
User does not want the risk of new protocol IPv6 and wants to
stick with IPv4.
-
Compare the 2 protocols (performance and stability).
With approach 1, this is very easy because only the desired protocol, ‘tcp_ip’
or ‘tcp_ipv6’, would be used in the config.dat for Ingres servers and the
vnodes for client applications. For local IPC on Unix and Linux, set
II_GC_PROT to the desired protocol.
With approaches 2 & 3, both IPv4 and IPv6 are supported in the same
protocol driver, so selecting the driver name is not sufficient. With approach
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 17 of 42
3, IPv4 can be enabled by picking the backed up IPv4 protocol driver,
‘tcp_ipv4’, but no similar solution exists for selecting only IPv6. Instead, a
config.dat setting for the protocol driver will be added (approaches 2 & 3
only). It is proposed to be the following:
tcp_ip.IPv with values of:
4
- IPv4 only
6
- IPv6 only
all
- IPv4 & IPv6 (default)
Examples:
ii.machine.gcc.*.tcp_ip.IPv:
4
/* for Ingres/Net comm. Server */
ii.machine.gcd.*.tcp_ip.IPv:
4
/* for DAS */
These configuration parameters must be added to the configuration utilities:
CBF and VCBF.
NOTE that on Unix and Linux, when the ‘tcp_ip’ (dual stack) protocol driver is
used as the local IPC, this configuration setting will also be in effect. If IPv4only support is desired, II_GC_PROT should also be set to ‘tcp_ipv4’ to
ensure that applications and all servers in the installation also use IPv4 only.
Alternatively, but more complicated, one could use the new driver but restrict
it to IPv4 or IPv6 for the local IPC by setting the appropriate config.dat setting
for applications and each server in the Ingres installation:
ii.machine.tcp_ip.IPv:
4
/* for applications (local IPC) */
ii.machine.gcn.tcp_ip.IPv:
4
/* for Name Server (local IPC) */
ii.machine.ingres.*.tcp_ip.IPv:
4
/* for Ingres DBMS (local IPC) */
Another configuration option considered was to add a connection attribute for
vnodes that would force connections on that vnode to use either IPv4 or IPv6.
This has the benefit that the choice of IPv4-only, IPv6-only, or both can be
made at the vnode level, rather than for the entire Ingres installation. This
was struck down, however, because it would involve too many changes; the
name server would have to pass the connection attribute value to the
application to pass to the Ingres communications server to pass down
through his layers to the protocol driver. That is a lot of work and not
considered worth the benefit.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 18 of 42
2.2 SAMPLE FLOW/EXECUTION DIAGRAM
Client Application
C
L
I
E
N
T
M
A
C
H
I
N
E
GCA
GC(A) CL – Local IPC
tcp_ip protocol driver
(Unix/Linux only)
JDBC or .Net
Application
JDBC or .Net Driver
TCP IPv6+IPv4 protocol
in Java or .Net
tcp_ip protocol driver
(Unix/Linux only)
GC(A) CL – Local IPC
GCA
INTERMEDIATE
MACHINE
GCC
GC(C) CL-Network IPC
tcp_ip protocol driver
tcp_ip protocol driver
GC(C) CL-Network IPC
GCB
S
E
R
V
E
R
M
A
C
H
I
N
E
tcp_ip protocol driver
tcp_ip protocol driver
GC(C) CL-Network IPC
GC(C) CL-Network IPC
GCC
GCD
GCA
GCA
GC(A) CL – Local IPC
GC(A) CL – Local IPC
tcp_ip protocol driver
tcp_ip protocol driver
(Unix/Linux only)
tcp_ip protocol driver
(Unix/Linux only)
GC(A) CL – Local IPC
GCA
DBMS
(Unix/Linux only)
NOTE: For “back off” purposes, the
tcp_ipv4 protocol driver can be used
instead of the tcp_ip protocol driver in
all places shown. However, tcp_ipv4
could not be used to communicate with
a tcp_ip driver over IPv6.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 19 of 42
2.3 I18N SPECIFIC ISSUES
None.
2.4 DESIGN LIMITATION AND ASSUMPTIONS
None.
2.5 PLATFORM SPECIFIC ISSUES
Each IPv6 network protocol driver must be implemented separately on each CL
platform group: Windows, Unix/Linux, VMS and mainframe (EDBC).
Windows XP specifies in the Help system that IPv6 is “prerelease code and is not
intended for commercial use”. However, Microsoft states in their main IPv6
documentation on the web that IPv6 is built into the latest versions of Microsoft
Windows, including Server 2003, XP with SP1 and/or SP2, CE .NET, Vista and
“Longhorn”. See Microsoft web site
http://www.microsoft.com/technet/itsolutions/network/ipv6/default.mspx for
current information about Microsoft’s plans for IPv6. Prior to Windows XP SP1,
the IPv6 support from Microsoft was not GA and we will not attempt to support
the non-GA versions.
Some new functions were added for IPv6 in Vista and Longhorn; these will not be
utilized by the driver because we must be able to build on Windows XP, which
will not have these functions. These functions are generally of the form WSA*
and include WSAConnectByName() and WSAConnectByList().
The networking stack has been redesigned in Vista and Longhorn. Though this
should not affect us, it should be included in the testing.
The operating systems release minimums required for IPv6 are:
-
Microsoft Windows XP SP1, 2003, (+ Vista and Longhorn)
-
AIX 5.2 with maintenance level 3 (ML3)
-
HP-UX 11i
-
Sun Solaris 8.0
-
Red Hat Enterprise Linux (RHEL) Advanced Server with update
2.4
-
Novell SUSE Enterprise Server 8.0 with SP3
-
Java 1.4
-
HP OpenVMS 5.1
-
HP Tru64 UNIX 5.1
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 20 of 42
-
IBM z/OS V1R5
The above minimum supported releases need to be compared with the release
that Ingres is built on for every supported platform. If the operating system
release that Ingres is built on is less (earlier) than the minimum release required
for IPv6, then the product won’t build. If this situation exists (yet to be
determined), then #ifdef’s could be used to allow the tcp_ip protocol driver to be
built (with just the current IPv4 support). However, this is not really a good
solution because if later releases (than the build release) of the operating system
DO support IPv6 (which is likely), then Ingres on that platform won’t support IPv6
at all! If at all possible, it would be best if Ingres was only built on OS releases
that support IPv6. If this is not possible for all platforms, then perhaps we could
copy the needed files to get the protocol driver to build with IPv6 and then count
on runtime logic (see next paragraph) to determine if IPv6 functionality actually
exists on the installed system.
A similar, but slightly different, problem to the one in the prior paragraph would
occur at run time if IPv6 functions don’t come installed by default in the operating
system. For instance, IPv6 is supported as of Windows XP SP1, but must be
manually “enabled” on each desired interface (local area Ethernet adapter +
wireless for instance). It is not clear (yet) what happens if one attempts to run
IPv6-enabled Ingres on a Windows system that supports IPv6 but has not yet
had it enabled. This must be tested early in the development process because it
will significantly impact the code. It “may” work just fine and the new IPv6
functions, like getaddrinfo() may exist in Windows without enabling IPv6 on any
network interfaces. If not, Ingres should still run and just downgrade to IPv4
support only; it shouldn’t generate an error and prevent startup of Ingres. It may
be necessary to check at run time for the existence of any such functions, which
is fairly easy to do in Windows. However, it would mean that code that
references the old, replaced functions could not be removed and must continue
to be available if the IPv6 functions are not found. For this reason, the new IPv6
functions should only be used when necessary. While the example provided was
for Windows, this may also be true on other operating systems as well.
For most platforms, Ingres is built on the lowest supported release. For
Windows, this does not seem to be the case. We typically build on Windows XP,
but Windows 2000 (as of the current product matrix for Ingres r3) is still
supported. Note that Windows 2000 has no GA version of IPv6 so I suspect will
generally NOT have the new IPv6 functions. Hence, this will most certainly
require the runtime code check for the IPv6 functions mentioned in the prior
paragraph…or drop support for Windows 2000 (including Server).
If IPv6 support is ever cross-integrated back to an earlier release of Ingres,
platform support will be an even bigger issue as prior releases of Ingres are built
and run on older versions of the OS, less likely to support IPv6.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 21 of 42
2.6 PATENT INFORMATION
None.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 22 of 42
3 EXTERNAL SPECIFICATION
3.1 USER PERSPECTIVE
A comment in the Release Notes should be added indicating that IPv6 support
has been added and perhaps a sentence or two about the benefits of IPv6 (larger
address space for instance).
With approach 1, ‘tcp_ipv6’ would be a new network protocol option that the user
could specify when setting up vnode definitions or dynamic vnode connection
strings. The new value for IPv6, ‘tcp_ipv6’, should be added to the Ingres
Connectivity Guide wherever the supported protocols are listed; TIP: scan for
“tcp_ip”.
With approach 3, ‘tcp_ipv4’ would be a new network protocol option that the user
could specify when setting up vnode definitions or dynamic vnode connection
strings to go back to the old IPv4-only protocol. This would not be documented
in the manuals and only provided to customers by Ingres Support when problems
occur with the new IPv6 enabled protocol driver.
User can specify IPv6 formatted IP addresses (colon hexadecimal format)
wherever hostnames and IPv4 (dotted decimal format) can be specified. These
new formats may need to be enclosed in square brackets for the JDBC and .Net
drivers to properly parse (RESEARCH!).
3.2 ADMINISTRATION PERSPECTIVE
With approach 1, the protocol ‘tcp_ipv6’ must be enabled by the Ingres
administrator (or DBA) during installation of Ingres or later during configuration.
With approach 3, the protocol ‘tcp_ipv4’ must be enabled by the Ingres
administrator (or DBA) during installation of Ingres or later during configuration if
there is a need to back off to the old IPv4-only protocol driver.
Any new configuration options added for IPv6 should be documented. These
include:
-
config.dat parm to restrict the Ingres TCP/IP protocol driver to only
use IPv4 or IPv6. [Approach 2 & 3 only]
The ports that Ingres listens on will not change. Although the Ingres tcp_ip
protocol driver may listen on multiple addresses (at least one for IPv4 and one or
more for IPv6), all of the addresses will listen on the same port. That is,
Ingres/Net will continue to listen on the symbolic II0 port where II is the 2character Ingres installation id; this is converted internally by Ingres to a numeric
port.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 23 of 42
3.3 MIGRATION ISSUES
It is expected that users will often have a phased approach to implementing IPv6
in their networks since IPv6 often requires upgrades in networking hardware
(such as routers and switches) and OS releases. The migration issues for all
approaches are discussed below.
Three (3) approaches are discussed below in sections 3.3.1, 3.3.2 and 3.3.3
respectively. That is, all of the 3.3.1.* sections pertain to approach 1, 3.3.2.*
sections pertain to approach 2, and 3.3.3.* sections pertain to approach 3.
Independent of the approach used, one scenario that requires special
programming in either approach is the following. One Ingres installation is IPv4
only, either because the OS or Ingres doesn’t support IPv6. The other Ingres
installation is IPv6 only, either because the OS only supports IPv6 or Ingres is
configured to only support IPv6. I think an IPv6-only system is unlikely because
OS’s will continue to support IPv4 for the foreseeable future and it doesn’t make
sense for a customer to turn off IPv4 in Ingres when he still has IPv4 nodes in his
network. However, if we want to support this, we could by using IPv4-mapped
IPv6 addresses. This requires additional code (not extensive) in the protocol
driver. I propose that we not implement this at this time as I am doubtful that it
will be needed by customers; it could be a stretch goal for the project.
3.3.1
Approach 1: Add new Ingres/Net protocol driver for IPv6 only
Ingres allows the user to transition gradually to an IPv6 network by only enabling
IPv6 as needed.
Current Ingres installations will continue to run on the old IPv4 network protocol
since ‘tcp_ip’ will not change (i.e., will still be used for IPv4). Users wishing to
take advantage of IPv6 will need to do the following:
3.3.1.1 Ingres/Net
If using Ingres/Net for communications between the client and server:
1. Configure ‘tcp_ipv6’ status to yes for communication servers (gcc) on
both client and server. In the configuration manager, go to Net
Servers -> default -> Protocols tab and click Status box on
(checkmark) for protocol ‘tcp_ipv6’. Make sure the Listen Address is
different from any of the other network protocols that are activated
(status = on) for that Net server (or DAS or bridge server, if
applicable).
2. Use ‘tcp_ipv6’ as network protocol for new or existing vnode
definitions and/or dynamic vnode connection strings on client
machines.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 24 of 42
3.3.1.2 JDBC and/or .Net Applications
If using JDBC or .Net applications:
1. Configure ‘tcp_ipv6’ status to yes for the relevant Data Access Server
(gcd, aka DAS); the DAS may be configured to run on the client or the
server, or both. In the configuration manager, go to Data Access
Servers -> default -> Protocols tab and click Status box on
(checkmark) for protocol ‘tcp_ipv6’. Make sure the Listen Address is
different from any of the other network protocols that are activated
(status = on) for the DAS, Net, or Bridge servers in that installation.
2. ?? Need to determine how to tell the JDBC and .Net drivers to use
IPv6 to connect to the DAS.
3. If the DAS and the Ingres DBMS are running in different Ingres
installations, then the URL connection string will contain vnode
information. As with standard client connections using Ingres/Net,
use ‘tcp_ipv6’ as the network protocol for new or existing vnode
definitions and/or dynamic vnode connection strings.
4. The connection between the JDBC/.Net driver and the DAS does not
have to use the same network protocol as the connection between the
DAS and the DBMS (when running in different installations). One can
be converted to IPv6 while the other leg of the connection can remain
IPv4. In fact, since the DAS to DBMS connection uses Ingres/Net,
any network protocol supported by Ingres/Net will work. This fact
could be used to ease migration issues when only parts of a user’s
network migrate to IPv6 initially.
3.3.1.3 Ingres Bridge
The Ingres Bridge server may be needed for communications between the client
and server (actually between Ingres/Nets) when one, but not both, the client and
server machines support IPv6. The most likely scenario is that the server is
upgraded to support IPv6, but not all of the clients are. One option, if supported
by the server OS and hardware, is to configure both IPv6 and IPv4 in the server;
clients that support IPv6 can connect to the IPv6 port while clients that don’t can
continue to connect to the IPv4 port. Another alternative is to only configure the
server with IPv6 and then add an Ingres Bridge server to an intermediate
machine (between client and server) that supports both IPv6 and IPv4. The input
protocol to the Bridge would be IPv4 and this would be mapped to an output
vnode with protocol IPv6.
1. Install Ingres on an intermediate machine that supports both IPv4 and
IPv6, or configure the bridge server on an existing Ingres installation
that meets the same requirements. Make sure the Startup count for
the Bridge server is set to 1 (since the default is 0).
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 25 of 42
2. Configure ‘tcp_ip’ and ‘tcp_ipv6’ statuses to yes for the bridge server
(gcb). In the configuration manager, go to Bridge Servers -> default > Protocols tab and click Status box on (checkmark) for protocols
‘tcp_ip’ and ‘tcp_ipv6’. Make sure each Listen Address is different
from any of the other network protocols that are activated (status =
on) for that Bridge server (or DAS or Net server, if applicable).
3. Configure outgoing (to DBMS) vnode network protocol as ‘tcp_ipv6’
and configure incoming protocol in Configuration Manager as ‘tcp_ip’.
The reverse would also work if the client has been upgraded to IPv6
but not the server.
3.3.1.4 Local IPC on Linux and Unix
On Unix and Linux, the local IPC is, by default, IPv4; it currently may be
overridden with the II_GC_PROT variable to another supported local IPC
protocol (such as Unix Domain Sockets). Users will now have the option of
overriding the default local IPC (which will remain TCP_IP, aka IPv4) to
TCP_IPv6.
3.3.1.5 General NOTES
1. Both sides of each connection (client and server) must be changed to utilize
IPv6 since it is not compatible with IPv4. That is, an IPv6 connection from a
client cannot connect to an IPv4 port on a server, or vice versa.
2. Since there are no plans to support IPv6 in prior releases of Ingres, access to
older Ingres releases must be done with IPv4.
3. Clients and servers may concurrently use both IPv4 and IPv6 connections.
4. DISCUSS! It may be desirable to provide a way for users to easily convert
existing IPv4 connections to IPv6 connections without setting up new vnodes
and reconfiguring Net/DAS/Bridge servers to support IPv6. This is very
similar to the problem we have with getting users on Windows to switch to the
relatively new tcp_ip protocol (Winsock 2) from the older wintcp protocol
(Winsock 1) and should probably be handled in the same way. Approaches
considered are:
a. Provide a utility (required only on Windows, but is generic) that will
scan the vnode file and replace all occurrences of one protocol with
another. Users would need to run this once while their Ingres
installation(s) are down. It does not address dynamic vnodes, but
these are (we think) less used as they have only recently been
documented for general use. The users would still need to change
their GCF server configurations.
b. Add a config.dat setting for Ingres/Net, DAS and possibly the bridge
server that makes one protocol equivalent / aliased to another. For
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 26 of 42
instance, one could set ‘wintcp’ to be equivalent to ‘tcp_ip’ so that any
requests to wintcp would actually be directed to the ‘tcp_ip’ protocol
driver – likewise ‘tcp_ip’ could be set to ‘tcp_ipv6’. This would make
transitions more transparent for some users.
3.3.2
Approach 2: Enhance existing Ingres/Net protocol driver
Ingres would immediately and transparently begin using IPv6, wherever possible,
as the network is migrated to IPv6.
3.3.2.1 Ingres/Net
None.
3.3.2.2 JDBC and/or .Net Applications
None.
3.3.2.3 Ingres Bridge
None.
3.3.2.4 Local IPC on Linux and Unix
None.
3.3.2.5 Rmcmd, TNGapi, misc
None.
3.3.2.6 General NOTES
Since there are no plans to support IPv6 in prior releases of Ingres, access to
older Ingres releases must be done with IPv4.
3.3.3
Approach 3: Rename current driver to ‘tcp_ipv4’ for “backup” and
enhance existing Ingres/Net protocol driver
(The “Chosen One”)
Rename the current driver to ‘tcp_ipv4’ for “backup” purposes and create a new
‘tcp_ip’ driver that supports both IPv4 and IPv6. This is essentially approach 2
with a “backoff” plan.
Ingres would immediately and transparently begin using IPv6, wherever possible,
as the network is migrated to IPv6.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 27 of 42
3.3.3.1 Ingres/Net
None, unless problems are encountered with the new IPv6 enabled driver; if so,
the customer could back off to the old driver by configuring the ‘tcp_ipv4’ protocol
driver in the config.dat for the GCC server(s).
3.3.3.2 JDBC and/or .Net Applications
None, unless problems are encountered with the new IPv6 support; if so, the
customer could back off to the old IPv4-only code by configuring the ‘tcp_ipv4’
protocol driver in the config.dat for the GCD server and, if available (TBD), set
new JDBC/.Net driver URL attribute to IPv4-only setting.
3.3.3.3 Ingres Bridge
None, unless problems are encountered with the new IPv6 enabled driver; if so,
the customer could back off to the old driver by configuring the ‘tcp_ipv4’ protocol
driver in the config.dat for the GCB server.
3.3.3.4 Local IPC on Linux and Unix
None, unless problems are encountered with the new IPv6 enabled driver; if so,
the customer could back off to the old driver by setting II_GC_PROT to
‘tcp_ipv4’.
3.3.3.5 Rmcmd, TNGapi, misc
None.
3.3.3.6 General NOTES
Since there are no plans to support IPv6 in prior releases of Ingres, access to
older Ingres releases must be done with IPv4.
3.4 SECURITY IMPACT
The IPv6 specification requires implementation of the IPSec network security
protocol. Since usage is optional, taking advantage of this will be deferred to the
next release, but will be a stretch goal for this release. The effort required to
implement IPSec is not known at this time. It is considered a very desirable
feature as it will allow data between Ingres clients and servers to travel in an
encrypted format.
IPv6 does not introduce any new security exposures over the prior IPv4 protocol.
3.5 CHANGES INITIATED BY REVIEWS/INSPECTIONS/WALKTHROUGHS
Use table below to document changes for a component or a design entity.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 28 of 42
Date
Aug 18,
2006
Type
No
Change Description
1
Initial DDS review decided on new approach 3, which will
provide a backup capability by copying/renaming the old
protocol driver and calling it ‘tcp_ipv4’. This will only be
made known to Ingres Support to provide to customers on
an “as needed” basis. See DDS Meeting Minutes for more
details and other changes.
2
3.5.1
Change Description 1
In this section describe each change and its impact. Create a sub-section for
each change identified in the table above.
Click here to begin typing
3.5.2
Change Description 2
Click here to begin typing
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 29 of 42
4 INTERNAL SPECIFICATION
4.1 ESTIMATED EFFORT
Windows protocol driver– 1 week
Linux/Unix protocol driver – 1 week
JDBC Driver – 3 days
.Net Driver – 3 days
Net Configuration Utilities – 2 days
VMS – 1 week (to be done later)
z/OS – 1 week (to be done later)
Part of the effort, at least initially, is setting up the Ingres Corporation network for
IPv6. I have already started this process with the IT department since our
network does not currently appear to be set up for IPv6. For instance, the IPv6capable ping command cannot ping over IPv6 addresses between 2 IPv6enabled Windows machines; using the IPv6 loop back or local address DOES
work with ping, so initial testing can be done in loop back mode. Also, nslookup
(DNS) does not return IPv6 addresses; ipconfig does.
4.2 PROGRAMMING
Change the Ingres network protocol drivers for TCP/IP to support the changes
required for IPv6.
4.2.1
Sockets
The socket() function is used to create a socket descriptor that represents a
communication endpoint. The first argument to the function tells the system which
protocol to use. For IPv4, this is set to PF_INET or AF_INET (#defined to the same
value, though PF_INET is really the proper one to use). For IPv6, this must be set to
PF_INET6 or AF_INET6. The getaddrinfo() function returns the family (protocol) of
each address; this must then be used in the subsequent socket() call for each address.
4.2.2
Address Structure
The “sockaddr_in” structure is the protocol-specific data structure for IPv4. A
new data structure, sockaddr_in6, has been added to allow for the bigger IPv6
addresses plus the new fields utilized by IPv6: flowinfo and scope_id. Function
calls that pass in or get back the socket address must use the sockaddr_in6
structure for IPv6 addresses or use the sockaddr_storage structure, which can
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 30 of 42
be used for both IPv4 and IPv6. The structure sockaddr_storage will be used
since it can be used for both protocols. This includes the following functions:
bind(), connect(), accept(), getpeername() plus others that are less likely to be
used in the Ingres code. Note that the syntax of the function calls have not
changed and the address structure is passed as an opaque pointer to each
function, along with a length indicator.
The field “flowinfo” in the IPv6 address structure should be set to zero. This field
is used to identify flows of packets (aka, “flow labels” which are a combination of
the source and destination addresses plus the flowinfo field). For instance, all of
the packets on a particular transport connection could be identified with a unique
flow id. There are various rules and restrictions associated with using flows (see
RFC 3697). At this time, I don’t see a benefit in using them. They could be
useful at some point to identify the Ingres expedited channel or to multiplex
messages from different logical connections over a single network connections.
The field is 20 bits in length.
4.2.3
Name to Address Translation Functions
The name-to-address translation functions in the socket interface are
gethostbyname() and gethostbyaddr(). These are left as is and new functions
are defined to support IPv4 and IPv6. Additionally, the POSIX 1003.g draft [3]
specifies a new nodename-to-address translation function which is protocol
independent. This function can also be used with IPv4 and IPv6.
4.2.4
Address Conversion Functions
The address conversion functions, inet_ntoa() and inet_addr(), convert IPv4
addresses between binary and printable form. These functions are quite specific
to 32-bit IPv4 addresses. Two analogous functions have been added that
convert both IPv4 and IPv6 addresses, and carry an address type parameter so
that they can be extended to other protocol families as well.
4.2.5
Address Selection (RFC3484)
With IPv6, each interface on the host is often assigned multiple addresses. With
IPv4, there was generally only 1. This complicates address selection because
the source and destination addresses used must be compatible and there are
now more than one to choose from. RFC 3484 documents how the address
selection process should work. The algorithm gives preference to IPv6
addresses. Much of it is implemented in the OS. From the Ingres protocol
driver’s perspective, the connection logic will be changed to utilize function
getaddrinfo(), which will return a list of addresses for the designated server in the
preferred order. The driver will then try to connect to each address in the list until
a connection is successful.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 31 of 42
There is a concern that trying to connect to multiple addresses will slow
connection performance if the first address connect is not successful. That is,
there will be overhead and time spent trying to connect to addresses that don’t
work. It is not known if the amount of the slowdown is significant, but it likely is,
since network operations, particularly connection requests, are relatively costly,
particularly relative to CPU. The impact of unsuccessful connection requests
should be measured in testing. The most likely scenario where this problem
would exist is when an Ingres client with IPv6 support attempts to connect to an
older Ingres server without IPv6 support, but running on an IPv6-enabled host.
Both IPv6 and IPv4 addresses would be returned to the client if connecting by
hostname (vs IP address); since the Ingres server would not respond to the initial
IPv6 connection requests, the overall connection time will likely be slower.
Connection time for Ingres has been a problem in the past, so it is important to
ensure that it is not made worse.
To minimize the overhead of unsuccessful connect attempts, the code should
learn from failed connection attempts and not continue to retry bad addresses.
This could be done by caching the successful address for each unique target
host/port combination so that future connection requests to the same target
would first try the successful address. One problem with this approach is that the
target may get recycled and, in the process, become enabled for a previously
unsuccessful address; until the client cache is reset, the new address wouldn’t be
used. However, this is less important than the connect speed. An example of
where this scenario would be likely to occur is as follows. If the target system is
upgraded to a newer release that supports IPv6, but the Ingres client is not
recycled, then the client would continue to use the old IPv4 address rather than
the IPv6 address. To avoid this, the cache would need to be flushed at some
point; this could be based on a count of connection requests, an elapsed time
period, an operator command (such as from iimonitor), or all of the above. The
new iimonitor could be used to flush the cache in GCF servers and even the
DBMS (notably Star), but wouldn’t be much help for the local IPC on Unix and
Linux (often configured for TCP/IP) between applications and the local Ingres
system. However, this is probably fine since applications would likely get
recycled anyway when the local Ingres installation is recyled, thus refreshing the
cache. Whatever mechanism is selected, it could be made configurable;
however, I don’t think it is worth the effort and recommend hard-coding it until
such time that experience dictates it should be configurable.
On the listen side, passing flag AI_PASSIVE to getaddrinfo() will return one
address for each supported protocol family that is appropriate for listening on for
the local machine. Specifically, the returned address will have the appropriate
“any address” value (IPv4->INADDR_ANY, IPv6->IN6ADDR_ANY_INIT). The
server will then listen on each address with the same, standard port configured
for that server in that Ingres installation. Hence, the server will be listening on
multiple IP addresses concurrently, each with the same port id.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 32 of 42
At startup, at least one of the network listens must be successful for the
GCA_LISTEN request to be considered successful. Additionally, network listens
that fail should be removed from the list or marked in some way such that we
don’t continue to retry them.
Listening on multiple addresses presents a complication when a remote user
connects and one of the listens is posted. While the GCA_LISTEN completion
routine will be driven in the usual fashion, when a new GCA_LISTEN is
requested, the protocol driver must only repost a TCP listen on the address that
was previously connected to. Since the GCA will not provide this information in
the GCA_LISTEN, the protocol driver must keep track of this himself. Another
complication is that another listen address may be connected to before the GCA
wraps around and reissues a GCA_LISTEN; if this occurs, the protocol driver
must hold off on driving any GCA_LISTEN completion routines until the new
GCA_LISTEN request is received. To handle these complications, the protocol
driver should maintain an internal status associated with each of the listen
addresses and a status or flag indicating whether a GCA_LISTEN is pending.
When a network listen address is connected to, the protocol driver should only
post the GCA_LISTEN completion routine if the GCA_LISTEN pending flag is on;
in other words, ensure that each completed network listen waits for an
associated GCA_LISTEN request. A network listen “could” immediately be
reissued on the address that received a connect prior to driving the
GCA_LISTEN address; however, this approach requires a queue to be setup of
all network listens that are pending a GCA_LISTEN request because one
address could get any number of network listens prior to receiving a
GCA_REQUEST; hence, a simple status field associated with the address
wouldn’t be sufficient. An alternative to reposting network listens immediately is
for the driver to keep track, for each address, if it is awaiting a GCA_LISTEN
request and not issue the network listen until the next GCA_LISTEN is received;
this is doable with a status field associated with each address in the driver since
each address could only have one such pending event at a time, and no queue
of pending GCA_LISTENs would be required. NOTE that the GCA_LISTEN
request itself will not tell the driver which listen address to reissue because it
does not contain any IP address info.
The system administrator can configure the rules that determine what addresses
are returned and in what order from getaddrinfo(). This is an “operating system”
feature though and not part of Ingres.
There are various flags (see ai_flag field) that can be set to control what is
returned from getaddrinfo(). One such setting, AI_V4MAPPED, will cause the
returned address(es) to be returned as IPv4-mapped IPv6 addresses. These
types of addresses are useful when connecting from an IPv6-only application or
system to an IPv4-only application or system. However, I believe this will be
unnecessary for Ingres as we plan to support both types of addresses in the new
Ingres protocol driver. However, the Ingres administrator could specifically
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 33 of 42
restrict Ingres to IPv6-only via a configuration setting; in this case, to get to an
IPv4 system, the user would need to directly enter the remote node name in an
IPv4-mapped IPv6 address format.
4.2.6
Ingres Networking Configuration Utilities
Any utility used to configure Ingres/Net vnodes must be reviewed to verify that
IPv6-style addresses can be entered and displayed. Also, all fields used to store
the addresses must be checked to make sure they are long enough. It is
anticipated that these will generally be OK because they already should
accommodate long host names and are generally just used as character strings,
without having to convert from one format to another.
4.2.7
JDBC and .Net Drivers’ Network IO to DAS
Changes similar to those made in the protocol drivers must be made to the JDBC
and .Net drivers in the code that communicates with the DAS. NOTE that this
code is in Java and C# respectively. Since these are not servers, there is no
associated listen logic. However, the connect logic will need to change to
account for the multiple source and target IP addresses.
without having to convert from one format to another.
4.2.8
IPv6 Colon Hexadecimal Address Format
Users can specify IPv6 formatted IP addresses (colon hexadecimal format)
wherever hostnames and IPv4 (dotted decimal format) can be specified.
Research the web standard to see if there is a “standard” format for URLs. Also,
check the JDBC and .Net drivers to see if the new format will cause parsing
problems. Parsing changes will likely be required in the JDBC and .Net drivers
for the URL since the colon “:” is used already as a separator in the URL. Also
note that the ability to collapse IPv6 0-valued hex components into a double
colon “::” may conflict with the double colon used to separate the vnode from the
database name in the standard Ingres connection string (which is also part of the
URL). This needs more research.
Examples of addresses:
Description
IPv4
IPv6
loopback
127.0.0.1
::1
local
10.3.30.50
fe80::208:dff:fe7c:fecc%5 (link local)
IPv4-mapped
N/A
::FFFF:10.3.30.50
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 34 of 42
In the local address format, the “%5” suffix is the interface id and is, I believe,
optional; it is arbitrarily assigned by IPv6, starts at 1 and increments by 1 for each
interface (including tunnels).
Also note that the total length of the IP address formats is longer with IPv6. With
IPv4, the maximum length was 15 bytes (999.999.999.999); with IPv6, the
maximum length is 39 bytes (xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx) and
possibly longer if IPv4 address is concatenated in the case of IPv4-mapped
addresses (these usually (always?) however have less than full length IPv6
portions). Since hostnames can also be quite long, and the same internal fields
are used to store hostnames and IP addresses, it is expected that the current
lengths will be sufficient, but it needs to be researched.
NOTE that even though IPv6 introduces a new address format, the port ids have
not changed. They are typically displayed in decimal or, for Ingres, as a symbolic
port id consisting of the Ingres 2-character installation id followed by an octal digit
of 0 through 7.
4.2.9
EDBC Server display of IP addresses (D A command) [EDBC
only]
When IPv6 is added to the EDBC server, the operator “D A” command will need to be
modified to support the longer IPv6-style addresses in the output. Also, any console or
error log messages that display the remote client’s IP address will need to likewise be
modified.
4.3 RESOURCES AND FILES
4.3.1
System Files and Physical Devices
Name
4.3.2
Version
New
Description of
module or entity
Description of
change
Memory Usage
N/A
4.4 INTERFACE
N/A
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 35 of 42
4.5 UI RESOURCE/PROPERTIES FILES
File Name
Byte Count
Word Count
Format
Comments
4.6 BITMAP RESOURCES
File
Comments
File
Comments
4.7 ICON FILES
Release note
System
requirements
4.8 REFERENCES.
1. IETF (Internet Engineering Task Force) IPv6 Working Group (IPv6)
http://www.ietf.org/html.charters/ipv6-charter.html
(Lists and links all associated RFC docs)
2. RFC 3484: Default Address Selection for Internet Protocol version 6 (IPv6)
http://www.ietf.org/rfc/rfc3484.txt
3. RFC 3493: Basic Socket Interface Extensions for IPv6
http://www.ietf.org/rfc/rfc3484.txt
(obsoletes earlier RFCs 2133 & 2553)
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 36 of 42
4. RFC 3879: Deprecating Site Local Addresses
http://www.ietf.org/rfc/rfc3879.txt
5. RFC 4291: IP Version 6 Addressing Architecture
http://www.ietf.org/rfc/rfc4291.txt
(obsoletes earlier RFCs 1884, 2373 & 3513)
6. Current information about Microsoft’s plans for IPv6.
http://www.microsoft.com/technet/itsolutions/network/ipv6/default.mspx
a. Introduction to IPv6 (Microsoft) - IPv6.doc
7. Good discussion on choosing source and destination addresses (re. RFC 3484)
http://www.microsoft.com/technet/community/columns/cableguy/cg0206.mspx
8. MS IPv6 Guide for Windows Sockets Applications
http://msdn.microsoft.com/library/default.asp?url=/library/enus/winsock/winsock/ipv6_guide_for_windows_sockets_applications_2.asp
9. Java IPv6 support
http://java.sun.com/j2se/1.4.2/docs/guide/net/ipv6_guide/
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 37 of 42
5 IMPACT SUMMARY
5.1 PRODUCT/COMPONENT IMPACTS
5.1.1
Entities
Entity
New
Modified
Comments
Tool
Commands
Messages
Help
Modules
5.2 DOCUMENTATION
MANUAL
Release Notes
Connectivity Guide
Migration Guide
IMPACT
A comment indicating that IPv6
support has been added and
perhaps a sentence or two
about the benefits of IPv6 (larger
address space for instance).
1. Some examples of IPv6
formatted addresses (colon
separated hex values). 2. New
configuration parameter to
restrict protocol driver to IPv4 or
IPv6 only addresses.
TBD: Is it worthwhile mentioning
that migration to IPv6 should be
transparent?
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 38 of 42
6 QUALITY ISSUES
6.1 UNIT TESTING SUMMARY
Testing of all IPv6 / IPv4 combinations across several platforms.
Ensure all Network Configuration utilities allow entry and display of IPv6 style
addresses.
Ensure all displays of IP addresses will accommodate the new formats and
multiple addresses; offhand, I’m not aware of any changes needed in this area.
6.2 TESTING RECOMMENDATIONS
Testing of various IPv6 / IPv4 combinations across several platforms and
versions of Ingres (some that do support IPv6 and some that don’t). The
following is a full list of combinations that could/should be tested:
Ingres Client
----------------------------------------------
=>
Ingres Server
-----------------------------------------------
OS IPv6 capable, Ingres IPv6 capable => OS IPv6 capable, Ingres IPv6 capable
OS IPv6 incapble, Ingres IPv6 capable => OS IPv6 capable, Ingres IPv6 capable
OS IPv6 capable, Ingres IPv6 incapble => OS IPv6 capable, Ingres IPv6 capable
OS IPv6 incapble, Ingres IPv6 incapble => OS IPv6 capable, Ingres IPv6 capable
OS IPv6 capable, Ingres IPv6 capable => OS IPv6 incapble, Ingres IPv6 capable
OS IPv6 incapble, Ingres IPv6 capable => OS IPv6 incapble, Ingres IPv6 capable
OS IPv6 capable, Ingres IPv6 incapble => OS IPv6 incapble, Ingres IPv6 capable
OS IPv6 incapble, Ingres IPv6 incapble => OS IPv6 incapble, Ingres IPv6 capable
OS IPv6 capable, Ingres IPv6 capable => OS IPv6 capable, Ingres IPv6 incapble
OS IPv6 incapble, Ingres IPv6 capable => OS IPv6 capable, Ingres IPv6 incapble
OS IPv6 capable, Ingres IPv6 incapble => OS IPv6 capable, Ingres IPv6 incapble *
OS IPv6 incapble, Ingres IPv6 incapble => OS IPv6 capable, Ingres IPv6 incapble *
OS IPv6 capable, Ingres IPv6 capable => OS IPv6 incapble, Ingres IPv6 incapble
OS IPv6 incapble, Ingres IPv6 capable => OS IPv6 incapble, Ingres IPv6 incapble
OS IPv6 capable, Ingres IPv6 incapble => OS IPv6 incapble, Ingres IPv6 incapble *
OS IPv6 incapble, Ingres IPv6 incapble => OS IPv6 incapble, Ingres IPv6 incapble *
where “OS” means “operating system” and “Ingres IPv6 incapble” would be a
prior release of Ingres that does not have IPv6 support. The items marked with
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 39 of 42
an asterisk (*) would not need to be tested with an older version of Ingres
because that would merely be testing prior versions. Instead, these should be
tested with at least one side of the test being the new Ingres with IPv6 support,
but disabled (via config.dat).
Ingres/Net SEP tests…if such a thing exists…to ensure connectivity is not
broken. On Linux and Unix, all regression tests will be exercising the new code
because the local IPC uses TCP/IP by default.
6.3 REGRESSION RISK ASSESSMENT
Verify that connections can still be made and that connection performance is
adequate. Although less likely to be a problem, query performance across
Ingres/Net should be checked: many short queries, queries that return large
result sets, plus some high concurrency tests.
On Unix and Linux, due to the use of TCP/IP as the local IPC, the introduction of
IPv6 support has the potential to break or slow performance for all GCA
communications between processes. This should be tested carefully! If
instability or slower performance occurs with the new driver where II_GC_PROT
is defaulted to TCP_IP, then the default should be changed to TCP_IPv4.
6.3.1
Backward Compatibility Issues
New Ingres installations that support IPv6 must continue to be able to support
older releases that don’t (across Ingres/Net).
Applications on Unix and Linux that are statically linked with the Ingres local IPC
TCP/IP protocol driver (in the Ingres compatibility library) should continue to work
when the installation is upgraded with an Ingres/Net and/or DBMS that supports
IPv6.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 40 of 42
7 PACKAGING AND INSTALLATION IMPACT
N/A
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 41 of 42
8 SUPPORT IMPACT
Support will need to have some familiarity with IPv6, such as how to enable it on
Windows, new address formats, the concept of dual IPv4/IPv6 and multiple
addresses, and of course how to configure in Ingres.
106755096
INGRES CONFIDENTIAL AND PROPRIETARY INFORMATION FOR INTERNAL USE ONLY.
Page 42 of 42