Subject: Re: how to mitigate misbehavior agains AAAA

From: Mohacsi Janos <[email-masked]>
Date: Tue, 7 Sep 2004 11:34:09 +0200 (CEST)

On Tue, 7 Sep 2004, Pekka Savola wrote:

> Sorry for not responding earlier..
>
> On Wed, 1 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
>>>> One really weird case where AI_ADDRCONFIG would be the only solution
>>>> is that the host performing getaddrinfo hasn't configured global IPv6
>>>> addresses and DNS queries for AAAA resource records cause serious
>>>> problem like the ones documented in
>>>> draft-ietf-dnsop-misbehavior-against-aaaa-01.txt.  However, we
>>>> basically think we can only solve this by fixing and upgrading the
>>>> broken servers, rather than by an introducing additional hack in the
>>>> host implementation.
>>
>>> But from the practical point of view, do you see this happening fast
>>> enough to suit the IPv6 deployment?  Remember that we have experienced
>>> the same issue with ECN: it has been PS for 3 years or so, and even
>>> now it hasn't been generally turned on because it causes the users to
>>> see breakage.
>>
>>> So, IMHO it would make sense to think *real* hard whether there are
>>> reasonable ways to work around this particular problem
>>> (draft-ietf-dnsop-ipv6-issues points out a couple of possibilities,
>>> e.g., firing off the queries in parallel or after e.g. 1 sec if there
>>> is no response, etc.)
>>
>>> At least, this issue should not affect the users who don't use IPv6
>>> (IMHO), so a solution like AI_ADDRCONFIG seems to be called for.
>>
>> If the work around can be a complete solution, even if it's ad-hock, I
>> agree that it's worth considering.  I also tend to agree that your
>> suggestion of the parallel query plus short timeout can be considered
>> as this type of work around.
>
> Yep.
>
>> My point on AI_ADDRCONFIG was that it cannot be a complete solution to
>> the AAAA misbehavior issue since it doesn't help in the case where we
>> have IPv6 connectivity.
>
> It seems like a good solution for the case where you want to deploy
> dual-stack -enabled nodes which would not necessarily get IPv6
> connectivity (e.g., nodes, which wouldn't activate 6to4, Teredo, or
> the like automatically, but just wait for native IPv6).
>
> The good side of using something like AI_ADDRCONFIG would be that the
> vendors would be less reluctant to enable IPv6 by default if you
> wouldn't even try to look up the v6 records (causing potential
> problems) *until* you get v6 connectivity.
>
> Remember, it's of utmost importance to be able to *safely* deploy
> *IPv6 capability*, even if that capability would not be used
> immediately...
>
> However, AI_ADDRCONFIG would need to be enabled by default (like with
> sysctl -- the RFC is unclear with this when it describes something
> like "AI_DEFAULT" but doesn't say more on that -- it's not clear
> whether that's assumed to be the default setting) for that to work,
> because otherwise all the apps would need to be modified which seems
> too late now...

Hi Pekka and all,

 	Sorry for cross-posting, but I think this discussion can take place 
most appropriately on v6ops mailing list.

 	I completely agree with you in ideas e.g. deploying dual stacked 
hosts as much as possible (by default!).

- I would leave AI_ADDRCONFIG as defined RFC3493.
- I would insist on proper implementation of Default Address 
Selection for IPv6 (RFC3484) on all dual-stacked hosts.

You could have different types of operation:
1. IPv6 not configured -> IPv6 not preferred:
 	old-fashioned IPv4 only operation

2. IPv6 configured + IPv4 preferred:
AI_ADDRCONFIG - says configured, so you get IPv6 address records, but the 
connection is done via IPv4 even if the remote host have IPv6 address 
records. End user could experiment with IPv6 locally or remotely if they 
prefer. - RFC 3484 is very flexible.

3. IPv6 configured + IPv6 preferred:
The user has decent IPv6 connectivity. IPv6 connectivity is preferred.

I would implement the configuration the following way in the 
operating system installation process:

1. - Ask for IPv6 configuration of interfaces.
2. - Ask for IPv6 preference to IPv4. I would warn the administrator, that 
they need good IPv6 connectivity if they prefer IPv6 to IPv4 (Asking ISPs 
etc....)

Unfortunately this does not solve the the problem of misbehaving DNS 
servers against AAAA query.

The other problem is, that you will lose some principle of dual-stack 
operation:
- When you are dual stacked IPv6 preferred over IPv4 to promote IPv6.

I think IPv6 community got into a troublesome situation:
- IPv6 host implementations are there - they are very good
- IPv6 router implementations are there - they are good
- There hardly any IPv6 network that support endusers (some exceptions at 
the academic and research communities). ISPs are very reluctant to 
implement IPv6....- Some good examples are (WIDE, 6NET, EURO6IX, GEANT and 
Internet2). 
- Some end-users are already eager to use IPv6 - see the popularity of 
different Tunnel-Broker services. But most of them are don't care: they 
want to use service regardless of underlying protocol (IPv4 or IPv6, or 
"homing pigeon carrying the packets...")

Regards,

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98