Re: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt

[Ray Hunter <[e-mail]>]

I've followed progress of this document over various versions and IMHO 
you're doing a great job.

I have no major comments, but quite a lot of detailed editorial comments 
/ nits, included below.

Editorial Comments
===============

re: Title.
A slightly alternative way of looking at this operationally: is this not 
simply about Information Security and "Risk Mitigation Whilst 
Transitioning Content To IPv6"?

Operations people should be well used to that via Prince 2, ITIL, and 
other methodologies.
It's not "daunting": It's just another transformation project, where 
business risks need to be managed.

My take on an alternative title: s/Transitioning Content to IPv6/Risk 
Mitigation Whilst Transitioning Content To IPv6/


Section 4.1: If we mention [W6D], should we not also mention [v6ops] ?

Normally for risk mitigation, you'd introduce a table of potential risks 
cross-referenced to the potential/selected mitigation tactics. You've 
done this  descriptively already within the subsections, but a summary 
table might prove enlightening/useful.


Section 4.3.1-4.3.4:
/ When implemented on an automated basis in the future, DNS recursive 
resolvers listed in the whitelist could expand and contract dynamically/

Is this defined anywhere as a WG item? Otherwise would suggest s/When/If/

I have a concern with automation of whitelisting and potential DNS 
content instability as different providers implement uncoordinated 
changes on a "near-real-time basis", which could lead to some serious 
traffic flip-flopping at mega scale (IPv6 detected as stable -> IPv6 DNS 
record added -> IPv6 load increases -> link/device/network saturates -> 
IPv6 impairment (just 0.078% loss) -> IPv6 record deleted -> 
link/device/network stable -> IPv6 detected as stable)

 From the perspective of a remote (feeder) network this is NOT like 
global server load balancing of IPv4, where the traffic to other ISP 
peers may change, but the peering point will probably anyway be 
physically co-located at the same GIX, so traffic patterns _within_ the 
remote feeder network probably won't be greatly impacted any more than 
say a local BGP peering failure. DNS A->AAAA record changes could 
trigger use of a completely different network path, equipment, or 
peering, and so may even impact traffic flows within the feeder network.


Section 4.3.4 "Split DNS" Add a reference to BIND "view" configuration 
command?


/ DNS Blacklisting is also likely less labor intensive for a domain than 
performing DNS Resolver Whitelisting on a manual basis./

Is there any basis or evidence for this statement? Otherwise s/is also 
likely less/may be less/


I see no reference to the risk of assuming a "do nothing" tactic and 
staying with IPv4 for as long as possible, or a mitigation tactic of 
relying on others to provide IPv6 to IPv4 translation somewhere else 
outside of your domain as its "not my problem." That's always option one 
and two on any risk management plan, and the preferred/default option of 
many managements. You could well argue it's out of scope, but a pointer 
to an existing document would be nice.


nits
====

Section 2
s/Challenges When Transitioning Content to IPv6/Risks When Transitioning 
Content to IPv6/

Section 3
s/Challenges/Risks/

Section 4
s/Potential Migration Tactics/Potential Risk Mitigation Tactics/ ???

whole document
s/migration tactics/risk mitigation tactics/

s/there is not one approach/there is no single prescriptive approach/
s/in Section 2.1 
<http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08#section-2.1>. 
One challenge/in Section 2.1 
<http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08#section-2.1>, 
one challenge/
s/ the potential solutions [I-D.ietf-v6ops-happy-eyeballs 
<http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08#ref-I-D.ietf-v6ops-happy-eyeballs>]/the 
potential solutions e.g. [I-D.ietf-v6ops-happy-eyeballs 
<http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08#ref-I-D.ietf-v6ops-happy-eyeballs>]/
s/turning on a significant amount of IPv6 traffic is quite daunting and 
would carry a relatively high risk of network/turning on a significant 
amount of IPv6 traffic may carry a relatively high risk of network/
s/used to facilitate the migration to IPv6/used to mitigate risks during 
migration to IPv6/
s/key tactics/key risk mitigation tactics/
s/Use IPv6-Specicic Names/Use IPv6-Specific Names/
s/recursive resolver is, etc./recursive resolver is, and any other 
operational impacts./
s/These authoritative DNS servers selectively return AAAA resource 
records using the IP address of the DNS recursive resolver that has sent 
it a query/These authoritative DNS servers selectively return AAAA 
resource records or not, dependent on the IP address of the DNS 
recursive resolver that has sent it a query/
s/and an A record would be sent/any A resource records associated with 
the name WILL be sent/
s/However, if a DNS recursive resolver is matched in the whitelist, then 
AAAA resource records WILL be sent/However, if a DNS recursive resolver 
is matched in the whitelist, then AAAA resource records WILL be sent 
(any A resource records associated with the name MAY still be sent)/
s/manually-based/manually-maintained/

/Similarities to Content Delivery Networks and Global Server Load 
Balancing/ something odd with the formatting here. /Balancing/ is 
outside the HTML <span> tag.

s/cannot send email to a domain at all, with DNS Resolver 
Whitelisting/cannot send email to a domain at all, with DNS Resolver 
Blacklisting/

s/It is then up to end users with IPv6-related impairments to discover 
and fix any applicable impairments./The onus is then on end users with 
IPv6-related impairments to discover and fix any applicable impairments 
themselves. The advantage of this approach being that IPv6-related 
impairments should reduce over time, rather than being worked around ad 
infinitum./

s/Finally, the tactics listed in Section 4 are by no means 
exclusive./Finally, the tactics listed in Section 4 are by no means 
exclusive, nor exhaustive./

s/contact end userd directly concerning/contact end users directly 
concerning/

regards
RayH