Subject: RE: IPv6 transition architecture discussion

From: "Bound, Jim" <[email-masked]>
Date: Sun, 24 Nov 2002 23:46:45 -0500

Pekka,

Inline responses.

/jim
[A people who would give up their freedom out of fear did not deserve it
in the first place. Ben Franklin]

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Sunday, November 24, 2002 6:45 AM
> To: [email-masked]
> Subject: IPv6 transition architecture discussion
> 
> 
> Hello,
> 
> Triggered by extended discussion at the IETF meeting on 
> NAT-PT, I think we should try to discuss more about the 
> _core_ matters of the transition, for
> example:
> 
> 1) how to start enabling v6-capable software in the operating 
> systems, and having operating systems v6-enabled, in such a 
> fashion that it does not hinder the current usability of v4?

None of the IETFs business you can't tell vendors what and what not to
do in their products.
This is not specifying standards.  You cannot tell vendors what to do
with their operating systems either.

> 
> A starter for discussion: v6 connectivity is very poor (see 
> draft-savola-v6ops-6bone-mess-01 for more).  Vendors are 
> rightfully afraid (I sure don't want them doing it) to enable 
> v6 by default, as connections could easily switch to using 
> (badly working) v6.

What vendor told you they are afraid?  If you cannot state who that is
then please retract this statement.

All vendors shipping products have web pages and kits to install IPv6.
You might go buy them and test them for yourself.  Also all our
interoperability labs are doing this now UNH, ETSI, TAHI, and now China.
This is none of the IETFs businss or v6ops unless that works points to a
protocol or operations problem on the network.  If you know of such
cases I am sure the chairs would love to hear them.

> 
> Do we need to do something about this or just wait N years to 
> operators to do something.  Note: this is a chicken-and-egg 
> problem, ISP's don't deploy v6 before it's requested (and 
> paid for, in some way or another), and the connectivity 
> remains poor because v6 isn't really production yet.

ISPs are deploying IPv6 you simply don't know what your talking about.
Right now it is in test bed mode and that will last awhile and it has
nothing to do with anything we can do in the IETF to help at this point.
The one thing we could do is stop wasting mail messages with mail like
this and get some decisions made about SLs, Scenarios, et al.   That is
the IETF's job not this diatribe you spew out here all to often, that is
totally irrelevant to the building of standards.

If you want to be part of the deployment mission and effort there are
places to do that and I would be glad to give you pointers offline as
this is not an IETF matter.

> 
> 2) are there some cases in the transition which we could 
> ignore, to make 
> it simpler?  In particular, this includes v6-only and v4-only 
> interoperation.

This is a valid discussion I agree.

> 
> A starter for discussion: v4-only <-> v6-only in a general 
> case is complex.  IMO we perhaps shouldn't try to solve the 
> general problem, as it draws the attention away from more 
> important issues.  Is it ok to require v6-only nodes will 
> only be deployed when they don't need connectivity to v4-only 
> nodes (except by proxies -- e.g. TCP/UDP relay or ALG level 
> thing is IMO just fine)?  

You cannot require anything Pekka.  You can only build a draft and
propose a standard.  The IETF cannot mandate anything at all to the
market or to those who have built and continuing to build IPv6 features
in products.

> 
> For example, in home networking scenario, enabling v6-only 
> printers etc. should be trivial _if we require_ TCP/UDP proxy 
> e.g. in one dual-stack computer in the network.  On the other 
> hand, I would imagine it could be ok to just say, if you want 
> to use that printer, upgrade your OS, period.

You have to be kidding right?   Have you ever shipped a product that a
customer is using?  If so you should know that no one in this standards
body or any standards body or even any deployment forum (which has far
more influence and power than the IETF to affect deployment) will EVER
tell a vendors customer what to do with their OS.   This is silliness
and borders on outright confusion on your role in the IETF and the role
the IETF will support you in.  This will not happen here.

> 
> Is it required to be able to communicate between v6-only node 
> in your network to v4-only nodes in the general internet?  
> The need for this can be mitigated by dual-stack ALG's, like 
> web proxies. My suggestion would be that don't deploy v6-only 
> nodes, requiring v4 internet access, then.  
> Such could still be deployed in internal networks -- most 
> v6-only gadgets today don't really require to be accessible 
> or to access v4 internet anyway -- and even v4 in the local 
> network is also a bit arguable.

Then right a spec for transition.  I would hope the chairs tell you to
wait for the scenarios as everyone else is told.  Why don't you work on
the scenarios as a working group member.

> 
> x) there are probably many other "really important" issues we 
> need to have 
> some idea of.  It's not all that useful to meddle with 
> scenario details 
> until we have some idea how the big picture should work itself out.

What your asking is the kind of discussions one has when building
products.  But I don't agree and the chairs have made it pretty clear we
must work on scenarios.  I have come to support that and it makes some
logical sense.   The scenarios are about use cases and people deploying
now and that is the big picture.

> 
> I think this is something we need to properly discuss now and 
> possibly at 
> the next meeting.

I simply disagree and strongly do not support this and ask the chairs to
kill 90% of what you suggest as out of scope for this mail list and the
IETF.

/jim

> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Nov 2002 10:27:05 +0200 (EET)

On Sun, 24 Nov 2002, Bound, Jim wrote:
> do in their products. This is not specifying standards.  You cannot tell
> vendors what to do with their operating systems either.

Of course, it's not IETF's business to say what to do.

But I believe it's in the interests of most of IPv6 community if we 
develop IPv6 standards and techiques, which can be used in the most 
non-intrusive manner suitable.

v6ops charter is not limited to specifying standards, I believe.

> then please retract this statement.

They haven't done the enabling yet but support is there, so they're
afraid.
 
> All vendors shipping products have web pages and kits to install IPv6.

I didn't dispute this, and it wasn't the point.

> cases I am sure the chairs would love to hear them.

I already pointed out the operational problem here.

> ISPs are deploying IPv6 you simply don't know what your talking about.

You've no idea.

I have 4 hats:

1) ISP; we run a dual-stack STM-16 backbone, and believe me, I think I 
know full well about problems of ISP's
2) Home user; I use IPv6 at home using 6to4 etc. and have set up many such 
networks for others
3) Enterprise; I've designed and implemented IPv6 in several managed 
enterprise networks, and I'm currently managing one
4) Vendor; I do volunteer work for a vendor and have pretty much a say in 
all IPv6-related issues

With my ISP hat on, please don't try to be authorative of problems (or
lack of thereof)  in ISP networks.

> totally irrelevant to the building of standards.

I think it's our responsibility to react if we see problems with IPv6 
deployment.
 
> market or to those who have built and continuing to build IPv6 features

We have a very strong say in which standard we produce, and we don't need 
to produce more of those than we want to.

> the IETF will support you in.  This will not happen here.

We have the right to restrict our focus if we believe that's the best
thing to do.  Of course, we can't forbid people from doing something, but
we may document the way our proposed solution will work out.

> wait for the scenarios as everyone else is told. 

There are fundamental issues which affect all the transition scenarios.  
I believe we should try to figure out some answers to those; this is what
I noted in the meeting when the NAT-PT discussion turned to IMO critical
core issues.

> Why don't you work on

I believe I've contributed to all of the scenarios, it seems some of them 
are ignoring my contributions though.

Waiting for next revisions of the documents so I can keep on 
contributing...

> now and that is the big picture.

Some people have already deployed and noticed problems.

We need to make deployment scenarios that will work.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 25 Nov 2002 13:40:15 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

On Sun, Nov 24, 2002 at 11:46:45PM -0500,
 Bound, Jim <[email-masked]> wrote 

> then please retract this statement.

There was a discussion in Debian <URL:http://www.debian.org/> a while
ago and this issue was raised several times. Sorry, I do not find the
entry of the thread right now.
 
> ISPs are deploying IPv6 you simply don't know what your talking about.
...
> customer is using? 
...
> kill 90% of what you suggest as out of scope for this mail list and the

Such a reply to the perfectly reasonable and well-documented draft of
Pekka about the current IPv6 situation helps me to understand why the
IPv6 transition is so slow (I connected my employer to the 6bone in
1996 and I saw very little progress since). If all the IPv6 zealots
believe and act the same, IPv6 will stay a small island for many years
to come.

If you treat such concerns like you do and with words like this one,
we will soon only have trolls like Dan Bernstein to tell the simple
truth about IPv6.

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 25 Nov 2002 12:25:02 -0800

> with their operating systems either.

The IETF and vendors are not two separate entities. Vendors send people 
to participate in the IETF to help establish standards so we can all 
cooperate and release products that will work together. The IETF 
certainly can't tell any vendor what to do or what not to do in a 
product. That doesn't mean that vendors don't look to the IETF for 
suggestions. Suggestions on how to deploy IPv6 from the operating 
system perspective seem to be lacking. 6to4 looks like a good solution, 
but it doesn't work behind NAT. In addition, people in this working 
group have strongly advised against any wide deployment of 6to4 hosts.

Apple would like to ship a version of our operating system that does 
everything it can to get an IPv6 address. This would give our 
developers an opportunity to make use of IPv6. This strategy only works 
if we can figure out how to get IPv6 addresses to the majority of our 
customers. Solutions such as 6to4 and Teredo would allow us to achieve 
this goal. The vocal people in this working group say that 6to4 and 
Teredo are bad solutions. They rightly point out that the few 6to4 
relays will probably melt down or people will stop running them. In 
addition, there is no such thing as a Teredo relay deployed today. 
Teredo and 6to4 work well when there are many relays, which is not the 
case today.

We look to the IETF for a solution because we can't solve this problem 
alone. I get the impression from this working group that the working 
group is of the opinion that the transition mechanism will not work and 
we should just sit on our thumbs until the ISPs provide us IPv6 
connectivity.

> then please retract this statement.

We are concerned, I'm not sure I'd say afraid. We have shipped Mac OS X 
10.2, with support for IPv6. It isn't really well integrated yet, but 
it's there. It will assign link-local addresses, listen for routing 
advertisements, and assign addresses. This is fine because almost no 
one has IPv6 connectivity. We were considering turning on 6to4 by 
default when there are no routing advertisements. This working group 
has dissuaded us from doing so. If we did turn on 6to4, we would want 
to add some extra smarts to getaddrinfo to list IPv4 addresses first 
when 6to4 is in use to reduce the load on the relays. If we didn't 
modify getaddrinfos behavior, websites that used to work, may not work 
if the relays are down, or it may be very inefficient to communicate 
with such hosts since 6to4 could send the tunneled packets to a relay 
just about anywhere.

Based on feedback in this working group and some feedback at the recent 
IETF in Atlanta, we will probably not be working to get IPv6 
connectivity on all Mac OS X hosts.

> cases I am sure the chairs would love to hear them.

Why are these optional kits to install IPv6? If vendors really felt 
comfortable about IPv6, they would ship support built in to the product 
and it would be enabled by default. The fact is, very few people have 
IPv6 connectivity. IPv6 connectivity is the exception, not the rule.

> totally irrelevant to the building of standards.

Is there any evidence to suggest that IPv6 will some day make the move 
from testbed to wide deployment? The IETF has a huge amount to do with 
how quickly IPv6 moves from testbed to deployment. The IETF has drafts 
defining transition strategies. These transition strategies are 
important. Without them, IPv6 will never move on from test bed 
deployment. If people continue to ignore the transition problem and 
insult those who bring it up, perhaps IPv6 will go the way of OSI.

<SNIP>

> now and that is the big picture.

<sarcasm>Yes, scenarios are more important since people participating 
in the IETF will be building scenarios instead of products. After all, 
it doesn't matter that a something be implemented in a product so long 
as there's a scenario in which the protocol could be used.</sarcasm>

> kill 90% of what you suggest as out of scope for this mail list and the

Perhaps it is too early to be folding the ng-trans working group 
efforts in to v6-ops?

-josh

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 16:10:09 -0500

> Suggestions on how to deploy IPv6 from the operating 

I don't think there's consensus about that, only that there are some 
questions or problems associated with 6to4 on a host level that haven't
been fully resolved.  Personally I find "host 6to4" essential both to
provide access to machines at home (where a single host serves both
as an IPv4 presence and as a v6 router) and to allow me to access my 
v6 hosts from v4-only net connections.  I'm really disappointed that so
few host OSes support it.  For instance the lack of 6to4 support in 10.2
probably means I'll end up running NetBSD on my new 1Ghz powerbook g4.

> everything it can to get an IPv6 address. 

I'd love for MacOS to support 6to4, though I'm not sure that having
it automagically enabled is a good idea.  (there's such a thing as
a machine being too clever or having too high an opinion of its
own cleverness)

> The vocal people in this working group say that 6to4 and 
> relays will probably melt down or people will stop running them. 

6to4 works wonderfully if you have v4 connectivity (perhaps indirectly)
and are talking to other 6to4 sites.  if you want to talk to other sites
over v4, right now you generally need to set up an explicit tunnel for
that.  the anycast based relay routers don't work well enough to be used,
IMHO.  at least not right now.  attempts to talk to v6 sites typically
time out (which is annoying because the v6 addresses are tried first -
another thing which needs to be fixed)

> we should just sit on our thumbs until the ISPs provide us IPv6 

be assured that not everyone here shares that opinion.  IMHO we need
to define a host profile for 6to4, and perhaps another one for NAT boxes
that wish to support 6to4.  yes there are problems.  let's fix them.

> We were considering turning on 6to4 by 
> when 6to4 is in use to reduce the load on the relays. 

it turns out that you need the address ordering to be sensitive to both
network configuration and to the particular application.  some apps will
be v4 by default, others will be v6 default, others will be exclusively 
one or the other.

Keith

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 25 Nov 2002 13:25:23 -0800

> probably means I'll end up running NetBSD on my new 1Ghz powerbook g4.

6to4 does exist on Mac OS X 10.2. It just isn't integrated in to the 
user interface. If you run the command line (Terminal application), you 
can use the script ip6config to turn on 6to4 (i.e. sudo ip6config 
start-stf en0). 10.2 also comes with rtadvd for advertising routes. 
IPv6 support is in 10.2, it's just isn't available through the user 
interface.

-josh

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 25 Nov 2002 23:09:58 +0100

<SNIP>

> Teredo and 6to4 work well when there are many relays, which 
> is not the case today.

My opinion is certainly NOT that it is a _bad_ solution au contrair.
But you did want are to use it for the wrong thing.

> group is of the opinion that the transition mechanism will 
> not work and we should just sit on our thumbs until the ISPs provide
us IPv6 
> connectivity.

This is the right approach indeed. Discussing this with multiple
vendors and people who have experience in deployment already does
help find out what is going on.

IMHO for IPv6 to get a big push at this moment one needs two things:
 1) Application support.
 2) ISP support.

Application support is being worked on, many programmers change their
current IPv4-only applications to support IPv6 simply by using
getaddrinfo().

ISP support should be pushed by RIPE/ARIN/APNIC.
The APNIC and RIPE regions are working quite hard. Taking a look
at the ARIN region though makes me worry a bit.

> >> v6 by default, as connections could easily switch to using

6bone-mess is named 6bone mess as it's the mess of the 6bone.
The 6bone will fade away. RIR space will be left.
There are talks under a group of ISP's to clean up the RIR/6bone

> when 6to4 is in use to reduce the load on the relays.

Pekka mentioned a certain thing (prefer IPv4 over IPv6 dns queries).
This would lessen the use of IPv6 where it could be used IMHO.

Another approach to this is to test for IPv6 connectivity every N
times a month* or something like that and turn on the above feature.

*= ping6/connect to a certain host on the internet which is well
connected.
Eg "testforipv6.apple.com" :)

> If we didn't modify getaddrinfos behavior, websites that used to work,
may 
> not work if the relays are down, or it may be very inefficient to
communicate 
> > This is none of the IETFs businss or v6ops unless that 
> works points to 
> > a
> > the IETF's job not this diatribe you spew out here all to 
> often, that 
> > is
> > products.  But I don't agree and the chairs have made it 
> pretty clear 
> > we

Maybe in the US, but not in Europe and Asia! :)

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Nov 2002 11:02:51 +0100

To add to what Keith said, which I fully agree with, let's be clear
that 6to4 was invented as a supplementary mechanism, for the case where
a user site wants to support IPv6 and its ISP doesn't, and where for
whatever practical reason a configured tunnel or tunnel broker
solution isn't applicable. 6to4 shouldn't dominate the debate. It happens
to be the youngest of the techniques in the V6OPS charter, so it's no
surprise that it has open questions. That doesn't prevent it from
working.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 09:22:04 +0200 (EET)

On Mon, 25 Nov 2002, Keith Moore wrote:
[...]
> at least not right now.  attempts to talk to v6 sites typically

Do I sense this as a voice for support to modify or at least explore the 
current de-facto standard ordering?

> be v4 by default, others will be v6 default, others will be exclusively 

There are already some variables that affect this, namely:

 1) whether the DNS lookup produces A, AAAA, or both; ie "remote 
site configuration"

 2) what ordering for DNS records is used when both are used
(default is AAAA first everywhere I know, no possibility to change that)

 3) whether the application uses AF_INET, AF_INET6 or AF_UNSPEC
(with server apps, this is even a bit muddier.)

These help quite a bit, but I guess adding some getaddrinfo hint like
AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup
returns both addresses, you use AF_UNSPEC and you want to influence the
default DNS record ordering.

---

From: [email-masked]
Date: Wed, 27 Nov 2002 16:27:18 +0900

>default DNS record ordering.

	i don't think it wise to have flag bit - if you pass AI_PREFERV4
	you will stuck with IPv4 even when IPv6 provides much better
	connectivity, and the curse won't go away until you recompile.

	leave it to default address selection rule and logic in getaddrinfo(3).

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 09:32:51 +0200 (EET)

> 	connectivity, and the curse won't go away until you recompile.

That's still better than apps shipping with AF_INET or no getaddrinfo at 
all, right?
 
> 	leave it to default address selection rule and logic in getaddrinfo(3).

I'm not sure how default address selection, at least ones I've seen would
help with this.

Perhaps they don't implement _destination_ address selection.

---

From: [email-masked]
Date: Wed, 27 Nov 2002 16:38:04 +0900

>Perhaps they don't implement _destination_ address selection.

	they do.  see draft-ietf-ipngwg-default-addr-select-06.txt section 5.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Nov 2002 17:16:39 +0900

>>>>> On Wed, 27 Nov 2002 16:38:04 +0900, 
>>>>> [email-masked] said:

> 	they do.  see draft-ietf-ipngwg-default-addr-select-06.txt section 5.

Section 10.3 of draft-ietf-ipv6-default-addr-select-09.txt (this is
the latest draft I believe) may also help.  KAME snaps have
getaddrinfo considering the policy table and a tool to modify the
policy table.  I guess Windows XP support the feature, too.

Whether we should change the default is, of course, another issue.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Gert Doering <[email-masked]>
Date: Wed, 27 Nov 2002 09:50:43 +0100

Hi,

> default DNS record ordering.

In addition to that, provide a system configuration item that will
set the default preference in case the application doesn't specify
AI_PREFER*

Usually it's not something the application would care about, but more
the system administrator - "I want to have IPv6 but I do not trust it
enough to be the default" vs. "I know IPv6 is now working well enough".

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  50279 (49875)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 12:16:03 +0200 (EET)

> set the default preference in case the application doesn't specify

Yes, that could be the policy table (or my suggestion) actually 
implementing the toggle in the resolver, often in /etc/resolv.conf.
 
> enough to be the default" vs. "I know IPv6 is now working well enough".

Totally agree -- some apps can be exceptions though.

I want to be able to start enabling v6 by default, to build the user base, 
but I don't want it to cause _any_ ill effects to apps or the user yet.

Currently there is no way to do this, and I believe it's critical when we 
really want to deploy v6 to the masses.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Nov 2002 13:06:22 +0100

Pekka Savola wrote:

> Currently there is no way to do this, and I believe it's 
> critical when we really want to deploy v6 to the masses.

The OS or actually the resolver part of the OS should be able
to be configured with an option exactly like above.
Programs should _never_ have a preference, if they do they
should ask for an AF_INET or AF_INET6 that's enough preference already
:)
I am against having the AI_PREFER4/6 as this would be too program
specific and one needs to recompile to get it out.

The resolver could/should have a setting in f.e /etc/resolv.conf
or in the registry: "prefer AAAA,A" This would first try IPv6,
then IPv4. I think I once saw a discussion on the debian-ipv6
lists talking about such a mechanism which would be implemented
into the glibc resolver library.

One could also have a tool which periodically, say once a week,
or on-boot checks if there is a working IPv6 uplink. Eg by sending
a ping packet to a well known host by doing this in IPv4 and IPv6
this toggle could be flipped automatically. Ofcourse due to privacy
there should be an easy way to turn this off and to change the host.

Greets,
 Jeroen

---

From: Stig Venaas <[email-masked]>
Date: Wed, 27 Nov 2002 13:28:02 +0100

> to be configured with an option exactly like above.

Yes, that is a good idea.

> specific and one needs to recompile to get it out.

I agree, we really should avoid this. I think adding even more
complexity to getaddrinfo() is a bad idea. And not only does it
take time to deploy, but it might also be hard to change the
applications later. This is really something the sysadmin should
be able to choose, there is no default that fits all.

Stig

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 08:39:13 -0500

> current de-facto standard ordering?

I'm certainly going to change it on the machines that I use
(it helps that I have source code)
 
>  1) whether the DNS lookup produces A, AAAA, or both; ie "remote

I don't see how this affects ordering - if you don't get back A 
records are you going to put the AAAA records in a different
order relative to one another than if you do get them back?
 
> default DNS record ordering.

it's fairly easy for an app to reorder addresses that it gets back
between IPv4 and IPv6.  but I often find myself wanting to specify
a mixed preference like:

6to4 addresses
native IPv4
other IPv6

Keith

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 15:45:25 +0200 (EET)

> order relative to one another than if you do get them back?

Of course you're right -- the ordering described here is only relevant 
when both are used.

The point was that, because of current ordering, people don't really put 
v6 addresses in AAAA fields that much, so this is no problem (address 
resolves to either A or AAAA (under e.g. ipv6 subdomain)).

But we'd like it to be different..

> between IPv4 and IPv6.  but I often find myself wanting to specify

.. particularly if you use 6to4 addresses yourself; otherwise you really 
don't buy much by separating them from other v6.

> other IPv6

Yeah -- but that's something that we must not try to plug into every app 
-- it should really be done by lower layers (at least, by functions 
provided by lower layers).  No need to write the code 1000 times :-).

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 08:58:32 -0500

> provided by lower layers).  No need to write the code 1000 times :-).

personally I intend to rewrite the library routine so that it references
a config file that specifies preferred ordering.  eventually it might be 
nice if the host could get that preference list from the local network.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 16:53:12 +0200 (EET)

> be able to choose, there is no default that fits all.

There are more layers than that, e.g.

 - "if I have an app and install it anywhere at all, I have no way of 
knowing whether the system has implemented A,AAA preferation method -- so 
I'll just ship it with AF_UNSPEC + AI_PREFERV4, so people can run it with 
'app v6host', 'app -6 v46host' or 'app v46host' without problems, it'll 
always fall back to v4 if it doesn't know better"

 - "my app is special and is really only usable in v6 context; I'd prefer 
it to use v6 even though whatever's configured in A,AAAA preferation 
method. AF_UNSPEC + AI_PREFERV6 could handle that"

Ie. I'd like the app writers to be able to write "v6-safe" code.  Code 
that, when run or compiled on nearly any system, would produce code that's 
safe to be used in v4-preferring environments _regardless of_ whether the 
app user's box even has any A,AAAA preferation method.

But I can very well like with stuff like AI_PREFER* -- we just need the
toggle to change the ordering of A,AAAA records when using AF_UNSPEC ASAP,
if not yesterday.  If we could manage to get that deployed fast enough, 
and v4 preferred widely enough, perhaps in 1-2 years people could start 
shipping v6-enabled apps, waiting for the site admins decision to prefer 
v6 instead when they're confident enough to do so.

---

From: Craig Metz <[email-masked]>
Date: Wed, 27 Nov 2002 10:39:57 -0500

>current de-facto standard ordering?

  There is no specified standard, deliberately. This is an implementation
issue. Not all implementations have this problem, but many people on this list
don't seem to understand that and instead blame getaddrinfo() or blame IPv6.

>default DNS record ordering.

  NO! NO! NO!

  getaddrinfo is a PROTOCOL INDEPENDENT API. It is NEVER appropriate to cruft
ANY protocol-specific options into getaddrinfo. Protocol-specific hacks belong
in protocol-specific APIs. If the protocol-independent APIs do not give you
the features you want, then use the protocol-dependent APIs instead, which
will give you more specific controls.

  If an application wants to have getaddrinfo() return things in a particular
order, it should call getaddrinfo() multiple times in the order it wants, i.e.,
call it first for req.ai_addr=AF_INET, second for req.ai_addr=AF_INET6, etc.
HOWEVER, this behavior would be TOTALLY BROKEN as it first defeats protocol
independence (the whole point; if you're not using getaddrinfo in a protocol
independent way, why are you using it at all?), and second because it limits
you to IPv4 and IPv6.

  BSDI did this right. BSD/OS had a configurable resolver return order, I
believe through a file and an environment variable. Didn't like the system
default? Users can request things be done in a different order. Problem solved.

  I think BSDI gave their code to ISC for use in BIND, but it appears that
this feature got lost in the transition. Still, if someone with clues asked
the old BSDI folks nicely, you might be able to get their code for this and
fold it into your favorite implementation.

                                                                         -Craig

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 18:12:41 +0200 (EET)

> don't seem to understand that and instead blame getaddrinfo() or blame IPv6.

Yes, this is implementation specific.  But most do have this _operational_ 
_deployment_ _problem_.  And sitting on our thumbs does little to help 
with getting v6 out there.  I'd like to see it one day :-)
 
> will give you more specific controls.

I'm sorry to wake you up from the wonderland, but getaddrinfo has already
been encumbered with protocol-specific options (think AI_MAPPED..).

Whether anything can or should be salvaged is another issue..
 
> independent way, why are you using it at all?), and second because it limits

Right. (I prefer some deliberate ordering for AF_UNSPEC of course.)
 
> default? Users can request things be done in a different order. Problem solved.

That's nice, but as more folks haven't done it -- it helps little in this 
operational problem.

This is probably caused by the fact that most many not have considered
this problem serious at all, worth spending time on -- and there are many
strategies how v6 could be deployed, some of which aren't affected by the
lack of the option.  I believe it's our job to raise awareness on this.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Nov 2002 17:21:53 +0100

> always fall back to v4 if it doesn't know better"

It will currently always fall back to v4 if one wrote it correctly:
 - tries AAAA (if dns returned it)
 - tries A (if dns returned it)

> method. AF_UNSPEC + AI_PREFERV6 could handle that"

One should use AF_INET6 for that. And this is what currently happens.
But indeed if the resolver reorders A's in front of AAAA this doesn't
work anymore.
Then again the application can request a getaddrinfo() for AF_INET6 and
if those didn't connect go for the AF_INET addresses.
I don't think that there are many, even better name me 1, application
that would want to do it. Even though it could be a quite plausible
example one day. I don't think it will happen.

> app user's box even has any A,AAAA preferation method.

Ofcourse this should be true. And currently it nicely falls back
to v4. if the resolver doesn't support preferring they should
push their resolver coder to upgrade it. If people don't upgrade
reguraly they won't have IPv6 support anyways on most platforms

> But I can very well like with stuff like AI_PREFER* -- we 
> just need the toggle to change the ordering of A,AAAA records when
using 
> AF_UNSPEC ASAP, if not yesterday.
> If we could manage to get that deployed fast enough, 
> and v4 preferred widely enough, perhaps in 1-2 years people 
> could start shipping v6-enabled apps, waiting for the site admins 
> decision to prefer v6 instead when they're confident enough to do so.

IMHO the toggle should go into the resolver and NOT in the application.
If the application is specific enough to always request eg IPv6 then it
should do getaddrinfo(AF_INET6) and then fallback to
getaddrinfo(AF_INET).
As been said getaddrinfo is for AF independence if you depend on
something
request specifically that type of protocol.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Nov 2002 18:31:46 +0200 (EET)

>  - tries A (if dns returned it)

Sure.. but in this case www.google.com will not have AAAA records in,
well, about 5-10 years.  They have no incentive to do so, _at all_ --
quite the contrary -- as their v4-enabled users would get worse service.

Or many more such sites.

If try A first would be the option, www.google.com (etc.) folks would have 
_no_ reason not to put the AAAA record in www.google.com in a year or two.

But this is just v6 deployment strategy.  Both ways could work.. but it 
seems to me that we must go and take 1).

> example one day. I don't think it will happen.

This is a bit dubious case, I agree -- but e.g. future peer-to-peer, 
end-to-end applications could profit from trying v6 first, then falling 
back to v4 if necessary.
 
> to v4. 

You're missing the point.

> if the resolver doesn't support preferring they should
> push their resolver coder to upgrade it. 

A lot of pushing is needed, it seems.
 
> should do getaddrinfo(AF_INET6) and then fallback to

I kinda agree with this.

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 12:12:02 -0500

> will give you more specific controls.

you're absolutely correct.  thank you for saying that.

Keith

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Thu, 28 Nov 2002 02:37:40 +0900 (JST)

> quite the contrary -- as their v4-enabled users would get worse service.

This problem is NOT only ipv6 and/or getaddrinfo thing at all.
If one of IPv4 address on a DNS for a single FQDN were down, 
what would be happened?

(You might have recognized similar problem with h_addr_list[] in 
struct hostent{} :-))

What should be to blame is poor programming of application.

-- 
Hideaki YOSHIFUJI @ USAGI Project <[email-masked]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

---

From: Craig Metz <[email-masked]>
Date: Wed, 27 Nov 2002 11:46:10 -0500

>Whether anything can or should be salvaged is another issue..

  Last time I checked, AI_MAPPED was not a valid req.ai_flags argument to
getaddrinfo(), only to the IPv6-specific API getnodeinfo(). That was a
reasonable way to do things -- protocol independent APIs are protocol
independent, and protocol-specific features are available through protocol
specific APIs.

  Admittedly, the last time I checked was a long time ago, so I should check
to see whether there has been devolution in this way in the mean time.
 
>lack of the option.  I believe it's our job to raise awareness on this.

  Raising awareness is fine. But that twenty, thirty, forty emails on this
mailing list on this topic don't actually cause the changes to happen. A
polite email to your implementation's authors ("vendor") pointing out this
problem, pointing out how it was solved years ago, and pointing out where the
code might be freely available (I don't know that it is for certain, that's
a slightly informed speculation), would do far more good towards getting your
implementation to fix the problem.

  Now, I don't know whether there are security implications with this solution,
and expect that there are, but that they're problems we know how to deal with.

									-Craig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 28 Nov 2002 08:52:35 +0100

> What should be to blame is poor programming of application.

I think applications should try all addresses returned if necessary
to make a tcp connection. This solves the problem of unreachability
(except that it might take a while to establish a connection), but
you still have a problem that the IPv6 path might be poor.

Stig

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Thu, 28 Nov 2002 21:15:23 +0900 (JST)

> you still have a problem that the IPv6 path might be poor.

Each different "IP" performs differently from each other.
I believe what you need is some (dynamic) server selection 
method.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Nov 2002 08:01:39 -0500

> I believe what you need is some (dynamic) server selection

I believe what is needed is to stop relying so much on applications/hosts
choosing destination addresses.  Hosts should have as few addresses
as possible.  The network should make a best effort to deliver the traffic
to whatever address is used over the links permitted for such use.

---

From: Ronald van der Pol <[email-masked]>
Date: Thu, 28 Nov 2002 14:12:50 +0100

> we should just sit on our thumbs until the ISPs provide us IPv6 

I don't think you should sit on your thumbs. If you agree with the IETF
and believe IPv6 is the way to go, you should do your part. Otherwise,
everybody will wait for others. It would be good when OS and application
vendors shipped some nice IPv6 applications that would create end user
demand for IPv6.

> from testbed to wide deployment?

Yes, IPv6 is already widely deployed in research networks like WIDE,
6NET and Abilene. Remember how the IPv4 internet started? There are
also many internet exchanges that support IPv6. The commercial ISPs
will follow. Many have already got an IPv6 prefix from their RIR.

	rvdp

---

From: [email-masked]
Date: Thu, 28 Nov 2002 22:42:48 +0900

>will follow. Many have already got an IPv6 prefix from their RIR.

	IPv6 is not just in academia, also in commercial.  for instance:
	- 5+ ISPs in japan, more than 1 in sweden, and some other ISPs
	  offer commercial connectivity services
	- 25+ ISPs in japan offer experimental connectivity services
	- 50 IPv6 ASes are connected at NSPIXP6 (IPv6 IX in tokyo)
	- there are *at least* 1500 /48 sites in japan alone
	- at IIJ and WIDE we get lots of support calls/emails whenever there's
	  any routing issues or whatever - that means, people depends on
	  ipv6 network
	so it's a good sign.  i understand there are multiple chicken-and-egg
	problems (and it's irritating), but i'm sure it will get solved.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Nov 2002 17:51:54 +0200 (EET)

> 	  any routing issues or whatever - that means, people depends on

My take is that you really can't get reliably-ish v6 outside of Far East 
areas (excluding some regions with e.g. acedemic networks and some single 
companies).

That's not enough as lots of traffic does not go inside these regions.

The point of no return is when _global_ v6 works, not just within
(isolated) islands + some points of interconnections.

> 	problems (and it's irritating), but i'm sure it will get solved.

Do you consider AAAA records tried first (in some regions like US/Europe) 
a problem that needs solving?

---

From: Ronald van der Pol <[email-masked]>
Date: Thu, 28 Nov 2002 17:06:02 +0100

> a problem that needs solving?

No, because it is not a problem. The problem is bad routing. We should
fix that. As was pointed out earlier, when you have several A records,
one of them might be unreachable too by bad (v4) routing.

	rvdp

---

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Nov 2002 18:11:03 +0200 (EET)

On Thu, 28 Nov 2002, Ronald van der Pol wrote:

> fix that. 

_Can_ we fix that in some reasonable time?  I'm not so sure..

If we fix most of the IPv6 routing problems (doubtful) in 1-2 years, 
people can start start placing AAAA records in their main DNS zones in 2-4 
years.  Is that enough?

> As was pointed out earlier, when you have several A records,

So?  Bad IPv6 routing happens all the time, for about every non-local 
destination.  Bad IPv4 routing almost never happens.  They aren't 
comparable.

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Fri, 29 Nov 2002 01:30:28 +0900 (JST)

> destination.  Bad IPv4 routing almost never happens.  They aren't 

IPv6 routing is as stable as IPv4 routing.
Or, they're comparable at least.

What is "Bad routing," BTW?

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Nov 2002 11:58:05 -0500

> No, because it is not a problem. The problem is bad routing. 

I guess I disagree.  Yes, the problem is bad routing.  No, it's not
reasonable to assume that routing for v6 can be as good as or better  
than routing for v4 - at least not for many years.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Nov 2002 11:59:55 -0500

> That's not enough as lots of traffic does not go inside these regions.

I suspect we'll see 6to4 being used more often in regions where you can't
(yet) get reliable v6.   The problem then becomes how to get better 
interoperation between 6to4 and native v6.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Nov 2002 19:07:33 +0200 (EET)

> Or, they're comparable at least.

Perhaps in some restricted scope (it certainly is in our network and my 
home network in Finland), but not globally.
 
> What is "Bad routing," BTW?

draft-savola-v6ops-6bone-mess-01.txt

---

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Nov 2002 19:40:51 +0200 (EET)

> interoperation between 6to4 and native v6.

Well, this has a few problems.

If there is no good v6 support, it's very likely that the closest 6to4 
relay is also far away, thus causing extra RTT and instability.

And in many areas you _do_ get v6 -- via a tunnel or whatever -- and it 
seems to be preferred to 6to4 (I'd agree, but only to a degree).

So a rule of thumb "bad ipv6 connectivity or none at all -- use 6to4"  
doesn't probably hold.

---

From: Gert Doering <[email-masked]>
Date: Thu, 28 Nov 2002 18:44:53 +0100

Hi,

> Or, they're comparable at least.

Maybe in the APNIC region.  In the RIPE and ARIN region, IPv6 routing
is very much worse due to lots of "bad tunnels", ASes without proper
equipment giving full transit to everybody else, and so on.

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Nov 2002 13:07:00 -0500

> relay is also far away, thus causing extra RTT and instability.

depends on how well the relays are connected.  but yes, part of the
key to making 6to4<->native work better seems to be getting more
relays deployed.  either that or arranging for more tunnel endpoints.
is the latter easier than the former?
 
Keith

---

From: [email-masked]
Date: Fri, 29 Nov 2002 08:01:52 +0900

>a problem that needs solving?

	not at all.  and if your implementation supports default-addr-select
	policy table, you can tweak it (so the problem is fixed already).

itojun