Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 21 Nov 2011 22:05:54 +0000

I agree Fred - not sure this is actionable for this I-D.

Thanks
Jason

PS - There are 2 or 3 other bits of feedback that I'll close out on this
I-D tomorrow.

On 10/14/11 2:29 PM, "Fred Baker" <[email-masked]> wrote:

>
>On Oct 14, 2011, at 11:19 AM, Lorenzo Colitti wrote:
>
>> One thing that happy eyeballs doesn't help you with is MTU holes.
>
>There are two obvious solutions to the PMTU problem: don't filter
>ICMP/ICMPv6, and
>
>https://tools.ietf.org/html/rfc4821
>4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner.
>     March 2007. (Format: TXT=75665 bytes) (Status: PROPOSED STANDARD)
>
>I'm in favor of both...
>
>Not sure what that has to do with AAAA Whitelisting.
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 22 Nov 2011 12:39:18 +0000

>
>On 2011-10-15 05:30, George, Wes wrote:
>...
>> I think this document is remiss in not mentioning Happy Eyeballs as
>>another method to prevent end-user impact due to impaired IPv6
>>connectivity.
>
>If that is added, I think a reference to RFC6343 is also appropriate.
>That contains specific advice to content providers about how to
>significantly mitigate one class of problems.

Agree with you both, Brian and Wes. I have added a reference to Happy
Eyeballs and to RFC 6343. This will be coming in the -08 version soon.

Thanks,
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 22 Nov 2011 13:23:34 +0000

Thanks for the feedback, Lorenzo. All of this will be factored into the –08 update shortly. Specific responses inline below.

- Jason

On 10/14/11 2:19 PM, "Lorenzo Colitti" <[email-masked]<mailto:[email-masked]>> wrote:

Agreed, the draft should mention happy eyeballs.

Ack. Done in the next version.

Actually, I think you’re missing an opportunity to clarify that in the cases where whitelisting is being done, the onus is on the domain doing the whitelisting to ensure that the servers being whitelisted represent a network that has proven to their satisfaction that they are IPv6-ready and this will not create unacceptable risk of poor service to the downstream users of the whitelisted server.

Yes, the draft doesn't say anything about how to measure this.

Sounds fine. Added a bit of text to address this in 4.3.
- JL