>> 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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
