Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

From: Ray Hunter <[email-masked]>
Date: Fri, 06 May 2011 00:28:49 +0200

>
>
>
>
>
> On Thu, May 5, 2011 at 5:54 PM, Ray Hunter <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     Ahem...what IPv6 services are they using right now?  Seriously.
>     My company's web server, SSH, admin system, and SMTP mail service
>     already run native IPv6 dual stack, without aaaa whitelisting.
>
>
> I think that what Erik meant is that if you look at your favourite 
> list of most popular websites, you will find very few that are 
> IPv6-enabled.
Please note my replies are meant to be humorous & thought provoking, and 
not meant to be considered antagonistic.

I know exactly what he meant. Well my website is in my favorites. It 
also hosts a bugzilla server, a Twiki knowledge base, a bzr code 
repository (over SSH), and my webmail for when I'm travelling. I use it 
every day for work. A lot. It's important to me. I can't say the same 
about Altavista or whatever other newcomer search engine is popular with 
the kids these days, unless someone else placed it in my favorites list 
automatically. ;)

What I mean to say, although perhaps it was too subtle:

The whole concept of whitelisting is suspect as a general deployment 
methodology.

AAAA whitelisting may be good in general for the Internet if the few big 
sites that currently generate a lot of IPv4 traffic do it well and use 
it to aid in a transition to IPv6, but absolutely terrible for the 
Internet if the overall majority of sites deploy it.

If everyone employs DNS aaaa whitelists then nothing may ever 
transition, because he'll be testing my DNS and my aaaa whitelist 
authoritative server may reply with IPv4 only addresses to him (I 
haven't whitelisted him yet, so in his eyes it looks broken), and if I 
test his DNS he'll be replying with IPv4 only to me because my DNS quite 
obviously does not have any IPv6 content yet (even though it actually 
already has top level domain glue records in place), and no-one gets 
anywhere, because we have this continual stalemate of "why deploy IPv6 
because there's no traffic and IPv4 works just fine for me".

We all seriously need to start eating our own dog food, and I'm 
delighted to see such large players supporting World IPv6 day.

regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Tue, 17 May 2011 08:54:56 +0200

The following is a half baked idea (by my own admission), but I submit 
it just in case it triggers anyone to improve on it.

A number of threads on the v6ops list seem to be debating whether A 
records should be preferred over AAAA records or vice versa, or whether 
IPv6 should be preferred over IPv4, or some other transport or 
transition protocol, or whether filtering DNS records is a way to 
achieve this effect of achieving good connectivity. An alternative 
solution that has been suggested is to try to set up many sessions in 
parallel.

All of the solutions proposed today seem to assume that the node 
initiating the connection, or the node answering the DNS query, has to 
"solve" the prioritization / preference selection on their own, without 
much knowledge of the communicating party. So they make assumptions and 
come to a local decision, try it, and then fall back to an alternative, 
potentially leading to unhappy eyeballs.

Here's a "what if" to think about.

What if there were a specific DNS record type available, where an 
individual node, (or indeed entire net block) could publish their 
preferred connectivity scenarios in advance? Similar to publishing 
telnet options in advance so they don't need to be renegotiated during 
session establishment?

So as well as fetching an address record, nodes may also fetch a 
connection policy record (which could of course be locally cached as it 
is part of DNS).

Would this information on the remote nodes' / networks' preferences be 
useful input into the various address selection mechanisms running on 
the local node?

best regards,
RayH

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 29 May 2011 18:39:15 +0000

Hi John - Thanks for the detailed review. I'm planning a -04 update soon, FWIW.

Specific responses inline below.

Thx,
Jason

On 5/2/11 7:44 PM, "John Leslie" <[email-masked]<mailto:[email-masked]>> wrote:

Livingood, Jason <[email-masked]<mailto:[email-masked]>> wrote:
To: John Leslie <[email-masked]<mailto:[email-masked]>>...
As I read it, this says that certain DNS servers will be configured
to _not_ return AAAA records to AAAA queries by default.
This strikes me as a really-strange transition mechanism.
Depends on a number of factors for a content provider.

   Actually, no -- none of these factors make me feel it's any less than
_REALLY_ strange.

The more traffic a domain receives the more likely they are to consider
this practice as a transition mechanism from what I have observed.

   "Transition mechanism" is really-close to an oxymoron.

This practice can give a large domain some level of control in turning
on IPv6 access to their content, whereas they would lack this since
they would turn it on for everyone when publishing the AAAA RR in the
DNS.

   It doesn't give nearly as much control as they seem to think it does.
This blocks AAAA records, not based on the host interested in using them,
but based on some feature (IP address?) of the intermediate DNS resolver.

[JL] Quite so, and many in the WG feel it is difficult to use the resolver as a proxy for end use host IPv6-related impairment. Nevertheless, implementers feel it is good enough and the best available mechanism, and works reliably enough for their (temporary) use.

It's traditional to configure hosts to use two (or more) DNS resolvers
to mimimize the delays and disruptions.

   It will be very common for an end-host to alternate AAAA-requests
between one resolver which happens to be AAAA-blocked and another which
happens to be "whitelisted". I cringe in fear of taking the support
calls from such customers.

[JL] You and me both!!  ;-)

Once a comfort level and operational stability is achieved I would
expect most domains to move away from the practice, but that is TBD.

   I would expect a painful number of domains to forget it's there. :^(

[JL] Fair enough – which is why the 'risk of operational momentum' has been noted in the I-D. I don't know if it'll happen with this practice, but it would not be the first time that a temporary mechanism becomes a foundational one.

Certainly what happens on World IPv6 Day will bear on this question
in important ways (when AAAA RRs are published without the use of
DNS whitelisting).

   I predict a majority will turn off AAAA records for their regular
www.example.com on WorldIPv6Day+1.

[JL] To some extent this is expected — everyone will want to do some data analysis afterwards before they make a decision on what to do next. But certainly Heise Online (as cited in the I-D) and others feel the risk was low enough on their domains to go ahead and publish a AAAA RR. Every domain will be different and make the decision on their own.

   But that's OK: there are other ways to make progress.

   And the pressure should probably be applied to browser-software writers,
so that when an end-user finds himself IPv6-impaired, he can simply shift
to a different browser,

    Color me thoroghly confused.
Hopefully that's more over the practice than the document;

   Indeed, I _am_ more confused by the practice than the document.

   But the document is confusing enough! What does it encourage me to
_do_?

[JL] Suggest I simplify the document, I'm sure. ;-) I've made some effort to do this for the –04 version based on all the feedback on –03. I'm also planning a top-to-bottom simplification after the –04.  So, point well-taken.    :-)

if you wish to see improvements in the I-D just say so.

   Personally, I wish you'd do a nearly-global

s/DNS whitelisting/AAAA-blocking/

   It's a much more descriptive term.

[JL] The naming of the practice is noted as an Open Item in the draft, so I'll be discussing that with the WG chairs.

   Also, I'd appreciate less of "this solve a transition problem" and
more of "this doesn't even do what the folks seem to think it does".

   It's arguably reasonable to AAAA-block to DNS resolvers whose
managers ask for it; but it's not at all reasonable to AAAA-block by
default. IMHO, it would be better to tell folks that ask you to
AAAA-block to switch to resolver software that can AAAA-block to
certain end-users. After all, the problem _isn't_ localized on the
DNS resolver.

   And the document does nothing to help me figure out what to do to
enable a venturesome customer to _use_ IPv6 to a site that turns on
this AAAA-blocking!

   :^( :^(

[JL] All good feedback – thanks!

Jason

--
John Leslie <[email-masked]<mailto:[email-masked]>>