My ISP uses carrier-grade NAT which means I do not have an IPv4 address to use. However, my device has an IPv6 address. I have been told that golem should work properly over IPv6, but that I will likely only be able to connect to peers that have also enabled IPv6. Also, despite the fact that my IPv4 connection isn't working properly, the client continues to try to connect to IPv4 addresses.
Description
Suggestions:
enable IPv6 by default.
allow IPv4 to be disabled.
A more elegant solution might be to have the client autodetect which stack to use, e.g. try to connect to IPv4 and IPv6 when client is first started, but if all connections from one stack are failing, disable that stack.
User Interface
Are user-facing changes required for this functionality?
Despite my IPv6 connection working properly, the gui still reports "problem with ports". This check should be reworked to display the status of both stacks.
Technical specification
According to golem team members, "IPv6 is supported in the network module, but there may be problems on the way (with display, further checks, ports etc.)"
Dependencies
Enumerate other issues the completion of which is critical for this feature to be finished - or which block this feature from progressing with implementation
Sub-components
Define and add links to sub-components
?
?
Blockers
For any issues that block this issue, add links
?
?
Additional tests
Enumerate any additional unit and/or integration tests that need to be added for this feature to be covered
additional unit tests?
additional integration tests?
QA
Description of the QA process for the feature
Test scenarios:
Base test process
specify one of: ( if unsure, consult @ZmijaWA or @ederenn ) QA limited to the single feature (in case of very trivial changes)
Smoke Test (the limited set of tests designed to ensure that most critical functionality doesn't experience regressions)
** Full Test (full set of tests for the whole application - in case of more extensive application updates, refactoring etc)
New feature tests
Add test scenarios for the new feature
Positive Scenario 1
Step 1
Step 2
...
Expected results
Positive Scenario 2
...
Negative Scenario 1
Step 1
Step 2
...
Some expected problem
Expected problem handling
Possible regressions
is there any functionality that is likely to experience regressions?
are there any existing application components that should be tested more thoroughly?
Progress
Development
[ ] Feature implemented
[ ] Feature unit/integration tests implemented
Dev QA
[ ] Basic tests by the developer pass
[ ] Unit tests pass
[ ] Golem integration tests pass
[ ] Concent integration tests pass
[ ] Concent acceptance tests pass
Please choose the priority label for QA. It is set to the lowest by default. To setup higher priority please change the labelP0 label is set for Severity-Critical/Effort-easy
P1 label is set for Severity-Critical/Effort-hard
P2 label is set for Severity-Low/ Effort-easy
P3 label is set for Severity-Low/Effort-hard
QA team
[ ] Base scenario passes
[ ] Additional test 1 passes...
[ ] ...
Issues encountered during QA
When adding an issue here, please update testing scenarios and QA progress above
Rationale
My ISP uses carrier-grade NAT which means I do not have an IPv4 address to use. However, my device has an IPv6 address. I have been told that golem should work properly over IPv6, but that I will likely only be able to connect to peers that have also enabled IPv6. Also, despite the fact that my IPv4 connection isn't working properly, the client continues to try to connect to IPv4 addresses.
Description
Suggestions:
A more elegant solution might be to have the client autodetect which stack to use, e.g. try to connect to IPv4 and IPv6 when client is first started, but if all connections from one stack are failing, disable that stack.
User Interface
Are user-facing changes required for this functionality?
Technical specification
According to golem team members, "IPv6 is supported in the network module, but there may be problems on the way (with display, further checks, ports etc.)"
Dependencies
Enumerate other issues the completion of which is critical for this feature to be finished - or which block this feature from progressing with implementation
Sub-components
Define and add links to sub-components
Blockers
For any issues that block this issue, add links
Additional tests
Enumerate any additional unit and/or integration tests that need to be added for this feature to be covered
QA
Description of the QA process for the feature
Test scenarios:
Base test process
specify one of: ( if unsure, consult @ZmijaWA or @ederenn ) QA limited to the single feature (in case of very trivial changes) Smoke Test (the limited set of tests designed to ensure that most critical functionality doesn't experience regressions) ** Full Test (full set of tests for the whole application - in case of more extensive application updates, refactoring etc)
New feature tests
Add test scenarios for the new feature
Positive Scenario 1
Positive Scenario 2
Negative Scenario 1
Possible regressions
Progress
Development
Dev QA
Please choose the priority label for QA. It is set to the lowest by default. To setup higher priority please change the label P0 label is set for Severity-Critical/Effort-easy P1 label is set for Severity-Critical/Effort-hard P2 label is set for Severity-Low/ Effort-easy P3 label is set for Severity-Low/Effort-hard
QA team
Issues encountered during QA
When adding an issue here, please update testing scenarios and QA progress above