I've been at the UNH IOL (inter operability lab)
Since Monday morning going through the IPV6 Ready Phase II Logo test.
We should finish the first pass through the test late Today or Early Friday.
The rules of the test are such that you can't change the code during the test and have it still be valid.
Since we have been fixing bugs as we find them and retesting failures, the results of this first test will
not be valid to claim the IPV6 Ready logo.
Most of the bugs have been of the form of "you sent me deformed packet X" do I reject it completely or ignore the error.
Some you reject, some you ignore, deciding what is what from the RFC is difficult at best.
A few of the bugs would have had real impact...looking for Source Link options while packet has Target Link options...
(There are two different almost identical options for sending the ethernet MAC address)
I expect to be back in the office on Dec 1st and to spend at least two weeks finishing the programmers interface into this code and
packaging a beta of the IPV6 code. When that is done I will probably go back to NH to redo the test from start to finish with
one set of code. So beta available by end of year, and a Logo test Passed version of the code should be in Q1 15.
Paul
IPV6 and Update...
Re: IPV6 and Update...
We now have a code set that has passed all of the IPV6 Ready Phase II and USGv6 tests.
The tests take about 3 days and a fair number of the results are scored by human interaction.
We have been editing the code to fix errors as we find things we did not pass, so the result is not official
until we pass the test with zero changes.
This does not presently include DHCPV6 and Multicast Listener Discovery V2.
IPV6 Autoconfig and router advertisements do 90% of what DHCP does for IPV4 sites so
not having DHCPv6 is not as big a deal as one might think.
Our Plans going forward are as follows:
Cleanup the code that has passed (IE remove diagnostics and reorganize a little bit.)
Finish some features that were not required to pass the test (switching between v4/v6 depending on address entered, DNS etc..)
Package this code for a Beta Release. (Around end of December)
Add the simplified two message DHCP for DNS and NTP servers. This is part of the DHCPV6 specification.
(This won't pass all the DHCP6 Logo tests but should make the system fully functional)
Add simplified Multicast neighbor discovery join for IPV6 required packets.
IPV6 uses multicast rather than broad cast to do arp like functions. As a result if you
are doing IPV6 on the output of a switch that does multicast filtering you may miss packets
you should see unless you do the router multicast discovery dance.... doing the whole multicast spec
with source specific multicast joins/leaves is really complicated and there is a IPV6 multicast light RFC
in process. We intend to do multicast light.
Once we have done these things we will go back to NH and rerun the IOL Logo tests.
I expect to have this in Q1 2015.
If you have a need for IPV6 features not discussed here, please let us know what is needed.
Does anyone out there need IPSec (with/without IKEv2)?
The tests take about 3 days and a fair number of the results are scored by human interaction.
We have been editing the code to fix errors as we find things we did not pass, so the result is not official
until we pass the test with zero changes.
This does not presently include DHCPV6 and Multicast Listener Discovery V2.
IPV6 Autoconfig and router advertisements do 90% of what DHCP does for IPV4 sites so
not having DHCPv6 is not as big a deal as one might think.
Our Plans going forward are as follows:
Cleanup the code that has passed (IE remove diagnostics and reorganize a little bit.)
Finish some features that were not required to pass the test (switching between v4/v6 depending on address entered, DNS etc..)
Package this code for a Beta Release. (Around end of December)
Add the simplified two message DHCP for DNS and NTP servers. This is part of the DHCPV6 specification.
(This won't pass all the DHCP6 Logo tests but should make the system fully functional)
Add simplified Multicast neighbor discovery join for IPV6 required packets.
IPV6 uses multicast rather than broad cast to do arp like functions. As a result if you
are doing IPV6 on the output of a switch that does multicast filtering you may miss packets
you should see unless you do the router multicast discovery dance.... doing the whole multicast spec
with source specific multicast joins/leaves is really complicated and there is a IPV6 multicast light RFC
in process. We intend to do multicast light.
Once we have done these things we will go back to NH and rerun the IOL Logo tests.
I expect to have this in Q1 2015.
If you have a need for IPV6 features not discussed here, please let us know what is needed.
Does anyone out there need IPSec (with/without IKEv2)?