On Wed, 31 Mar 2010, Dan Wing 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).
Yes, absolutely, and Remi's recursive DNS servers don't need to turn this
feature on. Similarly, I, as a content provider don't need to whitelist
his DNS recursive servers to receive AAAA if doing so would break too many
users. However, if there are no broken IPv4 users behind Remi's recursors,
then there is absolutely no need for him to use this feature, and I would
be happy to give him AAAA replies when I'm ready to do so, and everybody
is happy..
:: > :: 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.
:: > ::
:: > 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 };
:: ...
:: }
This is *exactly* what I'm proposing -- all my presentation does is
document this as a feature and describes how it will work (the switch is
actually "disable-aaaa-on-v4-transport")... The content provider's DNS may
or may not then independently whitelist the ISP recursive servers that the
users are behind, depending on breakage stats. If the breakage stats are
sufficiently low for that content provider not to bother with the
whitelist, so much the better -- the whole point of advocating for this
feature is to allow us to get to that point.
So, I think the 2 of us are in complete agreement here.. the only question
is if you do this for all users, a subset of them, or none at all, and
that's going to be up to every individual ISP to do what is right for
them.. I'm merely trying to document the behavior and functionality of
this feature, and let people know that it will be available to them if
they choose to use it to help with the breakage during the transition.
Thanks,
-igor
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
