On 3/31/10 4:55 PM, "Dan Wing" <dw...@cisco.com> wrote:
>> On Wed, 31 Mar 2010, Dan Wing wrote:
>>
>> :: Users running IE6 today are IPv4-only users. If/when they go
>> :: to IPv6, they will be running Windows 7 and whatever browser
>> :: is shipped by Microsoft.
>>
>> Why do you say that? As far as I know, IE6 is an ipv6-capable
>> browser,
>> as long as it's going to FQDN's.. So, what about IE6/XP users who
>> installed bittorent clients (or spyware/trojans) that enabled
>> ipv6 for them without the user knowing about it?
>
> Yes, thanks for correcting me.
>
> I agree they will have a poor experience (due to Teredo).
>
> But Remi's point is that those same systems (running Windows XP
> and IE6) using 6rd will be denied the ability to access content
> via IPv6. Which removes an incentive for ISPs to add 6rd (and
> offload the NAT44 they may soon have to install).
>
[jjmb] this is true, this would be an issue for Free users that do not have
native IPv6. Free users that have native IPv6 connectivity would be fine,
however.
>> :: It seems solvably operationally, by asking ISPs to point their
>> :: IPv4-only subscribers at an ISP-operated DNS server which
>> :: purposefully breaks AAAA responses (returns empty answer), and
>> :: to point their dual-stack subscribers at an ISP-operated DNS
>> :: server which functions normally.
>> ::
>> :: Advanced IPv4-only users wanting to do AAAA queries (e.g.,
>> :: Teredo users, 6to4 users, etc.) should be sufficiently advanced
>> :: to point themselves at the ISP's normal nameserver or a
>> :: public DNS server on the Internet (e.g., Hurricane
>> :: Electric's, Google's, etc.). That won't affect users running
>> :: uTorrent (which uses Teredo to provide IPv6 connectivity)
>> :: because it doesn't do AAAA queries to find peers.
>>
>> This is *exactly* what we are proposing -- the feature to
>> return empty
>> answers would be needed for ipv4-only subscribers in order to
>> keep them
>> ipv4-only. Also, if a fully ipv6-capable user visits that
>> person's home,
>> the recursor would then be able to make the call on if they
>> should pass
>> through AAAA to that particular user or not... I am by no
>> means advocating
>> to make this behavior a default, just a feature.
>
> I'm saying this should be do-able entirely within the ISP's
> DNS, without coordination or involvement with the content
> provider's DNS.
>
> For example, imagine the ISP's nameserver has a new "allow-aaaa-response"
> option that would be configured like:
>
> #
> # list IPv4 addresses that are known to have real IPv6 connectivity.
> # (e.g., this is all of the ISP's subscribers that are also
> # connected using 6rd).
> #
> acl aaaa_whitelist { 172.16.72.0/24; 192.168.1.0/24; };
> ...
>
> options {
> ...
> allow-aaaa-response { aaaa_whitelist };
> ...
> }
[jjmb] So this would require the authoritative DNS servers of the content
providers to globally be advertising AAAA RR rights? What if IPv4 only
users are configured to use the same recursive name servers that IPv6
capable users are, we are back to points that have been made earlier related
to operational challenges, etc. What you describe above also looks a lot
like what what proposed during DNSOPs with the exception that it is assumed
that AAAAs are being advertised globally, right?
>
> Which should work until there is DNSSEC validation built into the subscriber's
> DNS client.
[jjmb] this would be problematic with DNSSEC, this has been acknowledged.
>
> I believe this is effectively what Nicholas described in
> http://www.ietf.org/mail-archive/web/dnsop/current/msg08339.html
>
> -d
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozow...@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
