hat tip to .gov hostmasters

Date: Mon, 22 Sep 2008 11:42:33 -0400
From: "Goltz, Jim (NIH/CIT) [E]" <jgoltz@mail.nih.gov>

> nice to see a wholesale DNSSEC rollout underway (I must confess to
> being a little surprised at the source, too!). Granted, it's a much
> more manageable problem set than, say, .com - but if one US-controlled
> TLD can do it, hope is buoyed for a .com rollout sooner rather than
> later (although probably not much sooner :)).

It ain't done yet.

I don't speak for the hostmasters of .gov or any subdomain thereof.
But I'll believe it when I see it.

I am pretty sure that you will see it. Unlike things like the IPv6
requirement, there are no waivers available for this. '.gov' must be
signed early next year and all zones delegated from the '.gov' GTLD must
be signed in early 2010. I doubt that many will sign until '.gov' is
signed, so you won't see much change for a few months.

Now, if the DOC people responsible for root would just catch a clue, we
could get that signed and have DNSSEC actually usable (except for
Mr. Metcalf) in a significant part of the US network before I retire.

Remember, they've also "mandated" IPv6 support on all backbones.

Yes, and the goal, relatively insignificant that it was, was met. It was
not a requirement that anyone actually use IPv6, only that the agency
backbone networks be able to carry IPv6. In fact, the wording was such
that doing proper routing was not even really needed.

Our backbone has offered IPv6 as a production service since 2002, so it
was a non-effort for us. Most other agency backbones were pretty trivial
to make "IPv6 capable".

The problem is that only the backbone currently needs IPv6. No facility
network or end host needs it, No network service needs it. No IPv6
packets, even routing updates, need to be delivered in any useful
way. It was a pretty trivial goal and was met with very little effort.

Kevin Oberman wrote:

Date: Mon, 22 Sep 2008 11:42:33 -0400
From: "Goltz, Jim (NIH/CIT) [E]" <jgoltz@mail.nih.gov>
    Remember, they've also "mandated" IPv6 support on all backbones.
    
Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed.

Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make "IPv6 capable".

The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort.
  
They mandated that all products, not just hardware, support IPv6. However, all that the requirement turned out to be, in practice, is that all products be "software upgradeable" to IPv6. My employer is still selling stuff by the truckload to the USG because the hardware itself is "IPv6 capable" (just like it's OSI or DECnet "capable"), but we haven't written a single line of IPv6 code yet because customers aren't actually demanding it and we have other, more profitable, things to spend developers' limited time on.

For vendors whose hardware needs to change for IPv4, like core routers, this is a big deal; for the rest of us, it was a non-event once we read the fine print.

S

To digress on IPv6 momentarily.

The airline magazine engineering memorandum* from OMB left two terms
undefined in the mandate; "backbone network" and "IPv6 compatible." The
Intra-agency IPv6 Federal Working Group wisely defined "backbone
network" as (paraphrasing) the wire exiting the first publicly-reachable
network perimeter router and entering the router next in the line of
traffic and all devices attached to that wire between those two points
as follows:

{Internet}->|router|<-connecting wire---IPV6-[firewall, IDS,
etc.]-IPV6--connecting wire->|next router in line|->NO IPV6-----...

NIST is still working on "compatible."

*Airline Magazine Engineering Memorandum: a mandate issued by an
executive who can. The memorandum has four characteristics; 1) It
mandates a technology not well understood by either the issuer or the
recipient of the memo, 2) it sets a date certain by which the technology
must be implemented, 3) it provides no funding, and 4, it contains one
or more undefined terms whose exact meanings are absolutely crucial to
actual implementation of the mandate. Source of the inspiration that
originally convinced the issuing executive that they actually understood
the scope and technology of the mandate is inherent in the title of this
paragraph.

JimL
James R Lindley
Senior Computer Engineer
Advanced Technical Analysis Team
IT Security Architecture and Engineering
Internal Revenue Service
An unquenchable thirst for Pierian waters.