Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

[itojun@iijlab.net]

>> 	d) obsolete AI_ADDRCONFIG.  AI_ADDRCONFIG semantics is too vague, and
>> 	way too difficult to specify (for instance, if you have IPv6 global
>> 	unicast address and no route, is it configured?).  also, even without
>> 	AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will
>> 	issue the right error).
>
>Agreed, that might be one option.
>
>Without the on-link assumption, the default route case should be rather
>simple, though.  You'd only have to look at the addresses.
>
>IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in
>dual-stack deployments where IPv6 connectivity is not yet enabled.  

	could you clarify what you meant by "dual-stack deployment"?  if it
	means "RA is sent by routers even though there's no glbal IPv6
	connectivity", that is a misconfiguration (outside of the issue w/
	AI_ADDRCONFIG).
	if it means "dual-stack host in IPv4-only network", it can live fine
	without AI_ADDRCONFIG.

>Of course, properly written apps would most probably also work there, but
>some apps are not properly written, but:
>
> - there are really misbehaving DNS servers out there, which jeopardize 
>your IPv4 service if you query for AAAA's, and

	this is a separate problem (this is not what AI_ADDRCONFIG cares about).

> - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA 
>queries

	this is a sane reason for keeping AI_ADDRCONFIG, but i doubt the
	roundtrip makes that much of difference.

> - maybe other considerations we haven't figured out / thought out yet.

	:-)

itojun