Attachment 91219 Details for Bug 165409 – IPv6 Implementation

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

IPv6 Implementation

IPv6-Implementation.html (text/html), 8.07 KB, created by Jonathan West

on 2008-02-29 13:35:13 EST

(hide)

Description:

Filename:

MIME Type:

Creator: Jonathan West

Created: 2008-02-29 13:35:13 EST

Size: 8.07 KB

patch

obsolete

><html>
>
> <head>
> <title>IPv6 Transition Implementation (Draft)</title>
> <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
> <link rel="stylesheet" type="text/css" href="http://www.eclipse.org/tptp/eclipse_style.css" > 
>
> </head>
>
><body link="#0000FF" vlink="#7777FF">
>
><div align="center"><h1>IPv6 Transition Implementation Draft</h1></div>
>
> 
>
><h2>Implementation Stages</h2>
>
>Stage 1: 
><ul>
> <li>Discuss and agree to the native changes required to our code. As a basis
>for this discussion, I would suggest the list of changes pulled
>together from Microsoft's IPv6 scan tool, the division of tasks 
>lists (below), as well as the Linux and Windows sample code.</li>
> <li>Investigate the build changes that will be required for
>this. My Visual C++ 6 (the latest service release) does not seem to
>include support for IPv6, and it's unclear to whether this is true in
>general. This suggests that Intel might need to move our native build
>environment to VS2k3 in order to support IPv6.</li>
></ul>
> 
>Stage 2: 
><ul>
> <li>Deploy build environment changes (if needed) to support
>IPv6 that were identified in stage 1.</li>
> <li>Smoke test AC w/ updated build environment (if needed).</li>
> <li>Rewrite native/Java socket code to move it from using IPv4-only
>API, to using IPv4/IPv6 agnostic API code (e.g. using sockaddr_storage
>rather than sockaddr_in, using getnameinfo/getaddrinfo rather than
>gethostbyname/gethostbyaddr, etc). However, only the function calls
>should change: at this stage, we should not implement any changes to
>the code that are not merely API translations + simple changes to
>support those translations.</li>
></ul>
><ul>
> <li>Investigate which IPv4/IPv6 equipment combinations we need
>to support.</li>
> <li>Investigate network equipment for testing.</li>
></ul>
><ul>
> <li>Developers begin investigating their code and note any IPv6
>changes that require more than just API translation + simple changes
>(e.g.&nbsp; changes to code logic, rather than merely changes to
>code form. For instance, adding additional XML commands to
>support&nbsp; changed IP address formats, updating existing XML
>commands, adding additional Hyades commands to the Hyades protocol to
>support IP addresses of more than 4 byte, etc.). However as noted, they
>should not begin making these changes until stage 4.</li>
></ul>
> 
><ul>
> <li>At the end of this stage we should have an updated and
>working AC that uses the IPv4/IPv6 agnostic socket API code only.</li>
></ul>
> 
>Stage 3: 
><ul>
> <li>Test updated AC w/ our standard test environment to ensure
>it continues to work w/ the updated socket code (that is, with the
>IPv4-&gt;IPv6 API translation changes.)</li>
> <li>Test IPv4 functionality with updated AC on two dual
>stack windows machines.</li>
> <li>Deploy network equipment for IPv6.</li>
></ul>
> 
><ul><li>At the end of this stage we should have tested the AC, and have fixed any identified bugs.</li></ul>
> 
>Stage 4: 
><ul>
> <li>Developers implement remaining changes in the code, that is, the the tasks identified in stage 1 that were larger than merely API translation. </li>
></ul>
> 
><ul><li>At the end of this stage IPv6 code changes should be complete.</li></ul>
>
> 
>Stage 5: 
><ul>
> <li>Test final AC w/ dual IPv4/IPV6 (confirmed to work during
>stage 3).</li>
> <li>Test final AC w/ the expected support IPv4/IPv6
>combinations that were identified in stage 1.</li>
></ul>
> 
><ul><li>Final Release.</li></ul>
>
>
> 
>
> 
>
>
><h2>IPv6 Native Code Changes</h2>
>I've amalgamated and summarized the results of running Microsoft's IPv6
>scan on our source. For details, see the scan results that I've
>included in the ZIP file, and the sample Windows/Linux code. 
> 
>Microsoft's recommendations are: 
><ul>
> <li>Replace sockaddr_in with sockaddr_storage</li>
> <li>Replace inet_addr with getaddrinfo(...). (using the
>AI_NUMERICHOST constant. See sample code)</li>
> <li>Replace gethostbyname with getaddrinfo</li>
> <ul>
> <li>Replace hostent with addrinfo</li>
> </ul>
> <li>Replace AF_INET with code that checks both AF_INET and
>AF_INET6. See MS/Linux code for details.</li>
> <li>Replace in_addr with code that checks both in_addr and
>in6_addr. </li>
> <li>Replace inet_ntoa(..) with getnameinfo (with NI_NUMERICHOST
>flag, which is cross-platform)</li>
> <li>Replace gethostbyaddr with getnameinfo (with NI_NUMERICHOST
>flag)</li>
> <li>Replace INADDR_ANY, "use getaddrinfo with nodename=NULL and
>AI_PASSIVE instead"</li>
></ul>
> 
>All of the recommendations above use ANSI C API, and thus should work
>on both Linux and Windows without platform-specific #ifdefs. The sample
>code I've included follows these guidelines for both Linux and Windows,
>however, the code uses platform-specific references in a few places
>that would need to be #ifdef-ed/replaced. 
> 
>
>
><h2>Division of Tasks (Java)</h2>
>
>Generally, Intel will transition the Java Execution Framework code (org.eclipse.tptp.platform.execution), and IBM will transition the Java Hyades code (org.eclipse.hyades.execution) as well as the TPTP GUI code.
>
>
>
><h2>Division of Tasks (C/C++)</h2>
>
>Generally, for other projects not listed below, Intel will transition the native TPTP AC code, and IBM will transition the native Hyades AC code (including Client Compatibility Layer). 
> 
>Of the files listed by the IPv6 scan, Intel would make changes to the following projects (and all supporting projects):
> 
> 
>transportSupport:
><ul>
><li>TransportSupportSocket.c, TransportSupport.c, TransportOSCalls_win.c, TransportOSCalls_linux.c</li>
></ul>
>
>socketTL:
><ul>
><li>SocketListener.c</li>
></ul>
>
>TPTPLogUtils:
><ul>
><li>TPTPCBE.cpp</li>
></ul>
>
>client:
><ul>
><li>TPTP_INetAddress.cpp</li>
><li>TCPDataServer.cpp</li>
><li>ConnectionImpl.cpp</li>
></ul>
>
>(And the various include files for the above that are in \include\tptp) 
> 
> 
>Of the files listed by the IPv6 scan, IBM would make changes to the following projects (and all supporting projects):
> 
> 
>TPTPClientCompTL:
><ul>
><li>ClientCTL.c</li>
><li>nativeFileServer.c</li>
></ul>
>
>RASocket
><ul>
><li>RASocket.c</li>
></ul>
>
>Across Multiple Projects:
><ul>
><li>
>Additional changes required to support IPv6 with the addition of new Hyades binary commands. 
></li>
></ul>
> 
>(And the various include files for the above that are in \include\tptp)
> 
> 
><h2>Reference URLs</h2>
> 
>Here are some excellent IPv6 resources for Java, C, Linux and Windows.
> 
> 
>IPv6 Guide for Windows Socket Applications 
>(<a href="http://msdn2.microsoft.com/en-us/library/ms738649.aspx">http://msdn2.microsoft.com/en-us/library/ms738649.aspx</a>) 
> 
>IPv6 for Microsoft Windows: Frequently Asked Questions 
>(<a href="http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx">http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx</a>) 
> 
>Sample Windows C code for an IPv4/IPv6 agnostic client/server 
>(<a href="http://msdn2.microsoft.com/en-us/library/ms737535(VS.85).aspx">http://msdn2.microsoft.com/en-us/library/ms737535(VS.85).aspx</a>) 
> 
> 
>Linux IPv6 HOWTO 
>(<a href="http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Linux+IPv6-HOWTO.html#AEN384">http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Linux+IPv6-HOWTO.html#AEN384</a>) 
> 
> 
>Porting applications to IPv6 HowTo 
>(<a href="http://jungla.dit.upm.es/~ecastro/IPv6-web/ipv6.html">http://jungla.dit.upm.es/~ecastro/IPv6-web/ipv6.html</a>)
> 
> 
>Java Networking IPv6 Guide 
>(<a href="http://java.sun.com/j2se/1.5.0/docs/guide/net/ipv6_guide/index.html">http://java.sun.com/j2se/1.5.0/docs/guide/net/ipv6_guide/index.html</a>) 
>
>
>
></body>
>
></html>

<html>

  <head>
    <title>IPv6 Transition Implementation (Draft)</title>
    <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
    <link rel="stylesheet" type="text/css" href="http://www.eclipse.org/tptp/eclipse_style.css" >   

  </head>

<body link="#0000FF" vlink="#7777FF">

<div align="center"><h1><u>IPv6 Transition Implementation <i>Draft</i></u></h1></div>

<br>

<h2><u>Implementation Stages</u></h2>

<span style="font-weight: bold;">Stage 1</span>:<br>
<ul>
  <li>Discuss and agree to the native changes required to our code. As a basis
for this discussion, I would suggest the list of changes pulled
together from Microsoft's IPv6 scan tool, the division of tasks 
lists (below), as well as the Linux and Windows sample code.</li>
  <li>Investigate the build changes that will be required for
this. My Visual C++ 6 (the latest service release) does not seem to
include support for IPv6, and it's unclear to whether this is true in
general. This suggests that Intel might need to move our native build
environment to VS2k3 in order to support IPv6.</li>
</ul>
<br>
<span style="font-weight: bold;">Stage 2</span>:<br>
<ul>
  <li>Deploy build environment changes (if needed) to support
IPv6 that were identified in stage 1.</li>
  <li>Smoke test AC w/ updated build environment (if needed).</li>
  <li>Rewrite native/Java socket code to move it from using IPv4-only
API, to using IPv4/IPv6 agnostic API code (e.g. using sockaddr_storage
rather than sockaddr_in, using getnameinfo/getaddrinfo rather than
gethostbyname/gethostbyaddr, etc). However, only the function calls
should change: at this stage, we should not implement any changes to
the code that are not merely API translations + simple changes to
support those translations.</li>
</ul>
<ul>
  <li>Investigate which IPv4/IPv6 equipment combinations we need
to support.</li>
  <li>Investigate network equipment for testing.</li>
</ul>
<ul>
  <li>Developers begin investigating their code and note any IPv6
changes that require more than just API translation + simple changes
(e.g.&nbsp; changes to code logic, rather than merely changes to
code form. For instance, adding additional XML commands to
support&nbsp; changed IP address formats, updating existing XML
commands, adding additional Hyades commands to the Hyades protocol to
support IP addresses of more than 4 byte, etc.). However as noted, they
should not begin making these changes until stage 4.</li>
</ul>
<br>
<ul>
  <li>At the end of this stage we should have an updated and
working AC that uses the IPv4/IPv6 agnostic socket API code only.</li>
</ul>
<br>
<span style="font-weight: bold;">Stage 3</span>:<br>
<ul>
  <li>Test updated AC w/ our standard test environment to ensure
it continues to work w/ the updated socket code (that is, with the
IPv4-&gt;IPv6 API translation changes.)</li>
  <li>Test IPv4 functionality with updated AC on two dual
stack windows machines.</li>
  <li>Deploy network equipment for IPv6.</li>
</ul>
<br>
<ul><li>At the end of this stage we should have tested the AC, and have fixed any identified bugs.</li></ul>
<br>
<span style="font-weight: bold;">Stage 4</span>:<br>
<ul>
  <li>Developers implement remaining changes in the code, that is, the the tasks identified in stage 1 that were larger than merely API translation. </li>
</ul>
<br>
<ul><li>At the end of this stage IPv6 code changes should be complete.</li></ul>

<br>
<span style="font-weight: bold;">Stage 5</span>:<br>
<ul>
  <li>Test final AC w/ dual IPv4/IPV6 (confirmed to work during
stage 3).</li>
  <li>Test final AC w/ the expected support IPv4/IPv6
combinations that were identified in stage 1.</li>
</ul>
<br>
<ul><li>Final Release.</li></ul>


<br>

<br>


<h2><u>IPv6 Native Code Changes</u></h2>
I've amalgamated and summarized the results of running Microsoft's IPv6
scan on our source. For details, see the scan results that I've
included in the ZIP file, and the sample Windows/Linux code. <br>
<br>
Microsoft's recommendations are: <br>
<ul>
  <li>Replace sockaddr_in with sockaddr_storage</li>
  <li>Replace inet_addr with getaddrinfo(...). (using the
AI_NUMERICHOST constant. See sample code)</li>
  <li>Replace gethostbyname with getaddrinfo</li>
  <ul>
    <li>Replace hostent with addrinfo</li>
  </ul>
  <li>Replace AF_INET with code that checks both AF_INET and
AF_INET6. See MS/Linux code for details.</li>
  <li>Replace in_addr with code that checks both in_addr and
in6_addr. </li>
  <li>Replace inet_ntoa(..) with getnameinfo (with NI_NUMERICHOST
flag, which is cross-platform)</li>
  <li>Replace gethostbyaddr with getnameinfo (with NI_NUMERICHOST
flag)</li>
  <li>Replace INADDR_ANY, "use getaddrinfo with nodename=NULL and
AI_PASSIVE instead"</li>
</ul>
<br>
All of the recommendations above use ANSI C API, and thus should work
on both Linux and Windows without platform-specific #ifdefs. The sample
code I've included follows these guidelines for both Linux and Windows,
however, the code uses platform-specific references in a few places
that would need to be #ifdef-ed/replaced.<br>
<br>


<h2><u>Division of Tasks (Java)</u></h2>

Generally, Intel will transition the Java Execution Framework code (org.eclipse.tptp.platform.execution), and IBM will transition the Java Hyades code (org.eclipse.hyades.execution) as well as the TPTP GUI code.



<h2><u>Division of Tasks (C/C++)</u></h2>

Generally, for other projects not listed below, Intel will transition the native TPTP AC code, and IBM will transition the native Hyades AC code (including Client Compatibility Layer).<br>
<br>
Of the files listed by the IPv6 scan, Intel would make changes to the following projects (and all supporting projects):
<br>
<br>
<b>transportSupport</b>:
<ul>
<li>TransportSupportSocket.c, TransportSupport.c, TransportOSCalls_win.c, TransportOSCalls_linux.c</li>
</ul>

<b>socketTL</b>:
<ul>
<li>SocketListener.c</li>
</ul>

<b>TPTPLogUtils:</b>
<ul>
<li>TPTPCBE.cpp</li>
</ul>

<b>client:</b>
<ul>
<li>TPTP_INetAddress.cpp</li>
<li>TCPDataServer.cpp</li>
<li>ConnectionImpl.cpp</li>
</ul>

(And the various include files for the above that are in \include\tptp)<br>
<br>
<br>
Of the files listed by the IPv6 scan, IBM would make changes to the following projects (and all supporting projects):
<br>
<br>
<b>TPTPClientCompTL:</b>
<ul>
<li>ClientCTL.c</li>
<li>nativeFileServer.c</li>
</ul>

<b>RASocket</b>
<ul>
<li>RASocket.c</li>
</ul>

<b>Across Multiple Projects:</b>
<ul>
<li>
Additional changes required to support IPv6 with the addition of new Hyades binary commands. 
</li>
</ul>
<br>
(And the various include files for the above that are in \include\tptp)
<br>
<br>
<h2><u>Reference URLs</u></h2>
<br>
Here are some excellent IPv6 resources for Java, C, Linux and Windows.
<br>
<br>
<b>IPv6 Guide for Windows Socket Applications</b><br>
(<a href="http://msdn2.microsoft.com/en-us/library/ms738649.aspx">http://msdn2.microsoft.com/en-us/library/ms738649.aspx</a>)<br>
<br>
<b>IPv6 for Microsoft Windows: Frequently Asked Questions</b><br>
(<a href="http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx">http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx</a>)<br>
<br>
<b>Sample Windows C code for an IPv4/IPv6 agnostic client/server</b><br>
(<a href="http://msdn2.microsoft.com/en-us/library/ms737535(VS.85).aspx">http://msdn2.microsoft.com/en-us/library/ms737535(VS.85).aspx</a>)<br>
<br>
<br>
<b>Linux IPv6 HOWTO</b><br>
(<a href="http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Linux+IPv6-HOWTO.html#AEN384">http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Linux+IPv6-HOWTO.html#AEN384</a>)<br>
<br>
<br>
<b>Porting applications to IPv6 HowTo</b><br>
(<a href="http://jungla.dit.upm.es/~ecastro/IPv6-web/ipv6.html">http://jungla.dit.upm.es/~ecastro/IPv6-web/ipv6.html</a>)
<br>
<br>
<b>Java Networking IPv6 Guide</b><br>
(<a href="http://java.sun.com/j2se/1.5.0/docs/guide/net/ipv6_guide/index.html">http://java.sun.com/j2se/1.5.0/docs/guide/net/ipv6_guide/index.html</a>)<br>



</body>

</html>

Actions: View

Attachments on bug 165409: 80048 | 91219 | 91220 | 92067 | 96037 | 96378 | 96379 | 99618 | 99619 | 99622 | 99735