Lockheed not an ODIN original
I enjoyed your article "ODIN on the home stretch" [FCW, Aug. 30]. Reading it brought back wonderful memories and made me very proud to have been a part of the early years of the Outsourcing Desktop Initiative for NASA (ODIN).
However, the article states, "Six years ago, when NASA turned over responsibility for its desktop computers to Lockheed Martin [Corp.]. ..." This is not correct.
From August 1998 until July 2002, I served as the Goddard Space Flight Center's ODIN project manager. Six years ago, Lockheed Martin was not one of our seven original ODIN contractors. As an agency, we took a phased approach toward the initiative, starting with only two centers.
Goddard was the first, followed immediately by Kennedy Space Center. Each center could choose its ODIN contractor. Six years ago, Goddard began to turn its desktops over to RMS Information Systems Inc. Kennedy began outsourcing under ODIN with OAO Corp. long before OAO's association with Lockheed Martin.
Goddard Space Flight Center
Ignorant about IPv6 transition
I read with dismay the box titled "IPv4 to IPv6: Not a simple migration" accompanying the article about the next-generation Internet Protocol [FCW, Aug. 30]. It's clear that the writer, Brian Robinson, and Bruce Fleming of Verizon Federal Network Systems have little knowledge of the true effort required to transition to Version 6.
I would suggest that you find more knowledgeable personnel such as members of the North American IPv6 Task Force, IPv6 Forum Korea Team, Internet2 or companies that participated in the Moonv6 project — a collaborative IPv6 interoperability and application demonstration — or the Global IPv6 Summit in Korea.
Internet service providers worldwide are adopting IPv6 in record numbers. As usual, the United States is the last to come kicking and screaming to the table.
The direction and course of action taken by the U.S. government are desperate attempts to ensure that this great nation stays on the cutting edge of technology. Printing incorrect information does nothing but confuse a simple issue.
Wrong about IPv4, too
I'm amazed at how much "IPv6: Built for speed" [FCW, Aug. 30] got wrong in two small paragraphs starting with the one that begins, "That means IPv4 has to first divide data packets into fragments. ..."
n Routers only fragment IPv4 datagrams if they won't fit into the Max Transmission Unit (MTU) of the next hop. Routers do not reassemble fragments; the end-system TCP does.
n IPv6 does not fragment. Rather, an end-system implementation probes the network and finds the smallest allowable MTU between itself and the destination. It then uses that as the MTU, obviating fragmentation.
I don't know where your information about IPv4 having variable headers comes from. IPv4 headers have been 24 bytes since RFC 791, in September 1981. If anything, it's the IPv6 headers that are variable. The base header in Version 6 is 40 bytes but can be extended by 20 to 60 more bytes by use of extension headers — RFC 2460. By the way, the extension headers business is the best part of IPv6 that hasn't been retrofitted into Version 4.
Naval Postgraduate School
Get the flag right
While reading your Aug. 23 issue, I noticed on Page 8 you had scanned in a photo backward. This resulted in the American flag being disrespectfully displayed on a soldier's uniform.
I know it's not sewed on that way because those patches are produced with the field of stars in the upper left-hand corner. In the future, I hope you will be more alert to the way your readers will see the American flag.
National Geospatial-Intelligence Agency