Subject: AAAA records to be added for root servers

From: Barbara Roseman <[email-masked]>
Date: Mon, 31 Dec 2007 10:05:55 -0800

apologies for cross-posting...

On 4 February 2008, IANA will add AAAA records for the IPv6 addresses  
of the four root servers whose operators have requested it. A  
technical analysis of inserting IPv6 records into the root has been  
done by a joint working group of ICANN's Root Server System Advisory  
Committee and Security and Stability Advisory Committee, a report of  
which can be found at http://www.icann.org/committees/security/ 
sac018.pdf. Network operators should take whatever steps they feel  
appropriate to prepare for the inclusion of AAAA records in response  
to root queries.

More information will be posted to the IANA web site during January.

Regards,

Barbara Roseman
IANA General OperationsManager
ICANN

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jan 2008 13:33:54 -0500

> apologies for cross-posting...

Which I have deleted on the grounds that most of  those lists
won't let me post anyway.  Feel free to forward if you think it
useful.

> On 4 February 2008, IANA will add AAAA records for the IPv6
> addresses of the four root servers whose operators have
> requested it. A technical analysis of inserting IPv6 records
> into the root has been done by a joint working group of
> ICANN's Root Server System Advisory Committee and Security and
> Stability Advisory Committee, a report of which can be found
> at http://www.icann.org/committees/security/sac018.pdf.
> Network operators should take whatever steps they feel
> appropriate to prepare for the inclusion of AAAA records in
> response to root queries.
>...

While I _strongly_ favor this move, it is often, if not always,
useful to examine the applications that use the DNS as well as
effects on the DNS itself.  Because these changes to the root
are likely to facilitate the use of IPv6-native environments (as
distinguished of IPv6 systems in clearly IPv4 environments, as
the root servers have been to date), they may increase stresses
elsewhere.  Let me take email as an example of why this is
important.  Because there are no mail servers associated with
the root zone (there is not even a way to express a root-zone
email address), there should be no direct effect of these
changes.  But I think your announcement and comments should
anticipate possible indirect effects.

When an email address is specified, the domain is interpreted
for mail-routing purposes according to rules first laid out in
RFC 974, which has been updated in minor ways by RFC 1123 and
RFC 2821.  RFC 974 defined the MX RR.  The data associated with
the MX RR is simply a domain name, so MX records raise no issues
with IPv6.  However, there is also a rule that, if no MX records
are present at a particular node, the mail system looks for an A
RR at the same node and treats it as if its label appeared with
an MX preference of 0.  That default does not apply to AAAA
records, so it is necessary that operators understand that, if
mail systems are to be accessed using IPv6, they MUST have MX
records at the relevant nodes.  In addition, those MX records
should be configured with preferences appropriate to the
connectivity of the servers: expecting SMTP-senders to sort out
the relative appropriateness and priority from mixed IPv4 and
IPv6 addresses at the same preference level is, at best, likely
to be operationally unwise.

Again, there is no specific root server issue in any of this,
but it concerns me that none of the relevant committees or
studies appear to have considered the possible applications
implications of the change.

regards,
     john

---

From: Bill Manning <[email-masked]>
Date: Fri, 4 Jan 2008 12:01:52 -0800

On Fri, Jan 04, 2008 at 01:33:54PM -0500, John C Klensin wrote:
> > requested it. 

> effects on the DNS itself.  

{ SMTP/MX interaction described }

> implications of the change.

	actually, there was on at least two occasions the explicit
	scoping of the consideration to the DNS-specific issues.
	interactions with other applications was ruled out of scope
	regarding the issues of adding what is effectively a new
	address family to the DNS.  The general answer when needing
	to communicate between similar applications that run on
	different address families has traditionally been the application
	layer gateway (ALG) ...  

--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jan 2008 15:46:34 -0500

> 	different address families has traditionally been the
> application 	layer gateway (ALG) ...  

Then, IMO, whoever ruled it out of scope should look for a job
describing large animals by touch and while blindfolded.  If
said large animal responds to inappropriate poking by stomping
on the individual we can make a nomination for the Darwin Awards.

Seriously, a competent SMTP server running in a competent
dual-stack environment should be nearly agnostic about whether
connections are occurring via IPv4 or IPv6.  There are several
server-environment pairs that are that competent.  Most major
contemporary SMTP servers have their origins in multiple
transport environments (not just different address families) and
RFC 821 was explicitly written to recognize and accommodate
multiple transport environments.   If we are now making
decisions about IPv6 deployment that effectively force the use
of an ALG, rather than servers that can handle both
environments, we have taken the fine art of shooting ourselves
in the foot to new heights.

I also note that, even if one ignores "other applications", the
DNS has already recognized email as a special case, with its
own, applications-protocol-specific RR type and rules --both
rules within the application protocol and rules about additional
information that is returned with MX queries.  If the MX
resolution doesn't work smoothly for IPv6, then the DNS isn't
IPv6-ready no matter how many AAAA records are defined and
spread around.  Even if one thinks an ALG is needed, one has to
find the ALG host.  I hope the additional information rules have
been adjusted if needed to encourage return of relevant AAAA
records if they exist: it hadn't even occurred to me to check
until now, but your comment about ALGs forces me to wonder
whether DNS changes for IPv6 have ignored the fact that there is
an Internet out there on which people run applications.

Mumble.
    john

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 4 Jan 2008 22:16:04 +0100

On 4 jan 2008, at 21:46, John C Klensin wrote:

> If we are now making
> of an ALG,

Huh?

What are you talking about?

I can't think of any application that would need to query for NS  
records for the root. This is the only place where stuff is going to  
change. AAAA records have been popping up all over the rest of the DNS  
hierarchy for years so this is something that applications should be  
used to by now.

The fact that an IPv6 host can't talk to an IPv4 host is unavoidable  
because the fact that IPv4 hosts can't talk to systems with addresses  
longer than 32 bits is exactly the reason why IPv6 was created.  
Hopefully we can take the edge off of that with a better version of  
NAT-PT. In the mean time, you'll want to run dual stack, not IPv6-only.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Jan 2008 13:40:17 -0800

John's email convinces me that the whole DNS issue is a red herring.
 
First off, nobody is ever going to set up IPv6 only email, not while there is any appreciable base of IPv4. They might add IPv6 support in addition.
 
Fortunately this is really easy to support. Let us imagine that we have two separate servers for the IPv4 and IPv6 support. The sysop writes an MX record as follows
 
example.com MX  1 1 1 smtp1.example.com
smtp1.example.com A 10.1.1.1
smtp1.example.com AAAA ......
 
A legacy IPv4 only SMTP server automatically chooses the A record and hits the IPv4 server. The IPv6 capable server chooses the AAAA record. 

It seems to me that this is going to be the story for every useful application. We do not have to make a fetish of doing everything with IPv6 alone. That is not the world we are moving to. In the real world of the future my home machine is going to continue to outsource SMTP mail submission and DNS query resolution to external servers. It is quite possible (certain even) that at some time in the future the pool of IPv4 addresses will dwindle to the point that my house does not have its own unique IPv4 address and so the communication between my home machines and the outsourced SMTP/DNS servers takes place over IPv6.
 
We have 4 billion IPv4 addresses. We are most unlikely to ever get to the stage where we are so short of them that an ISP cannot find enough IPv4 addresses for their servers and other proxies.

So what if you can pull up the .com domain via IPv6? The DNS server still has to be IPv4 capable or the query will quickly fail at microsoft.com, google.com or wherever.

________________________________

From: John C Klensin [mailto:[email-masked]]
Sent: Fri 04/01/2008 3:46 PM
To: Bill Manning
Cc: Barbara Roseman; [email-masked]
Subject: Re: AAAA records to be added for root servers

Mumble.
    john

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 04 Jan 2008 23:41:05 +0100

Hallam-Baker, Phillip wrote:
[..]
> smtp1.example.com AAAA ......

Which is a perfect example of dual-stack.

As for 'home users', they will get an IPv4 NAT while IPv6 will be e2e.

> So what if you can pull up the .com domain via IPv6? The DNS server
> still has to be IPv4 capable or the query will quickly fail at
> microsoft.com, google.com or wherever.

In the mean time:

http://www.microsoft.com.sixxs.org
http://www.google.com.sixxs.org

or:
http://www.kame.net.ipv4.sixxs.org

if you have IPv4 but want to look at IPv6 only sites.

As "The Internet" for most people is SMTP (see above for the solution)
and HTTP (just add a IPv6/IPv4 proxy somewhere) there is not an issue at
all with going to IPv6 except for enabling proxies at the right places,
configuring tools to use them and getting the connectivity to the users.
For everything else SOCKS does still exist.

Greets,
 Jeroen

---

From: Franck Martin <[email-masked]>
Date: Sat, 05 Jan 2008 10:49:13 +1200

It sounds so simple what to do to ensure AAAA records work, I wonder why
people made such a noise about the IETF experiment to cut IPv4 for 30mn...

hehehe

Anyhow, one day you have to bite the bullet and you cannot wait that
people implement the right thing, let the support centers glow red for a
few days and patches being issued...

This news item needs better coverage, so that all (mainly OS and
application makers) are aware, and prepared.

-- 
Franck Martin
ICT Specialist
[email-masked]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jan 2008 19:57:29 -0500

> What are you talking about?

We may have a philosophical difference of opinion here.  If we
do, the IETF list is probably not the right place to resolve it.
However, in the interest of explanation, not debate, I believe
that

(1) Some of the most attractive low-lying fruit for IPv6
deployment  involves IPv6-only machines (whether by design or
configuration) running on IPv6-only networks.    While I've
never considered it nearly as important an example as the IPv6
Forum has, if the 3G Wireless use of IPv6 is relevant to IPv6
deployment at all, it is precisely an example of IPv6-only
machines in an IPv6-only environment.

(2) IPv6 is not plausible as a network technology -- as distinct
from an IPv4 extension technology -- unless one can run
IPv6-only networks.  How much, and for how long, such networks
would have to be able to access applications and resources in
the IPv4 network(s) is a separate question.   As an IPv4
extension technology -- e.g., a mechanism for using 30 or so
bits of the IPv4 address space as a network identifier [prefix]
and putting the LAN-local address somewhere else, IPv6 is far
too complicated for its likely marginal value.

(3) As Keith Moore has pointed out repeatedly for the general
case and as I and others have pointed out for more specific ones
(including today's mail-and-DNS case), dual stack is a nice
thing to do if one is developing operating systems and maybe if
one is developing servers.  But any form of "the application has
a choice of multiple addresses or interfaces and must choose"
puts the application into the routing business.  It must have
all of the information that a router would normally have, and
maybe more, in order to make those interface decisions.  Even
then, its doing so is a serious layer violation in people and
skill-layering, not just network layering (that translates into
English as "if you expect the typical application-writer to be
able to understand topology and metric information and translate
that understanding into the application code, you are going to
be sadly disappointed".  

Even the trivial example that Jeroen and Phillip used may be
problematic, especially if there are multiple IPv4 and multiple
IPv6 addresses.   There are no MX rules at all about which
address must be tried first and some handwaving in RFC 2821
about how many addresses at a given preference level need to be
tried at all.  With most SMTP senders, such things can be
configured, but the IETF has published approximately zero advice
as to how to configure them (there actually is some reasonable
advice in RFC 3974, but that isn't an IETF document and it bears
one of the stronger forms of a "you really shouldn't pay any
attention to this" disclaimer from the IESG.

> I can't think of any application that would need to query for
> NS records for the root. This is the only place where stuff is
> going to change. AAAA records have been popping up all over
> the rest of the DNS hierarchy for years so this is something
> that applications should be used to by now.

It would need to have AAAA records for the root available if it
needed to query the root servers over IPv6.  And it would need
to do that if it, or the network on which it operated, was
IPv6-only.

> The fact that an IPv6 host can't talk to an IPv4 host is
> unavoidable because the fact that IPv4 hosts can't talk to
> systems with addresses longer than 32 bits is exactly the
> reason why IPv6 was created. Hopefully we can take the edge
> off of that with a better version of NAT-PT. In the mean time,
> you'll want to run dual stack, not IPv6-only.

Even with a better version of NAT-PT (or some other variety of
magic), suppose I have an enterprise that is running IPv6
(rather than lots of NAT and private address space).  That is
something we want to encourage, right?  Intra-enterprise
communications, including communications with the enterprise
SMTP and Mail Submission servers, are going to occur over IPv6.
Unless we force the enterprise into running split-horizon or
other tricks with a fake local DNS root, DNS queries are going
out, onto the network, over IPv6 because that is how the DNS
works.  If the IPv6 hosts within the enterprise are going to
send mail to IPv4 hosts, either the Submission server that
accesses the "outside" systems needs to be dual-stack (and
probably carefully configured) or, as Bill suggests, one needs
an ALG somewhere in the network.  Similar comments would apply
to web proxies and middleboxes for other applications.  But
there is no requirement that all of the hosts within the
enterprise LAN be dual-stack or even that they ever see an IPv4
packet.   At least I hope not because

(4) If we conclude that having an IPv4 address (direct or via
some NAT arrangement) is a requirement for every host that we
expect to run IPv6, and such addresses are necessary and
sufficient for those hosts to communicate with the network, then
we will have demonstrated that IPv6 serves no useful function.
I don't think that is true and I don't think you want to go
there.

    john

---

From: Bill Manning <[email-masked]>
Date: Fri, 4 Jan 2008 23:08:22 -0800

On Fri, Jan 04, 2008 at 07:57:29PM -0500, John C Klensin wrote:
> puts the application into the routing business.  

	:) welcome to the end2end model and the rise of the
	   stupid network... :)

> attention to this" disclaimer from the IESG.

	well the failures fo the MX record for both DNS and
	specific application use are well known and there was
	a well designed "charge" to replace that capability
	in the DNS with a more general purpose tool that does
	help w/ the "which interface to use" problem.. which
	is in fact, very old indeed..  I point you to the SRV RR.

--bill

-- 
--bill

---

From: Franck Martin <[email-masked]>
Date: Sat, 05 Jan 2008 22:08:04 +1200

Seems to me that DNS software at the customer level should be able to
respond to the applications immediately from the cache: switch from IPv6
to IPv4 because I have IPv4 info.

The standard behavior would be query with IPv6 the network DNS, and if
they answer with IPv6 info, carry on, if they answer no info return
error, or they answer switch to IPv4 because I have IPv4 info to give you.

Would that simplify the life of IPv6 applications?

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Jan 2008 09:45:50 -0500

--On Saturday, 05 January, 2008 22:08 +1200 Franck Martin
<[email-masked]> wrote:

> Seems to me that DNS software at the customer level should be
> able to respond to the applications immediately from the
> cache: switch from IPv6 to IPv4 because I have IPv4 info.
> 
> The standard behavior would be query with IPv6 the network
> DNS, and if they answer with IPv6 info, carry on, if they
> answer no info return error, or they answer switch to IPv4
> because I have IPv4 info to give you.
> 

As long as the application gets back exactly one address from
whatever query process it uses, it is presumably happy.   If it
gets back zero addresses, it may not be happy, but it knows
exactly what to do.

The problems arise in (at least) the following cases:

(i) The application must choose whether to query for IPv4
records, or for IPv6 records, or both.  Your scenario assumes
that it will ask for IPv6 records first and stop if it finds
one, but it might choose to ask for IPv4 ones anyway or to
prefer IPv4 connections if those were available.

(ii) If the application gets multiple address records back
(IPv6, IPv4, or a mixture), it must select which one to use.
This is not a new problem but dates back to roughly the point at
which we discovered how to make machines with multiple
interfaces.   It got much worse when we started connecting
networks to each other with routers, rather than hosts to
networks because, in the latter case, the requisite routing
preference information was at least available on the local host.
With hosts connected to LANs that terminate in one or more
router, the routing preference information is typically not even
available on the same host as the application that is called on
to make the decision.  IPv6 obviously adds a layer of
complexity, since, all of things being equal, one would probably
prefer an IPvX path to a host that did not involve address
translation to an IPvY path that did and _that_ information is
typically not even available to the routing system.  And, of
course, if one has no support (either on the local host or
between it and the first-hop router) for IPvX, then IPvY is
obviously preferred regardless of other considerations.

(iii) MX RRs, and to some considerable extent SRV RRs, which do
permit expressing some preference information at the application
layer, raise some additional complications about configuration
if not present and carefully organized.   In addition to the one
that I mentioned in starting this thread, the preference levels
reflect information available to the server and, presumably,
preferences from the server's perspective.  They cannot reflect
preferences from the perspective of the client or its network
connectivity.  One can easily configure oneself into a large
mess and, as I pointed out in an earlier not, we have offered
little advice about how to deal with that problem.

This is complicated by a more general problem with MX records:
the model assumes that all of the listed hosts will have the
same capabilities other than simple reachability (or not).  When
the spec was written, that was reasonable because we didn't have
a mechanism for different hosts advertising different
capabilities.  I'm on the hook for doing a writeup on that
subject, but doing so is backed up behind other work (and, in
particular, getting 2821bis into Last Call).

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Jan 2008 09:30:20 +1300

John,

Excuse front-posting but it probably works better than
interstitial comments for what I want to say.

The basic theory is supposed to be that faced with
a mixture of A and AAAA responses, the host will
by default prefer IPv6 and by default use RFC 3484
to choose among multiple IPv6 addresses. As far as
I know, that's running code for many SMTP servers.
It's also running code for Java 1.5 and up. (In both
cases, the host needs a dual stack supporting RFC 3484.)
In fact it's running code for any properly ported
application. But it does need some logic on top of
the getaddrinfo() call.

Note that this set of preferences would apply *after*
any set of preferences applied at the FQDN level, e.g.
after MX preferences have been applied.

It's also obviously that case that if an FQDN has both
A and AAAA records, all applications servers reached
at those addresses must support IPv4 and IPv6
respectively. No exceptions.

There's an operational fly in the ointment if the
DNS returns an AAAA record but no path exists to that
address; unfortunately we still have such issues
(exactly as we did for some A records 15 or 20 years ago).
In that case the client host would need to try all IPv6
addresses in sequence, followed by all IPv4 addresses in
sequence, until something works. That's more logic on top
of the socket API.

As Phill H-B has implied more than once, there's scope
for a library on top of the socket API that takes care
of this once and for all. Does anyone have such a library?

    Brian

---

From: Bill Manning <[email-masked]>
Date: Sat, 5 Jan 2008 14:45:45 -0800

the IETF has refused to adopt the DISCOVER opcode for 
the DNS - which pretty much handles this problem. Others
may have developed other techniques.

--bill

-- 
--bill

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 6 Jan 2008 10:06:51 +0100

> However, in the interest of explanation, not debate, I believe

It seems we're actually mostly in agreement: for IPv6 to be useful, it  
must be possible to run IPv6-only in at least some places.

> But any form of "the application has

Well, someone has to do the dirty work... My years in multi6 taught me  
that the people at each layer would be much happier if the complexity  
happened at one of the other layers. Unfortunately, the routing layer,  
which can solve this problem in small networks, can't do the same in  
large networks because of scaling issues. (And our protocols aren't  
especially smart: BGP knows how to avoid bad paths successfully in  
most cases, but it isn't very good at picking the best path.) Even  
today we have scaling issues even though a single entry in the routing  
tables is the aggregated information pertaining to hundreds or  
thousands of hosts. It would be possible to make a transport protocol  
that handles this issue, but that won't happen until we actually do  
the work to make that protocol, because TCP isn't it: it can't even  
migrate to a different address if the current address doesn't work.  
SCTP can do that but current implementations are limited to finding a  
working address, not the best one or even a good one from the set of  
working addresses and switching from TCP to SCTP is just as bad as  
moving from IPv4 to IPv6. This means that all applications that use  
TCP in an environment where there is the possibility that there are  
multiple addresses must be prepared to retry a session setup attempt  
until one works using in succession the addresses returned by the name- 
to-address mapping (= DNS).

(And IPv6 is a multi-address environment by design even without  
recognizing that running dual stack obviously requires two addresses.)

The selection of the best address is currently under the purview of  
RFC 3484, which doesn't have the tools to solve this issue  
satisfactory but at least keeps the issue out of the applications,  
except for trying addresses until one works. Really solving this means  
communicating preference values and doing reachability tests and QoS  
measurments, which is currently a research topic rather than an  
engineering topic.

> tried at all.

Well, this is what I have:

                IN      MX      100 sequoia.muada.com.
                IN      MX      200 mailv4.muada.com.

sequoia has both IPv4 and IPv6 addresses and the choice between those  
should happen using RFC3484, which, AFAIK, is generally implemented by  
ordering getaddrinfo() (successor to gethostbyname()) results. mailv4  
doesn't have an IPv6 address in order to avoid triggering bugs, which  
was a consideration a few years ago.

RFC 3484 suggests the use of a policy table that lets administrators  
set the relative preference of certain address ranges (IPv4 or IPv6).  
By default, IPv6 is preferred over IPv4, but with the policy table,  
this is easily reversed in the general case or for certain address  
ranges. Note also that applications can either ask for IPv4 addresses,  
IPv6 addresses or "any" type, with the latter generally resulting in  
the subset of available addresses for a name that is presumed  
reachable from the availability of IPv4 and/or IPv6 addresses and  
default routes on the system. I.e., if the application simply asks for  
"any" then it doesn't have to worry about IP versions.

> to do that if it, or the network on which it operated, was

Like I said, I don't know of any application that needs to do that.

Also, obviously the addition of AAAA records can only help hosts that  
are IPv6-only.

> I don't think that is true and I don't think you want to go

Well, any proxy or ALG that allows IPv6 hosts to talk to IPv4 hosts  
involves and IPv4 address that the IPv4 hosts perceive as their  
correspondent's address, and the IPv6 host in this communication could  
be perceived to "have" this IPv4 address. I don't think the presence  
of a very limited number of such addresses can reasonably be taken as  
an indication that IPv6 has failed. The current situation is that  
about 0.1% of the internet is reachable over IPv6. If no further  
progress is made, we can qualify this as failure, even if I can turn  
off IPv6 and still get work done through proxies etc. But as the  
original message in this thread shows, we're still making progress.

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Jan 2008 05:21:36 -0500

> I know, that's running code for many SMTP servers.

But, in general, SMTP servers don't choose addresses.  SMTP
clients do.  The number of them that are 3484-compliant is not,
in my experience, large although there may be ones out there
that I don't know about or that have been fixed while I wasn't
looking.  As far as the default IPv6 preference is concerned,
trying something, waiting for it to get a "not reachable" or,
much worse, time out, and then trying something else takes
sufficiently long that, until IPv6 reaches some critical mass,
configuring a 3484 sequence to prefer IPv6 in a production
environment just doesn't make a lot of sense right now.
Iljitsch's recent note covers some of the related issues much
better than I could and I have nothing to add to it.

> application. But it does need some logic on top of

Part of what I'm suggesting is that "properly ported
applications" are not a large enough set to make trying to run
IPv6 attractive to those whose goal is just to get work (or
entertainment) done on the Internet... and that a large part of
the problem is that missing logic, so we are in agreement on
that at least.

> after MX preferences have been applied.

And what started this set of comments was only that, IMO, (i) we
have not done a good enough job yet of warning people that, if
SMTP-senders are following the protocols as now written, they
MUST have MX records for the target SMTP servers; there is no
default that involves IPv6 addresses, and (ii) it is fairly
easy, through carelessness and/or stupidity, to configure MX
records into a nasty state and we haven't given explicit,
standards-track (or BCP) advice about those "opportunities" and
how to avoid them.

> respectively. No exceptions.

It may obviously be the case, but the implication of this is
that I dare not put an AAAA record up for a host that serves out
several protocols until all of those protocols are IPv6-ready.
That is an impediment to incremental conversion of a
multipurpose, dual-stack, host and is probably not optimal for
getting IPv6 deployed quickly.    If it is our only choice, then
it is our only choice, but it is not an attractive one.

> sequence, until something works. That's more logic on top

Yes.  It also runs afoul of the current definition of SMTP and
MX routing, because a host is _explicitly_ not required to try
all addresses at a given preference level before moving on (or
even giving up).  One can avoid getting into that problem by
being very careful about how many addresses might be tried at a
given preference level (which has some implications about hosts
with many listed addresses), but that is part of the "how to
configure this so it doesn't cause problems" issue that I refer
to above and in my original note.

And trying every address in sequence, without even caching the
information about what worked recently, is pathological from a
performance standpoint.  Worse, as Iljitsch points out, the
ability to reach a host at a particular address does not imply
that the path used is optimal (or even better than "pessimal but
sort of works").  If one wants to find a decent path (somewhere
between optimal and pessimal), then one has to try all of them,
and make measurements, until either a satisfactory level of
performance is found or one has enough information to perform a
ranking.  If one where going to go to all that trouble, one has
better be able to remember the results for at least a while.
And, at that point, the application (or that hypothetical socket
API) is beginning to resemble a router.

> of this once and for all. Does anyone have such a library?

Phill's suggestion is, I believe, a different form of part of
the comment I'm making and, at the risk of putting words in his
mouth, part of what Keith has been saying for years.  One can
say whatever one likes about shifting the burdens around or
difficulties in the e2e model in today's environment but the
bottom line is that, if one wants applications running smoothly
in an IPv6 (or dual-stack) environment, those applications need
to be able to call something when looking for an address record
that returns one plausible address in return for a name.  My
personal belief is that the "something" is going to need to be
sufficiently intimate with the operating system to maintain some
memory of what it has done across applications and to take
advantage of information that no one application is likely to
have. And I fear that, if we don't get serious about that sort
of thing, we might as well predict IPv6 deployment over the next
decade by extrapolation from the last decade.

    john

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 06 Jan 2008 21:12:22 +0900

Iljitsch van Beijnum wrote:

> large networks because of scaling issues.

Transport layers neither, unless you assume default timeout of TCP,
which is no assumption for UDP nor unusual TCP.

Unfortunately for IETF, there was little people being aware about
that and, thanks to particularly poor chairmanship, the consensus
of WG, including you but excluding people aware of the real problem,
resulted in non-solutions similar to NAT.

> (And our protocols aren't  
> especially smart: BGP knows how to avoid bad paths successfully in  most 
> cases, but it isn't very good at picking the best path.)

Protocols from multi6 is just as poor as that from IPv6 WG, of
course, that is, unusable.

> SCTP can do that

That's simply an utter violation of layering similar to everything
over not IP but HTTP.

> (And IPv6 is a multi-address environment by design

No. IPv6 itself is no better than IPv4 in handling multiple addresses.

> The selection of the best address is currently under the purview of  RFC 
> 3484, which doesn't have the tools to solve this issue  satisfactory but 
> at least keeps the issue out of the applications,

That's why the RFC is broken.

> Really solving this means  communicating 
> preference values and doing reachability tests and QoS  measurments, 

No.

Thank you for repeated demonstrations on your so poor understanding on
the problem.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 6 Jan 2008 17:14:23 +0100

> in my experience, large

Not sure what you mean here by "SMTP clients"... Would that be client  
computers such as the one I'm typing this message on? But those don't  
look at MX records, unless I'm very much mistaken.

However, it's not the applications that have to be aware of RFC 3484,  
but the OS. The only thing the application needs to do is use a  
network API that supports IPv6 and the OS will take care of selecting  
a list of appropriate addresses and try to order them in descending  
order of preference. (For instance, Apple's Mail can work over IPv6  
but it only tries the first address so if there is non-working IPv6 I  
can't get at my mail.)

> As far as the default IPv6 preference is concerned,

No, the part that doesn't make sense is enabling IPv6 but then  
preferring IPv4. That way, you don't get to find out what works and  
what doesn't work. It is true that enabling (and thus preferring) IPv6  
can have downsides. In my case it means the IETF website is  
excruciatingly slow because there doesn't seem to be any routing from  
the IETF to my ISP's IPv6 addresses. This is something that doesn't  
generate ICMP errors for me so I have to suffer TCP timeouts and  
fallback to IPv4. But fortunately, this type of issue is rare these  
days. However, operators aren't yet as responsive to these issues as  
they are to IPv4 reachability problems.

> several protocols until all of those protocols are IPv6-ready.

That's just silly. You can create different names where one has only  
IPv4 and one also has IPv6.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Jan 2008 10:00:32 +1300

Bill,

 From the layer 7 point of view, I don't see what DISCOVER
would offer in addition to getaddrinfo(). The library
I'm thinking of would also have to handle reachability
checking - and as John said, would ideally also be stateful
to avoid repeating the same timeouts.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Jan 2008 09:53:43 +1100

> but it only tries the first address so if there is non-working IPv6 I  

	Apple's Mail is not RFC 1123 compliant then.  I seriously
	doubt that Apple can produce the design documentation that
	proves that they even thought about this.  If they can I'd
	like to see the justification.  It would be a interesting
	read.

         *    "SHOULD"
         
              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

2.  GENERAL ISSUES

	[snip]

   2.3  Applications on Multihomed hosts

      When the remote host is multihomed, the name-to-address
      translation will return a list of alternative IP addresses.  As
      specified in Section 6.1.3.4, this list should be in order of
      decreasing preference.  Application protocol implementations
      SHOULD be prepared to try multiple addresses from the list until
      success is obtained.  More specific requirements for SMTP are
      given in Section 5.3.4.

> what doesn't work.

	And the longer people leave it the more likely it is that
	the service will be swamped as more and more clients have
	IPv6 transports.

> It is true that enabling (and thus preferring) IPv6  

	No.  There is no such requirement.  Just make sure the
	server sends ICMP or RST.  The client should move on
	to the next address after one RTT.

	UDP based applications may be more problematic but not
	always.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 6 Jan 2008 18:32:06 -0800

> From: Brian E Carpenter [mailto:[email-masked]] 

> As Phill H-B has implied more than once, there's scope for a 
> library on top of the socket API that takes care of this once 
> and for all. Does anyone have such a library?

I suspect the answer is that we either have zero or more than one such libraries.

If we are going to achieve interoperabilty I think we are going to need the IETF to take a lead in defining the abstract functionality of such socket APIs.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Mon, 7 Jan 2008 08:50:17 +0200

> of this once and for all. Does anyone have such a library?

Some TCP/IP stacks include this kind of API:

http://msdn2.microsoft.com/en-us/library/ms741554.aspx
http://msdn2.microsoft.com/en-us/library/ms741557.aspx

Best regards,
Pasi

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Jan 2008 02:45:43 -0800

by the time layer 7 is reached, there is only one address to 
 be concerned about... or should be.  if the "library" your
 thinking of tests reachability, then you have moved the routing
 function into the host - which is a much larger problem space.
 DISCOVER, unlike QUERY, is designed to deal with multiple replies
 to a question - e.g.  what address(s) map to this name?  whereas
 QUERY will take the first thing it gets back.

-- 
--bill

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 06 Jan 2008 21:18:41 -0800

Barbara and all,

  Why only 4 root servers?

Regards,

Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

Barbara Roseman wrote:

> apnic-talk mailing list
> [email-masked]
> http://mailman.apnic.net/mailman/listinfo/apnic-talk

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 7 Jan 2008 17:26:45 +0100

On 6 jan 2008, at 22:00, Brian E Carpenter wrote:

> The library

I don't think the thing that we need most in this area is a library. I  
did some testing, and it seems that a sample program copied and pasted  
from the getaddrinfo man page (which ONLY does DNS lookups and nothing  
else) experiences the influence of RFC 3484. What we do need is the  
knowledge about connectivity and QoS of addresses. We don't have that  
today and we have no easy way of getting it.

---

From: Tony Finch <[email-masked]>
Date: Mon, 7 Jan 2008 19:22:27 +0000

On Fri, 4 Jan 2008, John C Klensin wrote:
>
> However, there is also a rule that, if no MX records are present at a
> particular node, the mail system looks for an A RR at the same node and
> treats it as if its label appeared with an MX preference of 0.  That
> default does not apply to AAAA records, so it is necessary that
> operators understand that, if mail systems are to be accessed using
> IPv6, they MUST have MX records at the relevant nodes.

The only document that I know of which specifies IPv6 email routing is RFC
3974, which says that AAAA should be treated exactly the same as A. As far
as I know, Exim, Postfix, and Sendmail follow RFC 3974.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA SHANNON ROCKALL MALIN: MAINLY SOUTHWESTERLY, BECOMING CYCLONIC FOR A
TIME IN SHANNON, ROCKALL AND MALIN, 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9,
PERHAPS STORM 10 LATER IN SHANNON, ROCKALL AND MALIN. ROUGH OR VERY ROUGH,
OCCASIONALLY HIGH. RAIN OR SQUALLY SHOWERS. MODERATE.

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 07 Jan 2008 20:39:39 +0100

> as I know, Exim, Postfix, and Sendmail follow RFC 3974.

It seems that at least Postfix doesn't handle this the way it should do 
it. It does IPv6, but not according to how I understand it which is:

------------------------------------------
all_mxs = dig("dom", "MX");
sort_on_prio(all_mxs);

done = 0;

for (mx in all_mxs && done == 0)
{
	all_addrs = dig(mx, "AAAA|A");
	sort_aaaa_first_then_a(all_addrs);

	for (addr in all_addrs)
	{
		if (connect_to(addr, 25))
		{
			ret = try_smtp_exchange();
			if (connection_timeout) next;

			if (ret == 2xx) done = 1; success(); last;
			if (ret == 4xx) last;
			if (ret == 5xx) done = 1; DSN(); last;
		}
	}
}

if (!done)
{
	queue_message_for_later_retry();
}
------------------------------------------

Then if we have:
-------------------------------------------
example.com.
	MX	10 a.example.com.
	MX	20 b.example.com.

a.example.com.
	AAAA	2001:db8::11
	A	192.0.2.11

b.example.com.
	AAAA	2001:db8::22
	A	192.0.2.22
------------------------------------------

'a' & 'b' are both separate MX's. As such according to the above 
pseudo-code, which I deduced from the RFC, whenever 'a' is contactable 
and you can get a response from it, you should honor that response. Thus 
if you contact 'a' and it replies with a "450 Out of diskspace, try 
later" or other temp failure or a 5xx error etc, one should go to 'b'.

Postfix contacts a-AAAA, gets a 450 diskspace, then contacts a-A, gets 
the same error again, and then tries b-AAAA and then b-A, which might 
accept the message.

We actually noticed this last year because of one of Paul Vixies email 
setups rejects-all over IPv4 but accepts mail on IPv6, but as IPv6 gets 
greylisted (and thus it sends a 450) postfix tried the IPv4 address 
also, which resulted in a 500, rejecting the message, if Postfix would 
have properly followed the RFC like in the above pseudo code then it 
would have requeued the message and tried again a bit later, which would 
have caused the message delivery to succeed.

Indeed it is an odd-case, but it is the way it is specified in the RFC.
Also, the real thing is that one should not retry on the same MX as it 
is the same host, otherwise it would be a different host with a 
different weight in the MX label.

Also indeed, this does also lighten the load on 'email clusters' where 
the MX label has maybe 20 A records or so, as the sender should only try 
once to that MX label, and not try and contact all 20 of them.

Greets,
  Jeroen

---

From: Tony Finch <[email-masked]>
Date: Mon, 7 Jan 2008 19:43:58 +0000

On Fri, 4 Jan 2008, John C Klensin wrote:
> On Friday, 04 January, 2008 12:01 -0800 Bill Manning <[email-masked]> wrote:
> >
> > The general answer when needing to communicate between similar
> > applications that run on different address families has traditionally
> > been the application layer gateway (ALG) ...

MTAs *are* ALGs.

> [...] If the MX resolution doesn't work smoothly for IPv6, then the DNS
> isn't IPv6-ready no matter how many AAAA records are defined and spread
> around. [...] I hope the additional information rules have been adjusted
> if needed to encourage return of relevant AAAA records if they exist
> [...]

Yes AAAA records are returned in the additional section just like A
records. However this behaviour is less useful than one would hope,
because of the RFC 2181 rules about the TC bit. In particular, it is not
set when RR sets have been dropped from the additional section of the
reply. This means an MTA can't immediately tell the difference between an
IPv4-only MX record and a dual-stack MX record where the IPv6 addresses
have been truncated. It must do extra DNS lookups to resolve the
ambiguity, which (at the present time) is usually a waste of effort. The
extra lookups are not optional because you can also get dual-stack MX
replies in which the A records have been dropped, which can (and does)
lead a naive IPv4-only MTA to think erroneously that it cannot reach the
other server.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
NORTH FITZROY: SOUTHWESTERLY 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER. VERY
ROUGH. RAIN. MODERATE.

---

From: Tony Finch <[email-masked]>
Date: Mon, 7 Jan 2008 19:51:51 +0000

On Mon, 7 Jan 2008, Jeroen Massar wrote:
>
> 'a' & 'b' are both separate MX's. As such according to the above pseudo-code,
> which I deduced from the RFC, whenever 'a' is contactable and you can get a
> response from it, you should honor that response. Thus if you contact 'a' and
> it replies with a "450 Out of diskspace, try later" or other temp failure or a
> 5xx error etc, one should go to 'b'.
>
> Postfix contacts a-AAAA, gets a 450 diskspace, then contacts a-A, gets the
> same error again, and then tries b-AAAA and then b-A, which might accept the
> message.

Exim does the same as Postfix. (I haven't checked what Sendmail does.)
When we last had this argument on the SMTP list the conclusion was that
the specification is not clear enough to decide what is correct, so it's
best to implement the most operationally practical algorithm. It depends
whether you think multiple address records for a name are only for
multi-homed hosts, or whether it's legitimate to point a single name at
multiple separate hosts.

Of course because some postmasters will think that their idea of "correct"
is the only possible one and try to implement an anti-spam policy on this
basis, disagreements inevitably lead to interoperability problems.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE: VARIABLE 4, BECOMING SOUTHERLY 5 TO 7, PERHAPS GALE 8 LATER. ROUGH.
SHOWERS. MODERATE OR GOOD.

---

From: Tony Finch <[email-masked]>
Date: Mon, 7 Jan 2008 20:06:16 +0000

On Fri, 4 Jan 2008, John C Klensin wrote:
>
> There are no MX rules at all about which address must be tried first and
> some handwaving in RFC 2821 about how many addresses at a given
> preference level need to be tried at all.

In practice MTAs often randomise host addresses, ignoring the requirement
in RFC 2821 that they should trust the resolver to order them by
preference. You need to limit the number of host addresses your MTA tries
because some abusive DNS setups can cause an MTA to spend ages
wasting time trying to deliver a message. If you implement a limit like
this then it helps if you also randomize so that the next delivery attempt
tries a different subset of the host addresses.

Tony.

---

From: SM <[email-masked]>
Date: Mon, 07 Jan 2008 13:46:53 -0800

>look at MX records, unless I'm very much mistaken.

What you are using to send this message is known as a MUA (Mail User 
Agent).  In RFC 821, the two hosts participating in an SMTP 
transaction were described as the "SMTP-sender" and 
"SMTP-receiver".  Nowadays they are referred to as "SMTP client" and 
"SMTP server".

Quoting RFC 2821, an SMTP client determines the address of an 
appropriate host running an SMTP server by resolving a destination 
domain name to either an intermediate MX host or a final target host.

>can have downsides. In my case it means the IETF website is

Agreed.  However, finding out what works and what doesn't work might 
not be an alternative in a production environment as it would have a 
significant impact on mail delivery.

Regards,
-sm

---

From: Franck Martin <[email-masked]>
Date: Tue, 08 Jan 2008 14:14:41 +1200

Did you file a bug on postifx?

Jeroen Massar wrote:

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jan 2008 15:36:07 +1300

> http://msdn2.microsoft.com/en-us/library/ms741557.aspx

Right, but I was more hoping for an open source library...

    Brian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Jan 2008 22:35:14 -0500

>>> been the application layer gateway (ALG) ...

(Uh Oh.)

Nope.

MTAs are email relays.  ALGs can perform syntactic and semantic 
transformations.  A simple relay can't. ALGs connect similar applications that 
entail heterogeneous technologies, conventions, whatever.

Now it happens that email gateways have to include MTA functionality, since 
they all operate as relays, also.  And lots of software the is email 
gateway-capable are often used merely as MTAs, nicely confusing the heck out 
of us.

But architecturally, ALGs are seriously different.  Stated simplistically, an 
MTA performs very few functions and makes minimal changes to a message, where 
the 'changes' are mostly some additions.  An email gateway can massively alter 
the object.  It has permission to do whatever is necessary to make

d/

ps.  No one will be surprised that I've documented this issue in the email

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jan 2008 23:06:32 -0500

--On Monday, 07 January, 2008 22:35 -0500 Dave Crocker
<[email-masked]> wrote:

>>>> The general answer when needing to communicate between
>>>> similar applications that run on different address families
>>>> has traditionally been the application layer gateway (ALG)
>>>> ...
>> 
>> MTAs *are* ALGs.
> 
> 
> (Uh Oh.)
> 
> Nope.
> 
> MTAs are email relays.  ALGs can perform syntactic and
> semantic transformations.  A simple relay can't. ALGs connect
> similar applications that entail heterogeneous technologies,
> conventions, whatever.
> 
> Now it happens that email gateways have to include MTA
> functionality, since they all operate as relays, also.  And
> lots of software the is email gateway-capable are often used
> merely as MTAs, nicely confusing the heck out of us.

I'd make a further distinction and claim that even many email
gateways don't rise to the level (or sink to the depths) of what
we usually think about as ALGs.  First of all, I would contend
that an SMTP system that accepts an SMTP-and-MIME conformant
message that arrives over an IPv6-based TCP connection and that
is sent back out, using an unchanged address, over an IPv4-based
TCP connection is performing a standard relay function, not even
a mail gateway one (I think that is consistent with Dave's
comment above).  But even a mail gateway that, e.g., needs to do
some rewriting of addresses to get from the systems on one side
to the systems on the other still isn't in the ALG business as
I, at least, usually understand it.  The transformations are
mechanical, they don't require any external information, and
they don't inherently depend on the underlying transport
technology.  So I would suggest that some, but not all, email
gateways are ALGs... and that no relay is.

> But architecturally, ALGs are seriously different.  Stated
> simplistically, an MTA performs very few functions and makes
> minimal changes to a message, where the 'changes' are mostly
> some additions.  An email gateway can massively alter the
> object.  It has permission to do whatever is necessary to make
> 
> d/
> 

On the other hand, they might be surprised that we seem to be
agreeing <grin>
 
    john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Jan 2008 23:29:26 -0500

John C Klensin wrote:
> comment above).  

Entirely consistent.

Gateways do transformations at their own level of the stack.  Anything at a
lower layer is essentially transparent, given the basic relaying task.

Simply put, if it isn't transforming the rfc2822 object, it isn't a gateway.

> But even a mail gateway that, e.g., needs to do

Address translation, format translation, possibly other mappings.  But yeah,
addresses seem to be the biggies.

> gateways are ALGs... and that no relay is.

mumble.  probably.  mumble.

>> ps.  No one will be surprised that I've documented this issue

oops.  didn't add the specific reference:

I meant the Internet Mail Architecture draft, of course:

   <http://bbiw.net/specifications/draft-crocker-email-arch-08.html>

> On the other hand, they might be surprised that we seem to be

Particularly given that it is about email technology...

d/

-- 

   Dave Crocker

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jan 2008 07:49:04 +0000

> Nope.

Sorry, I should have been clear that I was talking about practice rather
than architecture.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND PLYMOUTH NORTH BISCAY SOUTHWESTERLY 6 TO
GALE 8, PERHAPS SEVERE GALE 9 LATER. ROUGH OR VERY ROUGH. SQUALLY SHOWERS.
GOOD.

---

From: [email-masked]
Date: Mon, 7 Jan 2008 15:44:35 +0000

property B, which effectively means they are paragraph separating).

Apart from CR+LF, these SHOULD NOT be emitted for net-utf8, unless
that is overriden by the protocol specification (like allowing FF, or CR+FF).
When faced with any of these in input **to be emitted as net-utf8**, each
of these SHOULD be converted to a CR+LF (unless that is overridden
by the protocol in question).

--------------------------

Section 2, point 3:

You have made an exception for FF (because they occur in RFCs?).
I think FF SHOULD be avoided, just like VT, NEL, and more (see above).
Even when it is allowed, it, and CR+FF, should be seen as line separating.

You have also (by implication) dismissed HT, U+0009. The reason for this in
unclear. Especially since HT is so common in plain texts (often with some
default tab setting). Mapping HT to SPs is often a bad idea. I don't think a
default tab setting should be specified, but the effect of somewhat (not wildly)
different defaults for that is not much worse than using variable width fonts.

SP, U+0020, is nowadays not seen as a control character, not even in
your own text... (same paragraph).

--------------------------

   "However, because they were optional in NVT applications
   and this specification is an NVT superset, they cannot be prohibited
   entirely." 

Why not? Why must this be a strict NVT superset? I think it would be rather
important to rule these strange beasts out from net-utf8. These were really
ASCII (ISO 646) features, but have been ruled out much before Unicode.

--------------------------

   "The most important of these rules is that CR MUST NOT
   appear unless it is immediately followed by LF (indicating end of
   line) or NUL."

I don't see how that follows (read: that does not follow).

--------------------------

     "[ISO10646]
              International Organization for Standardization,
              "Information Technology - Universal Multiple- Octet Coded
              Character Set (UCS) - Part 1: Architecture and Basic
              Multilingual Plane"", ISO/IEC 10646-1:2000, October 2000."

That seems a bit old... Better with the current revision:

ISO/IEC 10646:2003   Information technology -- Universal Multiple-Octet Coded
Character Set (UCS)

with the amendments (which I don't think you should reference explicitly):
ISO/IEC 10646:2003/Amd 1:2005  Glagolitic, Coptic, Georgian and other characters
ISO/IEC 10646:2003/Amd 2:2006  N'Ko, Phags-pa, Phoenician and other characters
(and more amendments in the works).

--------------------------

---

From: [email-masked]
Date: Mon, 7 Jan 2008 15:44:35 +0000

perhaps your answer can be found in the first line of Barbaras
message.  let me quote it:
"> On 4 February 2008, IANA will add AAAA records for the IPv6 addresses 
> of the four root servers whose operators have requested it. "

.... for the four root servers whose operators have REQUESTED it.

(emphasis added)

e.g. the other operators have not requested AAAA records be added 
for their servers.

--bill

09 Jan 2008 09:58:41 -0500
Cc: [email-masked], [email-masked], Ga <[email-masked]>,
	[email-masked], [email-masked],
	ac-coord' AC <[email-masked]>,
	[email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked],
	Barbara Roseman <[email-masked]>, [email-masked]
Subject: Re: [dns-wg] Re: [apnic-talk] AAAA records to be added for root
	servers
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

perhaps your answer can be found in the first line of Barbaras
message.  let me quote it:
"> On 4 February 2008, IANA will add AAAA records for the IPv6 addresses 
> of the four root servers whose operators have requested it. "

.... for the four root servers whose operators have REQUESTED it.

(emphasis added)

e.g. the other operators have not requested AAAA records be added 
for their servers.

--bill