If you lose your IPv6 connectivity (or worse, if it's up but not
performing well) you will run into problems with your end users that
have IPv6 enabled because when it's on it is generally tried first.
Since more and more operating systems come with IPv6 enabled by
default, and more and more networks worldwide are enabling it for
their users, this can be a problem.
Essentially, this is exactly why the only box that I have in production
with IPv6 is my own personal server. The production network has internal
IPv6 connectivity, but no DNS AAAA records until I find out how badly my
own gear will react in certain events.
In an ideal world you'll want to be able to monitor your IPv6
connectivity from key points outside your network, and alert $SOMEONE
if it isn't working properly. If it's a prolonged outage you will
probably want to update DNS to withdraw your AAAA records, and at
least to start with you'll want them to have a fairly short TTL when
they are in the zone.
Generally, the zone that I have AAAA and A records for a single name
have five minute TTLs for this purpose.
Although it is not popular with the "IPv6 do or die!" crowd, one
procedure I recommend in the early stages of IPv6 deployment is to set
up nameservers that only listen on IPv6 addresses, and only add the
AAAA records to the zone files on those nameservers. (The AAAA records
for the nameservers will have to be in all zone files of course.) At
least that way you will be sure that the people you serve AAAA records
to have _some_ kind of IPv6 connectivity, and that your end is at
least up before sending your end users there. This is not a foolproof
system because there is not necessarily a 1-to-1 relationship between
the network that the resolver is on and the network the user is on,
but for the vast majority it will be, and it's a lot better when
rolling out to take baby steps till you have found all/most of the
land mines.
While this idea makes a bit of sense, the single most popular OS for the
desktop is Windows XP and will not issue IPv6 DNS queries. While XP runs
IPv6 just fine, all name resolution is over V4, so if people do what you
suggest, they will always use IPv4. You will see traffic from MacOS,
Unix and Vista, but that is a fairly small part of the end-user world.
I agree that the idea makes sense, but also completely understand where
Kevin is coming from. All things considered now, I may end up whipping
up a monitor script to reload BIND with an alternate (IPv4 only) zone
file for the affected domains if I can't ping my IPv6 BGP peer. That
$SOMEONE you mentioned above could be nobody ;)
And I am probably in the "IPv6 do or die!" crowd as I see some really
big problems arising in the next coming few years with IPv4 address
exhaustion and several other things that can only be addressed when a
large portion of the 'eyeballs' are running over IPv6 exclusively. (Dual
stack does not really do much good.)
Unfortunately, there are reasons why I have to be dual stacked, some of
which are beyond my control, and others because I am not overly
confident with the lack of consensus in the IETF regarding transition
yet. I would highly prefer to be dual-stacked at this point, then to
have to perform *any* sort of translation, again, due to lack of
consensus within the IETF.
When an agreed upon standard is created for rock-solid global IPv6
connectivity, I'll be one of the first to hand ARIN back my v4 addresses.
Doug mentioned a great mailing list (that I'm currently on). For those
interested, here are some more:
- [EMAIL PROTECTED]
- [EMAIL PROTECTED]
Thanks for the great feedback.
Steve
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
