Re: [v6ops] draft-ietf-v6ops-v6-aaaa-whitelisting-implications-00

["Livingood, Jason" <[e-mail]>]

Brian - Replies inline below and cc'ing the v6ops list since this is now a
WG I-D. The changes you have suggested below will be made shortly in a -01
update of this draft.

Thanks for your feedback!
- Jason


On 10/19/10 5:06 PM, "Brian E Carpenter" <[e-mail]>
wrote:

>Hi Jason,
>
>Thanks for writing this. A couple of comments:
>
>> 7.3.6.  Additional Implications If Deployed On An Ad Hoc Basis
>
>Well, how about
>
>  1. Scaling (and manual updates). The cost and error-proneness
>     seem very high, especially as you get nearer to...
>
>  2. When at least half of the Internet is white-listed, do you
>     flip over to black-listing the other half, and then...
>
>  3. What is the exit strategy? Do you just declare victory and switch
>     the whole mechanism off one day?

[JL] Great suggestions - I have added the following text to that section:
Additional implications, should this be deployed on an ad hoc basis, could
include scalability problems relating to operational processes,
monitoring, and ACL updates. In particular, it seems quite likely that as
the number of domains that are whitelisted increases, as well as the
number of IPv6-capable networks requesting to be whitelisted, that there
is an increased likelihood of configuration and other operational errors,
especially with respect to the ACLs themselves. It is also unclear when
and if it would be appropriate to change from whitelisting to
blacklisting, and whether/how this could feasibly be coordinated across
the Internet, which may be proposed when a majority of networks (or
allocated IPv6 address blocks) have been whitelisted. Finally, some
parties implementing DNS whitelisting consider this to be a temporary
measure. As such, it is not clear how these parties will judge the network
conditions to have changed sufficiently to justify disabling DNS
whitelisting and/or what the process and timing will be in order to turn
off and stop this practice.

>
>> 8.3.1.  Solving Current End User IPv6 Impairments
>
>This would IMNSHO be a much more productive use of effort.

[JL] Quite so!  I have added this text at the end of that section:
Despite any potential challenges, many in the Internet community are
already working towards this goal and/or have expressed a preference for
this approach.

>
>...
>> 
>>    One challenge with this option is the potential difficulty of
>>    motivating members of the Internet community to work collectively
>>    towards this goal, sharing the labor, time, and costs related to such
>>    an effort.  Of course, since just such a community effort is now
>>    underway for IPv6, it is possible that this would call for only a
>>    moderate amount of additional work.
>
>Yes, and when people see that solving this issue is in their own
>self-interest, it may turn out to be considered essential work anyway.
>
>> 
>>    [EDITORIAL: More to add?]
>
>Yes. We need to be specific about the root causes of the loss of sessions.
>For example, for 6to4 clients, it is often the case that the IPv6 server's
>ISP is not providing a route to 2002::/16 that leads to a 6to4 relay
>willing
>to relay traffic. It's in the enlightened self interest of every ISP that
>has content providers as customers to provide such a relay. Have they been
>told? And so on for each of the root causes.
>
>This needs work; just throwing your hands up and saying "too hard!" isn't
>OK. 
>
>The other thing to add is to encourage the "happy eyeballs" approach.

[JL] There are a lot of potential root causes. I'm still a bit conflicted
on whether they should be covered in this I-D or a different one. I'll
note this as an open issue for later.

Thanks again!
Jason