Bugzilla – Full Text Bug Listing
| Summary: | (Test) IPv6 support in URL Test HTTP Recorder | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Mark D Dunn <mddunn> |
| Component: | TPTP | Assignee: | DuWayne Morris <dmorris> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P1 | CC: | dmorris, jkubasta, paulslau |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 212564, 212580 | ||
| Bug Blocks: | 165409 | ||
|
Description
Mark D Dunn
Put target milestone of 4.1 i3. modified target to 4.2. We do not have the network setup to test this yet. Moved to future until consuming product needs this. Added estimate. I have written the code to use ipv6, but have not tested it yet due to lack of ipv6 network. It may not take this long to complete if all goes well. Targeting to future since not containable in 4.4. As discussed on this week's Test Project call (January 22, 2007), the Test Project will focus on existing P1 - P2/Blocker - Major and P1/Normal and test creation/automation defects (omitting defects dependant on outstanding features) in TPTP 4.4. All other Test Project defects have been targeted to future. If this defect has been targeted to future and you/originator feel it should be completed in 4.4, please provide the necessary reason as a reply to this comment or a post to the Test Project mailing list (tptp-test-tooling-dev@eclipse.org). We will collectively triage and assess our resources to determine a case-by-case decision. As discussed on this week's Test Project call (January 22, 2007), the Test Project will focus on existing P1 - P2/Blocker - Major and P1/Normal and test creation/automation defects (omitting defects dependant on outstanding features) in TPTP 4.4. All other Test Project defects have been targeted to future. If this defect has been targeted to future and you/originator feel it should be completed in 4.4, please provide the necessary reason as a reply to this comment or a post to the Test Project mailing list (tptp-test-tooling-dev@eclipse.org). We will collectively triage and assess our resources to determine a case-by-case decision. Correction: The Test Project mailing list is tptp-testing-tools-dev@eclipse.org. Marking IPv6 support as a 4.5 enhancement so this defect fix would also be needed. (In reply to comment #4) > Added estimate. I have written the code to use ipv6, but have not tested it > yet due to lack of ipv6 network. It may not take this long to complete if all > goes well. > Mark, can you attach the code? Mark, is there a known problem with using IPv6? If so, what components? There is no known problem since I do not yet have an IPv6 network to test with. However, I suspect there will need to be changes in the following areas: HTTP Recorder - when displaying the IPv6 addresses and putting it into .rec file HTTP Playback - handling the IPv6 network addresses HTTP Testgen - possible work needed when getting the IPv6 addresses from .rec file and putting them into the .testsuite HTTP Test Editor - possible problem handling/displaying the IPv6 addresses Agent Controller - Can the RAC handle IPv6 addresses ? Do we need to worry about this? Perhaps it already does this. Also, time will have to be spent setting up a IPv6 network. I don't know of any already set up that we can use. Note: The estimate is only for the coding/testing phase. It does not include network setup time. Updated hours and changed owner to myself from Mark. Found a web site that lists IPV6 web servers: http://www.ipv6.org/v6-www.html If the following environment variable is set true, JVM 1.4.x and higher will transparently use IPV6: System.setProperty("java.net.preferIPv6Addresses", "true"); All of the existing Socket API's can use either IPV4 or IPV6 with no modifications, including InetAddress and InetSocketAddress. The plan is to set this flag before recording starts and before HTTP test execution. Mark has implemented most of the work including the Socks 5 specific code in the recorder. What remains is testing and finding whatever bugs remain. IPV6 is supported in IE 7 and in FireFox 2.0.0.6 and perhaps earlier versions. Supposedly, there is limited support in IE 6 only with DNS, the editor is not able to handle an IPV6 address. Note that brackets are needed when specifying an IPV6 URI. For example, using IPV6 to access the localhost is as follows (showing the syntax to include specified port): http://[::1]:80/default.html On Windows, the IPV6 protocol is available and can be added very easily and quickly to Windows XP. On Vista, IPV6 is installed and is used as the default protocol for TCP/IP. Note that IPV6 protocol stack can handle both IPV6 and IPV4 connections interchangably. Bulk update of the target field to reflect the change in iteration numbers. Status update. There were two significant issues that have arisen with IPV6 support: 1. Internet Explorer 7 supports IPV6 in general. However, I have found no settings for using a SOCKS version 5 proxy server (our recorder). Even when specifying an IPV6 address, IE connects to our proxy recorder using a socks version 4 header. Therefore, since SOCKS version 4 does not support an IPV6 address, I am unable to make Internet Explorer work with IPV6 recording with our Socks proxy recorder. 2. In Firefox, I am able to properly record using IPV6. However, I can only set Firefox to record either IPV6 or IPV4, not both at the same time. If I set Firefox to the localhost IPV4 address (like we have always done) at 127.0.0.1, I can record IPV4 traffic. If I set the proxy to point to the IPV6 localhost address at [::1], I can record IPV6 traffic. It is possible to write an auto-config file for proxy settings that will direct traffic to multiple proxy settings. I am not familiar enough with those capabilities to know whether this can be set to direct traffic based on IP version. What I can do now is finish debugging a couple of minor issues in the SOCKS version 5 code and checkin functionality that allows IPV6 recording by manually changing the proxy settings on FireFox. I have confirmed via a network sniffer and debugging information that the browser does not attempt to connect to the proxy if there is an IP version mismatch between the DNS address lookup results for the requested URI and the proxy setting. I intend to investigate using a proxy configuration file for FireFox to resolve proper routing of all traffic. However, in light of other priorities, I would prefer to defer this action until after the 4.5i4 test pass. If anyone is aware of any documentation that might help solve any of these issues, please let me know. Checked in code to support IPV6. Updated hours worked. Will validate in official build before closing as fixed. Closing as fixed. Validated in the 4.5i4 test pass build. Fixed and verified, closing. |