Subject: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

From: The IESG <[email-masked]>
Date: Wed, 01 Feb 2012 07:09:11 -0800

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Considerations for Transitioning Content to IPv6'
  <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> as an
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-02-15. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes considerations for the transition of end user
   content on the Internet to IPv6.  While this is tailored to address
   end user content, which is typically web-based, many aspects of this
   document may be more broadly applicable to the transition to IPv6 of
   other applications and services.  This document explores the
   challenges involved in the transition to IPv6, potential migration
   tactics, possible migration phases, and other considerations.  The
   audience for this document is the Internet community generally,
   particularly IPv6 implementers.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/

No IPR declarations have been submitted directly on this I-D.

---

From: Erik Kline <[email-masked]>
Date: Fri, 3 Feb 2012 11:57:23 +0900

World IPv6 Launch changes the relevance of this document greatly, I
think.  Since this would be published after the announcement of World
IPv6 Launch, I think the document should be updated to discuss its own
applicability in a post- World IPv6 Launch Internet.

On 2 February 2012 00:09, The IESG <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Feb 2012 04:56:08 +0000

I think that although the draft mainly discusses aaaa-whitelisting, it can be more specific in section 2 on issues impacting content delivery over ipv6.

Perhaps the biggest challenge in the IPv4-to-IPv6 transition is that the two protocols are not compatible; that is, IPv4-only systems cannot talk directly to IPv6-only systems. This means no one can turn off IPv4 support until every last device they want to reach has acquired IPv6 connectivity. Unfortunately, many existing devices — including PCs running older OSes, as well as older cable and DSL modems, wireless routers, and other business and consumer electronic devices—have either limited or no IPv6 support. In other words, companies will have to support both protocols for years to come, in a long and bumpy transition period. During that time, there will effectively be two Internets, an IPv4 one and an IPv6 one, loosely bound together into a hybrid Internet by various transition technologies.

Challenges of reaching IPv6 users from IPv4 sites
Many types of Web applications rely on an end-to-end connection, where each device, household, or entity is associated with a single IP address. CGN breaks this assumption — as it creates a situation where hundreds or thousands of end users — related only by their network provider — share the same IP address, and each user’s IP address may change with every new connection. Thus, CGN cripples functions like geo-location — using the user’s IP address to determine their location, in order to personalize content or to enforce licensing restrictions, for example, and abuse mitigation — IP blacklisting or whitelisting, in order to block spammers, trolls, or other abusive users.
CGN   breaks assumptions that many of today’s Web applications rely on. In particular it affects applications, such as peer-to-peer and VoIP, which rely in some way on a unique end user IP address. Troubleshooting the issues is extremely complex and costly, as it can’t be done without the NAT operator’s help.
In order to reach IPv4 sites, IPv6 end users need to go through a NAT64 gateway. Because there may be only one or two such gateways within a network, communications may be forced through long, indirect paths. In addition, these gateways quickly become congestion points within the network, as well as easily targeted points of failure, further affecting the performance and reliability.

Challenges of reaching IPv6 users from IPv6 sites
Because the IPv6 Internet is still sparsely connected, native IPv6 communications may require longer, less direct routes than their IPv4 counterparts, resulting in slower performance and higher packet loss. This is particularly troublesome for high throughput or low latency applications such as online gaming or streaming media. In addition, a significant portion of the IPv6 Internet currently relies on tunneling traffic over IPv4, creating additional performance degradation.

So I think that content providers and application providers are no longer pondering when to enable delivery over  IPv6 but are focused on how to manage this transition in a manner that is cost-effective and efficient in the short term but takes into account long-term needs and opportunities.

Sent from my iPad

On Feb 2, 2012, at 7:05 PM, "Erik Kline" <[email-masked]<mailto:[email-masked]>> wrote:

On 2 February 2012 00:09, The IESG <[email-masked]<mailto:[email-masked]>> wrote:

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2012-02-15. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Feb 2012 08:35:36 -0800

> applicability in a post- World IPv6 Launch Internet.

With respect...

The document was originally discussed in v6ops, and you chose to not comment. It went through last call there in January 2011 and was sent to the IESG. IESG review took until April, and an updated draft was posted at the end of May 2011. At IETF 81 (Quebec City) we were able to have you, the author, and some others discuss it. The IESG again decided it needed a revised draft, and that draft - in large part, a rewrite - arrived in October. v6ops had a second WGLC, in which you again declined to comment, although you may have seen Lorenzo's comments, which were picked up in a November version of the draft. Ralph and Jari finally cleared their "discuss" ballots a couple of weeks ago, and we are having a second IETF last call.

I'd like to understand your objective here. I know that you don't care for the draft, and at least at one point took it as a somewhat-personal attack. Is your objective to prevent the draft's publication entirely, or do you think that there is value in publishing it given a productive response to this comment? At what point are you willing to either participate in the public dialog or choose to not comment at all?

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Erik Kline <[email-masked]>
Date: Sat, 4 Feb 2012 10:43:19 +0900

> I'd like to understand your objective here. I know that you don't care for the draft, and at least at one point took it as a somewhat-personal attack. Is your objective to prevent the draft's publi…

With humblest apologies...

Having spent time rereading, I think W6L is clearly an implementation
of  sections 4.5 and 5.7, or 4.4 and 5.6, depending on the
implementer.

Additionally, in retrospect, there's probably no great reason to add a
reference to a future event.  It seems to me that the most meaningful
technical observation that can actually be offered would be its
scheduled calendar date.

There's no excuse for my failing to reread afresh before commenting.
Again, my apologies,
-Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Feb 2012 22:54:31 +0900

On Sat, Feb 4, 2012 at 01:35, Fred Baker <[email-masked]> wrote:

> The IESG again decided it needed a revised draft, and that draft - in
> large part, a rewrite - arrived in October. v6ops had a second WGLC, in
> which you again declined to comment, although you may have seen Lorenzo's
> comments, which were picked up in a November version of the draft. Ralph
> and Jari finally cleared their "discuss" ballots a couple of weeks ago, and
> we are having a second IETF last call.
>
> I'd like to understand your objective here. I know that you don't care for
> the draft, and at least at one point took it as a somewhat-personal attack.
> Is your objective to prevent the draft's publication entirely, or do you
> think that there is value in publishing it given a productive response to
> this comment? At what point are you willing to either participate in the
> public dialog or choose to not comment at all?

Ok, let me see if I can rephrase Erik's objection.

The draft needs to take World IPv6 Launch into account, because it's a key
piece of the puzzle.

We can't publish an RFC on how to transition content to IPv6 if the RFC
ignores the event when 5 of the top 10 websites in the world (and probably
many more) will permanently enable IPv6 for everyone.

Cheers,
Lorenzo

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 08 Feb 2012 07:36:54 -0800

On 2/8/12 05:54 , Lorenzo Colitti wrote:
> On Sat, Feb 4, 2012 at 01:35, Fred Baker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     The IESG again decided it needed a revised draft, and that draft -
>     in large part, a rewrite - arrived in October. v6ops had a second
>     WGLC, in which you again declined to comment, although you may have
>     seen Lorenzo's comments, which were picked up in a November version
>     of the draft. Ralph and Jari finally cleared their "discuss" ballots
>     a couple of weeks ago, and we are having a second IETF last call.
> 
>     I'd like to understand your objective here. I know that you don't
>     care for the draft, and at least at one point took it as a
>     somewhat-personal attack. Is your objective to prevent the draft's
>     publication entirely, or do you think that there is value in
>     publishing it given a productive response to this comment? At what
>     point are you willing to either participate in the public dialog or
>     choose to not comment at all?
> 
> 
> The draft needs to take World IPv6 Launch into account, because it's a
> key piece of the puzzle.
> 
> ignores the event when 5 of the top 10 websites in the world (and
> probably many more) will permanently enable IPv6 for everyone.

Ops is not marketing.

If you're saying some flag day makes the contents of the document no
longer operationally relevant after a given date, I'll take the point
but disagree.

The document in it's present form has a wider audience than the
operators at 5 of the ton 10 websites.

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Feb 2012 08:02:54 -0800

What specifically would you like changed in the draft? Can you suggest text? 

On Feb 8, 2012, at 5:54 AM, Lorenzo Colitti wrote:

> The IESG again decided it needed a revised draft, and that draft - in large part, a rewrite - arrived in October. v6ops had a second WGLC, in which you again declined to comment, although you may have seen Lorenzo's comments, which were picked up in a November version of the draft. Ralph and Jari finally cleared their "discuss" ballots a couple of weeks ago, and we are having a second IETF last call.
> 
> The draft needs to take World IPv6 Launch into account, because it's a key piece of the puzzle.
> 
> We can't publish an RFC on how to transition content to IPv6 if the RFC ignores the event when 5 of the top 10 websites in the world (and probably many more) will permanently enable IPv6 for everyone.
> 
> Cheers,
> Lorenzo

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Feb 2012 08:05:48 +1100

In message <[email-masked]>,
> many more) will permanently enable IPv6 for everyone.

World IPv6 day just means Google is at 5.5 now and will go to
5.6/5.7.  It really does not change anything.  The decision to
whitelist is a subjective one, not a objective one.  Similarly the
decision to stop whitelisting is also a subjective one.

While I, and I suspect most of the list, think that whitelisting
should no longer be needed that isn't our call to make.  All we can
do is encourage people to not whitelist by running dual stack
services without using whitelisting.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Feb 2012 18:25:02 +0900

> Ops is not marketing.

And if I were looking for a marketing venue, a standards body that produces
ASCII text documents read by a handful of engineers would not be high on my
list. This is not about marketing.

> longer operationally relevant after a given date, I'll take the point

I think you're missing my point.

It seems to me that approximately 30% of the non-biolerplate text in this
draft discusses DNS whitelisting. (And in fact, in its original form the
draft entirely on DNS whitelisting - hence the filename. The rest was added
later.)

Whitelisting is a practice relevant to a few large websites (since nobody
else is using it). It so happens that the websites that employ this
practice are going to stop using it, all together. Given the cost and
implications, I'd say practice is unlikely to be resurrected.

So, you decide to tell the whole story, and talk about whitelisting *and*
World IPv6 Launch. Or you can decide that whitelisting will soon be
irrelevant, and not talk about either whitelisting or World IPv6
Launch. But you can't talk about whitelisting without talking about World
IPv6 Launch, because if you do, your document is missing the key piece "how
do you remove the whitelist", and that's a disservice to its readers.

To be more specific, at least section 5.5 ("it is unclear how implementers
will judge when the network conditions will have changed sufficiently to
justify turning off DNS Resolver Whitelisting and/or what the process and
timing will be for discontinuing this practice") is now incorrect. It *is*
clear, and it's what those implementers are doing as part of World IPv6
Launch.

Does that make more sense?

Cheers,
Lorenzo

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 12 Feb 2012 20:25:10 -0800

On 2/9/12 01:25 , Lorenzo Colitti wrote:
> On Thu, Feb 9, 2012 at 00:36, Joel jaeggli <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Ops is not marketing.
> 
> 
> And if I were looking for a marketing venue, a standards body that
> produces ASCII text documents read by a handful of engineers would not
> be high on my list. This is not about marketing.
>

Sorry for being so droll, I found it hard to restrain myself.

> It seems to me that approximately 30% of the non-biolerplate text in
> this draft discusses DNS whitelisting. (And in fact, in its original
> form the draft entirely on DNS whitelisting - hence the filename. The
> rest was added later.)
> 
> Whitelisting is a practice relevant to a few large websites (since
> nobody else is using it). It so happens that the websites that employ
> this practice are going to stop using it, all together. Given the cost
> and implications, I'd say practice is unlikely to be resurrected.

I do not belive that the selective (inclusive) return of A or A + AAAA
records on the basis of source address is likely to end on a particular
day. It may well for you and some others, which is fine, or you may find
it necessary again, or it may become a list of exclusions rather than
inclusions. I belive you're on record indicating as much. In any event
others may find it necessary.

> So, you decide to tell the whole story, and talk about whitelisting
> *and* World IPv6 Launch. Or you can decide that whitelisting will soon
> be irrelevant, and not talk about either whitelisting or World IPv6
> Launch. But you can't talk about whitelisting without talking about
> World IPv6 Launch, because if you do, your document is missing the key
> piece "how do you remove the whitelist", and that's a disservice to its
> readers.
> 
> To be more specific, at least section 5.5 ("it is unclear
> how implementers will judge when the network conditions will have
> changed sufficiently to justify turning off DNS Resolver Whitelisting
> and/or what the process and timing will be for discontinuing this
> practice") is now incorrect. It *is* clear, and it's what those
> implementers are doing as part of World IPv6 Launch.

Invidual service operators like you and I are likely to make decisions
on the basis of our instrumentation, we may well alter their behavior on
a uni or multilateral basis, and some of us may do so for world ipv6
launch. ipv4/v6 Transition is not something with a flag day however, and
I do not believe that the concerns embedded in the draft will be
fundamentally altered on 6/6/12.

> Does that make more sense?

yes, that doesn't imply that we're in concert however.

---

From: "Marc Lampo" <[email-masked]>
Date: Mon, 20 Feb 2012 15:32:00 +0100 (CET)

Hello,

(sorry to be late with my comments, bit overloaded on my side)

6.1 Security Considerations - paragraph 2 (on DNSSEC)
The text states : "there should not be any negative impact on DNSSEC"
In my opinion, this is *wrong* :

It is correct that, if an AAAA record exists (in a DNSSEC's zone),
the appropriate RRSIG will be known to authoritative NS's.
If, via white listing, the decision is taken not to present the AAAA
record
(and its signature), this seems OK.

However : not returning an AAAA record seems identical to : there is no
AAAA record.
And that - there is no AAAA record - yields to "Next Secure" changes !
If no AAAA record exists, for a name, the corresponding NSEC (NSEC3)
record
should not hold a reference to AAAA.
But if that AAAA record does exist, the authoritative NS will have NSEC
(NSEC3)
data that shows so.

A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due to
whitelisting
will not be returned), cannot be proven by accompanying (and required)
NSEC (NSEC3)
information.
Hence : this draft will/might make DNSSEC validating name servers fail.

If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in
detail,
please observe :
1) the caching name server (and "stub resolver") ask 2 queries
    (there is only one line,
     but it are two queries : one for "A", one for "AAAA")
2) if the caching name server (or stub resolver) performs DNSSEC
validation,
    it will never accept a reply of "NODATA" to the query of AAAA
    (because the NSEC (NSEC3) information will not prove that
non-existance)
    ((and the validating name server will repeat the query to all
      authoritative NS's, looking for a validatable answer))

(the final result, to the user might be that only the A record is useable
 - mission accomplished ?
 But the side effect will be that validating caching name servers will hit
  *all* authoritative servers for the domain,
  "in search of" a correctly validating answer.)

So, while for the end-user, the result might be identical,
one "security impact" of this approach is
additional (useless) DNS traffic and
additional load on authoritative NS's (that implement whitelisting)

Kind regards,

Marc Lampo
Security Officer
EURid

-----Original Message-----
From: The IESG [mailto:[email-masked]] 
Sent: 01 February 2012 04:09 PM
To: IETF-Announce
Cc: [email-masked]
Subject: [v6ops] Last Call:
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt>
(Considerations for Transitioning Content to IPv6) to Informational RFC

Abstract

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl
ications/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl
ications/

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 20 Feb 2012 10:18:36 -0500

Marco,

The IESG has already approved this drat for publication. However, I think that your comment is significant if you can make a case that the DNS information returned to the user is less trustworthy than it would have been had the authoritative DNS not been practicing whitelisiting. Can you make this case?

                                                Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marc Lampo
> Sent: Monday, February 20, 2012 9:32 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-
> implications-08.txt> (Considerations for Transitioning Content to IPv6)
> to Informational RFC
> 
> Hello,
>

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 20 Feb 2012 17:02:16 +0100 (CET)

> The IESG has already approved this drat for publication.  However, I
> think that your comment is significant if you can make a case that
> the DNS information returned to the user is less trustworthy than it
> would have been had the authoritative DNS not been practicing
> whitelisiting.  Can you make this case?

"Less trustworthy" would be an imprecise euphemistic term to use in
this case.  Instead, the returned data would fail cryptographic
validation as performed by DNSSEC, and would therefore be discarded as
invalid ("incorrect") by a DNSSEC-validating resolver.

Therefore, it would seem to me that you can either do AAAA
whitelisting or DNSSEC, but not successfully do both.

Regards,

- Håvard

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Feb 2012 07:48:42 +1100

One can whitelist with DNSSEC at the source.  It just requires
having two nsec/nsec3 chains if the zone is signed.  One with AAAA
records in the bit map field and one without.  There are a number
of ways to implement this.  It's just a matter of returning consistent
answers.

In named this can be done with views.

	view "aaaa" {
		match-clients {
			key aaaa; !key noaaaa;
			whitelist;
		};
		zone "example.com" {
			type master;
			file "aaaa/example.com.signed";
		};
	};

	view "noaaaa" {
		match-clients {
			key noaaaa; !key aaaa;
			!whitelist; any;
		};
		zone "example.com" {
			type master;
			file "noaaaa/example.com.signed";
		};
	};

If you want to whitelist in the resolver, then DO=1 + signed AAAA
disables whitelisting.  There is no point when the client can detect
that it is happening.  This is what we did for filter-aaaa in named.

In message <[email-masked]>, Havard Eidnes writes:
> - H=E5vard

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 20 Feb 2012 13:57:58 -0800

> In my opinion, this is *wrong* :

IMHO the following applies.

if you have one zone yeah I agree.

If you have two zones one with aaaa and one without (assuming this is
done with dns views style implementation) you can sign both and they'll
both be valid and complete from the vantage point of a client which
resolves one or the other of them but not both.

this is a traditional split horizon problem. it's just not inside/outside.

joel

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Feb 2012 09:45:20 +1100

> resolves one or the other of them but not both.

It will still valid and complete even if you ask both servers. The
answer just won't be deterministic.  The important thing is that
the DNSKEY RRset holds all the DNSKEY records in use.  Note you can
sign the zone with different DNSKEYs.

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 20 Feb 2012 17:55:28 -0500

Marc, Havard,

Are you satisfied with the answers provided by Joel and Mark?

                                     Ron

> Of EXT - [email-masked]
> Sent: Monday, February 20, 2012 4:58 PM
> To: Marc Lampo
> Cc: [email-masked]

---

From: "Marc Lampo" <[email-masked]>
Date: Tue, 21 Feb 2012 08:02:31 +0100 (CET)

Hello,

I had assumed : 1 zone file (and Mark Andrews correctly pointed at
"views").

Would adding this piece of information, directly in the RFC,
be useful to avoid confusion for future readers ?

Thanks and kind regards,

Marc Lampo

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]] 
Sent: 20 February 2012 11:55 PM
To: EXT - [email-masked]; Marc Lampo
Cc: [email-masked]
Subject: RE: [v6ops] Last Call:

Marc, Havard,

                                     Ron

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 21 Feb 2012 08:44:11 -0500

Authors,

What do you think?

                Ron

> From: Marc Lampo [mailto:[email-masked]]
> Sent: Tuesday, February 21, 2012 2:03 AM
> To: Ronald Bonica; EXT - [email-masked]
> Cc: [email-masked]
> Subject: RE: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-
> > > However : not returning an AAAA record seems identical to : there
> is
> > no
> > > AAAA record.
> > > And that - there is no AAAA record - yields to "Next Secure"
> changes
> > !
> > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but
> due
> > to
> > > whitelisting
> > >    document may be more broadly applicable to the transition to
> IPv6
> > of

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 21 Feb 2012 19:44:51 +0000

On 2/20/12 4:57 PM, "Joel jaeggli" <[email-masked]<mailto:[email-masked]>> wrote:
IMHO the following applies.

If you have two zones one with aaaa and one without (assuming this is done with dns views style implementation) you can sign both and they'll both be valid and complete from the vantage point of a client which resolves one or the other of them but not both.

Exactly, which is one of the reasons section 4.3.4 is there (Similarities to Split DNS). This is two zones (or 'views' of the zone data). Both can be signed.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 21 Feb 2012 19:46:48 +0000

Good idea and it is quick & easy edit. Making the change now. Will send text momentarily.

Jason

On 2/21/12 8:44 AM, "Ronald Bonica" <[email-masked]<mailto:[email-masked]>> wrote:

Authors,

What do you think?

                Ron

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: 20 February 2012 11:55 PM
To: EXT - [email-masked]<mailto:[email-masked]>; Marc Lampo
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [v6ops] Last Call:
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf
> Of EXT - [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
is
changes
due
> > Cc: [email-masked]<mailto:[email-masked]>
IPv6

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 21 Feb 2012 14:51:03 -0500

Jason,

Please post the most recent version of the draft. If I hear no objections by COB Friday, I will send that version on to the RFC editor for publication.

                                                                                               Ron

From: Livingood, Jason [mailto:[email-masked]]
Sent: Tuesday, February 21, 2012 2:45 PM
To: EXT - [email-masked]; Marc Lampo; Ronald Bonica
Cc: [email-masked]
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 21 Feb 2012 19:54:38 +0000

I made this addition in the relevant section (6.1). Let me know if it does not capture this sufficiently (or does so inelegantly).

Thanks
Jason

In practical terms this means that two separate views or zones are used, each of which is signed, so that whether or not particular resource records exist, the existence or non-existence of the record can still be validated using DNSSEC.

On 2/21/12 2:46 PM, "Livingood, Jason" <[email-masked]<mailto:[email-masked]>> wrote:

Jason

Authors,

What do you think?

                Ron

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: 20 February 2012 11:55 PM
To: EXT - [email-masked]<mailto:[email-masked]>; Marc Lampo
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [v6ops] Last Call:
Behalf
is
changes
due
IPv6

_______________________________________________ v6ops mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 22 Feb 2012 10:20:16 +0100 (CET)

Hello,
(my time zone implies I see your replies only “the next day”)

1) I assume one cannot, in this RFC, elaborate too much on how
“aaaa-whitelisting”
can be implemented, so I can live with this sentence (though "view" is a
term
from the Bind implementation, other implementations might use different
wording).

2) regarding the previous sentence :
"So even though an authoritative DNS server will selectively return
 AAAA resource records and/or A resource records,
 these resource records can certainly still be signed."

In this context - assuming we are talking about a signed domain with
chain-of-trust
appropriately in place - I'd propose :
"So even though an authoritative DNS server will selectively return
 AAAA resource records and/or A resource records,
 these resource records must be signed,
 as well as any accompanying NextSecure information
 that proves existence and/or not-existence of AAAA resource records."

So :
-> it's a *must*
-> it's not only the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs.

Kind regards,

Marc Lampo
Security Officer
EURid (for .eu)

From: Livingood, Jason [mailto:[email-masked]]
Sent: 21 February 2012 08:55 PM
To: Ronald Bonica; Marc Lampo; EXT - [email-masked]; Mark Andrews
Cc: [email-masked]
Subject: Re: [v6ops] Last Call:
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt>
(Considerations for Transitioning Content to IPv6) to Informational RFC

I made this addition in the relevant section (6.1). Let me know if it does
not capture this sufficiently (or does so inelegantly). 

Thanks
Jason

In practical terms this means that two separate views or zones are used,
each of which is signed, so that whether or not particular resource
records exist, the existence or non-existence of the record can still be
validated using DNSSEC. 

On 2/21/12 2:46 PM, "Livingood, Jason" <[email-masked]>
wrote:

Good idea and it is quick & easy edit. Making the change now. Will send
text momentarily.

Jason

On 2/21/12 8:44 AM, "Ronald Bonica" <[email-masked]> wrote:

Authors,

What do you think?

                Ron

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: 20 February 2012 11:55 PM
To: EXT - [email-masked]; Marc Lampo
Cc: [email-masked]
Subject: RE: [v6ops] Last Call:
is
changes
due
IPv6

_______________________________________________ v6ops mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Havard Eidnes <[email-masked]>
Date: Wed, 22 Feb 2012 12:58:03 +0100 (CET)

> One can whitelist with DNSSEC at the source.

I stand corrected, thanks.

Regards,

- Håvard

---

From: Havard Eidnes <[email-masked]>
Date: Wed, 22 Feb 2012 13:05:30 +0100 (CET)

> Are you satisfied with the answers provided by Joel and Mark?

I am.

Regards,

- Håvard

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 23 Feb 2012 13:06:52 +0000

On 2/22/12 4:20 AM, "Marc Lampo" <[email-masked]<mailto:[email-masked]>> wrote:
2) regarding the previous sentence :
"So even though an authoritative DNS server will selectively return
AAAA resource records and/or A resource records, these resource records can certainly still be signed."

In this context - assuming we are talking about a signed domain with chain-of-trust appropriately in place - I'd propose :
"So even though an authoritative DNS server will selectively return
AAAA resource records and/or A resource records, these resource records must be signed, as well as any accompanying NextSecure information that proves existence and/or not-existence of AAAA resource records."

Great suggestion, thank you for suggesting actual text! Correction to that sentence made and will publish momentarily in a –10.

- Jason

So :
-> it's a *must*

Kind regards,

Marc Lampo
Security Officer
EURid (for .eu)

To: Ronald Bonica; Marc Lampo; EXT - [email-masked]<mailto:[email-masked]>; Mark Andrews

Thanks
Jason

On 2/21/12 2:46 PM, "Livingood, Jason" <[email-masked]<mailto:[email-masked]>>
wrote:

Jason

Authors,

What do you think?

                Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf
Of EXT - [email-masked]<mailto:[email-masked]>
Sent: Monday, February 20, 2012 4:58 PM
To: Marc Lampo
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-
whitelisting-
implications-08.txt> (Considerations for Transitioning Content to
IPv6)
to Informational RFC

If you have two zones one with aaaa and one without (assuming this is
done with dns views style implementation) you can sign both and
they'll
both be valid and complete from the vantage point of a client which
resolves one or the other of them but not both.

this is a traditional split horizon problem. it's just not
inside/outside.

joel

is
no
changes
!
due
to
IPv6
of

_______________________________________________ v6ops mailing list
[email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 23 Feb 2012 10:22:10 -0500

Folks,

I will allow the dust to settle for another 24 hours and then send the draft on for publication.

                                                                        Ron

From: Livingood, Jason [mailto:[email-masked]]
Sent: Thursday, February 23, 2012 8:07 AM
To: Marc Lampo; Ronald Bonica; EXT - [email-masked]; 'Mark Andrews'
Cc: [email-masked]
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

Great suggestion, thank you for suggesting actual text! Correction to that sentence made and will publish momentarily in a -10.

- Jason

So :
-> it's a *must*

Kind regards,

Marc Lampo
Security Officer
EURid (for .eu)

Thanks
Jason

Jason

Authors,

What do you think?

                Ron

-----Original Message-----

joel

is
no
changes
!
due
to
IPv6
of

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2012 07:50:42 +1100

So even though an authoritative DNS server will
   selectively return AAAA resource records and/or A resource records,
   these resource records must be signed, as well as any accompanying
   NextSECure (NSEC) information that proves existence and/or not-
   existence of AAAA resource records.

		   So even though an authoritative DNS server will
   selectively return AAAA resource records or a non existance
   response both types of response will be signed and will validate.
   ("non existance" covers both name error responses and NOERROR
   no data responses depending apon the presence or absence of data
   other than AAAA records at the name.  Usually there will be at least
   a A records so one would expect a NOERROR no data.)

In message <[email-masked]>, Ronald Bonica writes:
> --_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> Folks,
> 
> I will allow the dust to settle for another 24 hours and then send the draf=
> t on for publication.
> 
>                                                                         Ron
> 
> 
> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-impl=
> ications-08.txt> (Considerations for Transitioning Content to IPv6) to Info=
> rmational RFC
> 
> On 2/22/12 4:20 AM, "Marc Lampo" <[email-masked]<mailto:marc.lampo@eur=
> id.eu>> wrote:
> AAAA resource records and/or A resource records, these resource records can=
>  certainly still be signed."
> 
> In this context - assuming we are talking about a signed domain with chain-=
> of-trust appropriately in place - I'd propose :
> AAAA resource records and/or A resource records, these resource records mus=
> t be signed, as well as any accompanying NextSecure information that proves=
>  existence and/or not-existence of AAAA resource records."
> 
> Great suggestion, thank you for suggesting actual text! Correction to that =
> sentence made and will publish momentarily in a -10.
> 
> - Jason
> 
> 
> 
> So :
> -> it's a *must*
> To: Ronald Bonica; Marc Lampo; EXT - [email-masked]<mailto:[email-masked]=
> om>; Mark Andrews
> On 2/21/12 2:46 PM, "Livingood, Jason" <[email-masked]<m=
> ailto:[email-masked]>>
> wrote:
> 
> On 2/21/12 8:44 AM, "Ronald Bonica" <[email-masked]<mailto:rbonica@jun=
> iper.net>> wrote:
> 
> Authors,
> 
> What do you think?
> 
>                 Ron
> 
> From: [email-masked]<mailto:[email-masked]> [mailto:v6ops-b=
> [email-masked]] On
> Behalf
> > [email-masked]<mailto:[email-masked]> mailing lists by 2012-02-15. Exceptio=
> nally, comments
> may be
> > sent to [email-masked]<mailto:[email-masked]> instead. In either case, plea=
> se retain the
> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo=
> /v6ops
> 
> 
> --_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
> osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
> //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
> =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
> oft Word 12 (filtered medium)"><style><!--
> /* Font Definitions */
> @font-face
> 	{font-family:"Cambria Math";
> 	panose-1:2 4 5 3 5 4 6 3 2 4;}
> @font-face
> 	{font-family:Calibri;
> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
> 	{font-family:Tahoma;
> 	panose-1:2 11 6 4 3 5 4 4 2 4;}
> @font-face
> 	{font-family:Consolas;
> 	panose-1:2 11 6 9 2 2 4 3 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman","serif";}
> a:link, span.MsoHyperlink
> 	{mso-style-priority:99;
> 	color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{mso-style-priority:99;
> 	color:purple;
> 	text-decoration:underline;}
> span.apple-style-span
> 	{mso-style-name:apple-style-span;}
> span.EmailStyle18
> 	{mso-style-type:personal-reply;
> 	font-family:"Calibri","sans-serif";
> 	color:#1F497D;}
> .MsoChpDefault
> 	{mso-style-type:export-only;
> 	font-size:10.0pt;}
> @page WordSection1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 1.0in 1.0in 1.0in;}
> div.WordSection1
> 	{page:WordSection1;}
> --></style><!--[if gte mso 9]><xml>
> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
> <o:shapelayout v:ext=3D"edit">
> <o:idmap v:ext=3D"edit" data=3D"1" />
> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
> nk=3Dpurple style=3D'word-wrap: break-word;-webkit-nbsp-mode: space;-webkit=
> -line-break: after-white-space'><div class=3DWordSection1><p class=3DMsoNor=
> mal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo=
> r:#1F497D'>Folks,<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'=
> font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nb=
> sp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;fo=
> nt-family:"Calibri","sans-serif";color:#1F497D'>I will allow the dust to se=
> ttle for another 24 hours and then send the draft on for publication.<o:p><=
> /o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-f=
> amily:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
> class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sa=
> ns-serif";color:#1F497D'>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;Ron<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11=
> .0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></s=
> pan></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"C=
> alibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div style=
> =3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><di=
> v><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0i=
> n 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-fam=
> ily:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt;=
> font-family:"Tahoma","sans-serif"'> Livingood, Jason [mailto:Jason_Livingoo=
> [email-masked]] <br><b>Sent:</b> Thursday, February 23, 2012 8:07 AM<b=
> r><b>To:</b> Marc Lampo; Ronald Bonica; EXT - [email-masked]; 'Mark Andre=
> ws'<br><b>Cc:</b> [email-masked]<br><b>Subject:</b> Re: [v6ops] Last Call: =
> &lt;draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt&gt; (Consider=
> ations for Transitioning Content to IPv6) to Informational RFC<o:p></o:p></=
> span></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p=
>  class=3DMsoNormal><span class=3Dapple-style-span><span style=3D'font-famil=
> y:Consolas;color:black'>On 2/22/12 4:20 AM, &quot;Marc Lampo&quot; &lt;<a h=
> ref=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span=
> ></span><span style=3D'font-family:"Calibri","sans-serif";color:black'><o:p=
> ></o:p></span></p></div></div><blockquote style=3D'border:none;border-left:=
> solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-rig=
> ht:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal=
> ><span style=3D'font-family:Consolas;color:black'>2) regarding the previous=
>  sentence :<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span styl=
> e=3D'font-family:Consolas;color:black'>&quot;So even though an authoritativ=
> e DNS server will selectively return<o:p></o:p></span></p></div><div><p cla=
> ss=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>AAAA resour=
> ce records and/or A resource records,&nbsp;these resource records can certa=
> inly still be signed.&quot;<o:p></o:p></span></p></div><div><p class=3DMsoN=
> ormal><span style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></s=
> pan></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas=
> ;color:black'>In this context - assuming we are talking about a signed doma=
> in with&nbsp;chain-of-trust&nbsp;appropriately in place - I'd propose :<o:p=
> ></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-famil=
> y:Consolas;color:black'>&quot;So even though an authoritative DNS server wi=
> ll selectively return<o:p></o:p></span></p></div><div><p class=3DMsoNormal>=
> <span style=3D'font-family:Consolas;color:black'>AAAA resource records and/=
> or A resource records,&nbsp;these resource records must be signed,&nbsp;as =
> well as any accompanying NextSecure information&nbsp;that proves existence =
> and/or not-existence of AAAA resource records.&quot;<o:p></o:p></span></p><=
> /div></blockquote><div><p class=3DMsoNormal><span style=3D'color:black'><o:=
> p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'col=
> or:black'>Great suggestion, thank you for suggesting actual text! Correctio=
> n to that sentence made and will publish momentarily in a &#8211;10.<o:p></=
> o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'color:black'>=
> <o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'=
> color:black'>- Jason<o:p></o:p></span></p></div><div><p class=3DMsoNormal><=
> span style=3D'color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'color:black'><o:p>&nbsp;</o:p></span></p></div>=
> <blockquote style=3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0i=
> n 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTR=
> IBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal><span style=3D'font-family:Co=
> nsolas;color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNo=
> rmal><span style=3D'font-family:Consolas;color:black'>So :<o:p></o:p></span=
> ></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;co=
> lor:black'>-&gt; it's a *must*<o:p></o:p></span></p></div><div><p class=3DM=
> soNormal><span style=3D'font-family:Consolas;color:black'>-&gt; it's not on=
> ly the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs.<o:p></o:p></span></p=
> ></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:=
> black'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span st=
> yle=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p></div>=
> <div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>=
> Kind regards,<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span st=
> yle=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p></div>=
> <div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>=
> Marc Lampo<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>Security Officer<o:p></o:p></span></p=
> ></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:=
> black'>EURid (for .eu)<o:p></o:p></span></p></div><div><p class=3DMsoNormal=
> ><span style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span><=
> /p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;colo=
> r:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span =
> style=3D'font-family:Consolas;color:black'>From: Livingood, Jason [<a href=
> =3D"mailto:[email-masked]">mailto:Jason_Livingood@cable.=
> comcast.com</a>]<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span=
>  style=3D'font-family:Consolas;color:black'>Sent: 21 February 2012 08:55 PM=
> <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-f=
> amily:Consolas;color:black'>To: Ronald Bonica; Marc Lampo; EXT - <a href=3D=
> "mailto:[email-masked]">[email-masked]</a>; Mark Andrews<o:p></o:p></sp=
> an></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;=
> color:black'>Cc: <a href=3D"mailto:[email-masked]">[email-masked]</a><o:p><=
> /o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:=
> Consolas;color:black'>Subject: Re: [v6ops] Last Call:<o:p></o:p></span></p>=
> </div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:b=
> lack'>&lt;draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt&gt;<o:p=
> ></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-famil=
> y:Consolas;color:black'>(Considerations for Transitioning Content to IPv6) =
> to Informational RFC<o:p></o:p></span></p></div><div><p class=3DMsoNormal><=
> span style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p=
> ></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:=
> black'>I made this addition in the relevant section (6.1). Let me know if i=
> t does<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'=
> font-family:Consolas;color:black'>not capture this sufficiently (or does so=
>  inelegantly).&nbsp;<o:p></o:p></span></p></div><div><p class=3DMsoNormal><=
> span style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p=
> ></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:=
> black'>Thanks<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span st=
> yle=3D'font-family:Consolas;color:black'>Jason<o:p></o:p></span></p></div><=
> div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'><=
> o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'f=
> ont-family:Consolas;color:black'>In practical terms this means that two sep=
> arate views or zones are used,<o:p></o:p></span></p></div><div><p class=3DM=
> soNormal><span style=3D'font-family:Consolas;color:black'>each of which is =
> signed, so that whether or not particular resource<o:p></o:p></span></p></d=
> iv><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:blac=
> k'>records exist, the existence or non-existence of the record can still be=
> <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-f=
> amily:Consolas;color:black'>validated using DNSSEC.&nbsp;<o:p></o:p></span>=
> </p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;col=
> or:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span=
>  style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p></d=
> iv><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:blac=
> k'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p></div><di=
> v><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>On =
> 2/21/12 2:46 PM, &quot;Livingood, Jason&quot; &lt;<a href=3D"mailto:Jason_L=
> [email-masked]">[email-masked]</a>&gt;<o:p><=
> /o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:=
> Consolas;color:black'>wrote:<o:p></o:p></span></p></div><div><p class=3DMso=
> Normal><span style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></=
> span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consola=
> s;color:black'>Good idea and it is quick &amp; easy edit. Making the change=
>  now. Will send<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span =
> style=3D'font-family:Consolas;color:black'>text momentarily.<o:p></o:p></sp=
> an></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;=
> color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><s=
> pan style=3D'font-family:Consolas;color:black'>Jason<o:p></o:p></span></p><=
> /div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:bl=
> ack'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span styl=
> e=3D'font-family:Consolas;color:black'>On 2/21/12 8:44 AM, &quot;Ronald Bon=
> ica&quot; &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a=
> >&gt; wrote:<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span sty=
> le=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p></div><=
> div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>A=
> uthors,<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D=
> 'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p></div><div><=
> p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>What d=
> o you think?<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span sty=
> le=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p></div><=
> div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&=
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp;Ron<o:p></o:p></span></p></div><div><p class=3DMsoNorma=
> l><span style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span>=
> </p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;col=
> or:black'>-----Original Message-----<o:p></o:p></span></p></div><div><p cla=
> ss=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>From: Marc =
> Lampo [<a href=3D"mailto:[email-masked]">mailto:[email-masked]</a=
> >]<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font=
> -family:Consolas;color:black'>Sent: Tuesday, February 21, 2012 2:03 AM<o:p>=
> </o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family=
> :Consolas;color:black'>To: Ronald Bonica; EXT - <a href=3D"mailto:joelja@bo=
> gus.com">[email-masked]</a><o:p></o:p></span></p></div><div><p class=3DMs=
> oNormal><span style=3D'font-family:Consolas;color:black'>Cc: <a href=3D"mai=
> lto:[email-masked]">[email-masked]</a><o:p></o:p></span></p></div><div><p c=
> lass=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>Subject: =
> RE: [v6ops] Last Call: &lt;draft-ietf-v6ops-v6-aaaa-whitelisting-<o:p></o:p=
> ></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Cons=
> olas;color:black'>implications-08.txt&gt; (Considerations for Transitioning=
>  Content to IPv6)<o:p></o:p></span></p></div><div><p class=3DMsoNormal><spa=
> n style=3D'font-family:Consolas;color:black'>to Informational RFC<o:p></o:p=
> ></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Cons=
> olas;color:black'>Hello,<o:p></o:p></span></p></div><div><p class=3DMsoNorm=
> al><span style=3D'font-family:Consolas;color:black'>I had assumed : 1 zone =
> file (and Mark Andrews correctly pointed at<o:p></o:p></span></p></div><div=
> ><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&quo=
> t;views&quot;).<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span =
> style=3D'font-family:Consolas;color:black'>Would adding this piece of infor=
> mation, directly in the RFC,<o:p></o:p></span></p></div><div><p class=3DMso=
> Normal><span style=3D'font-family:Consolas;color:black'>be useful to avoid =
> confusion for future readers ?<o:p></o:p></span></p></div><div><p class=3DM=
> soNormal><span style=3D'font-family:Consolas;color:black'>Thanks and kind r=
> egards,<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D=
> 'font-family:Consolas;color:black'>Marc Lampo<o:p></o:p></span></p></div><d=
> iv><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>--=
> ---Original Message-----<o:p></o:p></span></p></div><div><p class=3DMsoNorm=
> al><span style=3D'font-family:Consolas;color:black'>From: Ronald Bonica [<a=
>  href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<o:p></=
> o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:C=
> onsolas;color:black'>Sent: 20 February 2012 11:55 PM<o:p></o:p></span></p><=
> /div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:bl=
> ack'>To: EXT - <a href=3D"mailto:[email-masked]">[email-masked]</a>; Ma=
> rc Lampo<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>Cc: <a href=3D"mailto:[email-masked]"=
> >[email-masked]</a><o:p></o:p></span></p></div><div><p class=3DMsoNormal><s=
> pan style=3D'font-family:Consolas;color:black'>Subject: RE: [v6ops] Last Ca=
> ll:<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'fon=
> t-family:Consolas;color:black'>&lt;draft-ietf-v6ops-v6-aaaa-whitelisting-im=
> plications-08.txt&gt;<o:p></o:p></span></p></div><div><p class=3DMsoNormal>=
> <span style=3D'font-family:Consolas;color:black'>(Considerations for Transi=
> tioning Content to IPv6) to Informational RFC<o:p></o:p></span></p></div><d=
> iv><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>Ma=
> rc, Havard,<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span styl=
> e=3D'font-family:Consolas;color:black'>Are you satisfied with the answers p=
> rovided by Joel and Mark?<o:p></o:p></span></p></div><div><p class=3DMsoNor=
> mal><span style=3D'font-family:Consolas;color:black'>&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ron<o:p></o:p></spa=
> n></p></div><blockquote style=3D'border:none;border-left:solid #B5C4DF 4.5p=
> t;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_=
> OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal><span style=3D'fo=
> nt-family:Consolas;color:black'>-----Original Message-----<o:p></o:p></span=
> ></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;co=
> lor:black'>From: <a href=3D"mailto:[email-masked]">v6ops-bounces@ie=
> tf.org</a> [<a href=3D"mailto:[email-masked]">mailto:v6ops-bounces@=
> ietf.org</a>] On<o:p></o:p></span></p></div></blockquote><div><p class=3DMs=
> oNormal><span style=3D'font-family:Consolas;color:black'>Behalf<o:p></o:p><=
> /span></p></div><blockquote style=3D'border:none;border-left:solid #B5C4DF =
> 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"=
> MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>Of EXT - <a href=3D"mailto:joelja@bog=
> us.com">[email-masked]</a><o:p></o:p></span></p></div><div><p class=3DMso=
> Normal><span style=3D'font-family:Consolas;color:black'>Sent: Monday, Febru=
> ary 20, 2012 4:58 PM<o:p></o:p></span></p></div><div><p class=3DMsoNormal><=
> span style=3D'font-family:Consolas;color:black'>To: Marc Lampo<o:p></o:p></=
> span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consola=
> s;color:black'>Cc: <a href=3D"mailto:[email-masked]">[email-masked]</a><o:p=
> ></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-famil=
> y:Consolas;color:black'>Subject: Re: [v6ops] Last Call: &lt;draft-ietf-v6op=
> s-v6-aaaa-<o:p></o:p></span></p></div></blockquote><div><p class=3DMsoNorma=
> l><span style=3D'font-family:Consolas;color:black'>whitelisting-<o:p></o:p>=
> </span></p></div><blockquote style=3D'border:none;border-left:solid #B5C4DF=
>  4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D=
> "MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>implications-08.txt&gt; (Consideratio=
> ns for Transitioning Content to<o:p></o:p></span></p></div></blockquote><di=
> v><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>IPv=
> 6)<o:p></o:p></span></p></div><blockquote style=3D'border:none;border-left:=
> solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-rig=
> ht:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal=
> ><span style=3D'font-family:Consolas;color:black'>to Informational RFC<o:p>=
> </o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family=
> :Consolas;color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMs=
> oNormal><span style=3D'font-family:Consolas;color:black'>On 2/20/12 06:32 ,=
>  Marc Lampo wrote:<o:p></o:p></span></p></div><div><p class=3DMsoNormal><sp=
> an style=3D'font-family:Consolas;color:black'>&gt; Hello,<o:p></o:p></span>=
> </p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;col=
> or:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><=
> span style=3D'font-family:Consolas;color:black'>&gt; (sorry to be late with=
>  my comments, bit overloaded on my side)<o:p></o:p></span></p></div><div><p=
>  class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt;<o:=
> p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'fon=
> t-family:Consolas;color:black'>&gt; 6.1 Security Considerations - paragraph=
>  2 (on DNSSEC)<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span s=
> tyle=3D'font-family:Consolas;color:black'>&gt; The text states : &quot;ther=
> e should not be any negative impact on<o:p></o:p></span></p></div></blockqu=
> ote><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:bla=
> ck'>DNSSEC&quot;<o:p></o:p></span></p></div><blockquote style=3D'border:non=
> e;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.7=
> 5pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p cla=
> ss=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; In my =
> opinion, this is *wrong* :<o:p></o:p></span></p></div><div><p class=3DMsoNo=
> rmal><span style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p>=
> </span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Conso=
> las;color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNorma=
> l><span style=3D'font-family:Consolas;color:black'>IMHO the following appli=
> es.<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'fon=
> t-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p></div><div><p cl=
> ass=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>if you hav=
> e one zone yeah I agree.<o:p></o:p></span></p></div><div><p class=3DMsoNorm=
> al><span style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span=
> ></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;co=
> lor:black'>If you have two zones one with aaaa and one without (assuming th=
> is is<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'f=
> ont-family:Consolas;color:black'>done with dns views style implementation) =
> you can sign both and<o:p></o:p></span></p></div></blockquote><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'>they'll<o:p><=
> /o:p></span></p></div><blockquote style=3D'border:none;border-left:solid #B=
> 5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' =
> id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal><span s=
> tyle=3D'font-family:Consolas;color:black'>both be valid and complete from t=
> he vantage point of a client which<o:p></o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'>resolves one =
> or the other of them but not both.<o:p></o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</=
> o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:C=
> onsolas;color:black'>this is a traditional split horizon problem. it's just=
>  not<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'fo=
> nt-family:Consolas;color:black'>inside/outside.<o:p></o:p></span></p></div>=
> <div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>=
> <o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'=
> font-family:Consolas;color:black'>joel<o:p></o:p></span></p></div><div><p c=
> lass=3DMsoNormal><span style=3D'font-family:Consolas;color:black'><o:p>&nbs=
> p;</o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-fami=
> ly:Consolas;color:black'>&gt; It is correct that, if an AAAA record exists =
> (in a DNSSEC's zone),<o:p></o:p></span></p></div><div><p class=3DMsoNormal>=
> <span style=3D'font-family:Consolas;color:black'>&gt; the appropriate RRSIG=
>  will be known to authoritative NS's.<o:p></o:p></span></p></div><div><p cl=
> ass=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; If, v=
> ia white listing, the decision is taken not to present the<o:p></o:p></span=
> ></p></div></blockquote><div><p class=3DMsoNormal><span style=3D'font-famil=
> y:Consolas;color:black'>AAAA<o:p></o:p></span></p></div><blockquote style=
> =3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;m=
> argin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOT=
> E"><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:blac=
> k'>&gt; record<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span s=
> tyle=3D'font-family:Consolas;color:black'>&gt; (and its signature), this se=
> ems OK.<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D=
> 'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><d=
> iv><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&g=
> t; However : not returning an AAAA record seems identical to : there<o:p></=
> o:p></span></p></div></blockquote><div><p class=3DMsoNormal><span style=3D'=
> font-family:Consolas;color:black'>is<o:p></o:p></span></p></div><blockquote=
>  style=3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4=
> .0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLO=
> CKQUOTE"><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;colo=
> r:black'>no<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span styl=
> e=3D'font-family:Consolas;color:black'>&gt; AAAA record.<o:p></o:p></span><=
> /p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;colo=
> r:black'>&gt; And that - there is no AAAA record - yields to &quot;Next Sec=
> ure&quot;<o:p></o:p></span></p></div></blockquote><div><p class=3DMsoNormal=
> ><span style=3D'font-family:Consolas;color:black'>changes<o:p></o:p></span>=
> </p></div><blockquote style=3D'border:none;border-left:solid #B5C4DF 4.5pt;=
> padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OU=
> TLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal><span style=3D'font=
> -family:Consolas;color:black'>!<o:p></o:p></span></p></div><div><p class=3D=
> MsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; If no AAAA =
> record exists, for a name, the corresponding NSEC<o:p></o:p></span></p></di=
> v></blockquote><div><p class=3DMsoNormal><span style=3D'font-family:Consola=
> s;color:black'>(NSEC3)<o:p></o:p></span></p></div><blockquote style=3D'bord=
> er:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-le=
> ft:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div>=
> <p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; =
> record<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'=
> font-family:Consolas;color:black'>&gt; should not hold a reference to AAAA.=
> <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-f=
> amily:Consolas;color:black'>&gt; But if that AAAA record does exist, the au=
> thoritative NS will have<o:p></o:p></span></p></div><div><p class=3DMsoNorm=
> al><span style=3D'font-family:Consolas;color:black'>NSEC<o:p></o:p></span><=
> /p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;colo=
> r:black'>&gt; (NSEC3)<o:p></o:p></span></p></div><div><p class=3DMsoNormal>=
> <span style=3D'font-family:Consolas;color:black'>&gt; data that shows so.<o=
> :p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-fam=
> ily:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p cla=
> ss=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; A DNSS=
> EC query (ENDS0 + DO set) for AAAA (and the AAAA exists but<o:p></o:p></spa=
> n></p></div></blockquote><div><p class=3DMsoNormal><span style=3D'font-fami=
> ly:Consolas;color:black'>due<o:p></o:p></span></p></div><blockquote style=
> =3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;m=
> argin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOT=
> E"><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:blac=
> k'>to<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'f=
> ont-family:Consolas;color:black'>&gt; whitelisting<o:p></o:p></span></p></d=
> iv><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:blac=
> k'>&gt; will not be returned), cannot be proven by accompanying (and<o:p></=
> o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:C=
> onsolas;color:black'>required)<o:p></o:p></span></p></div><div><p class=3DM=
> soNormal><span style=3D'font-family:Consolas;color:black'>&gt; NSEC (NSEC3)=
> <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-f=
> amily:Consolas;color:black'>&gt; information.<o:p></o:p></span></p></div><d=
> iv><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&g=
> t; Hence : this draft will/might make DNSSEC validating name servers<o:p></=
> o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:C=
> onsolas;color:black'>fail.<o:p></o:p></span></p></div><div><p class=3DMsoNo=
> rmal><span style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p>=
> </span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Conso=
> las;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoN=
> ormal><span style=3D'font-family:Consolas;color:black'>&gt; If you look at =
> 4.3.1.1 (Description of DNS Resolver Whitelisting)<o:p></o:p></span></p></d=
> iv></blockquote><div><p class=3DMsoNormal><span style=3D'font-family:Consol=
> as;color:black'>in<o:p></o:p></span></p></div><blockquote style=3D'border:n=
> one;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3=
> .75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p c=
> lass=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; deta=
> il,<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'fon=
> t-family:Consolas;color:black'>&gt; please observe :<o:p></o:p></span></p><=
> /div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:bl=
> ack'>&gt; 1) the caching name server (and &quot;stub resolver&quot;) ask 2 =
> queries<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D=
> 'font-family:Consolas;color:black'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; (there is o=
> nly one line,<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span st=
> yle=3D'font-family:Consolas;color:black'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
> &nbsp;but it are two queries : one for &quot;A&quot;, one for &quot;AAAA&qu=
> ot;)<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'fo=
> nt-family:Consolas;color:black'>&gt; 2) if the caching name server (or stub=
>  resolver) performs DNSSEC<o:p></o:p></span></p></div><div><p class=3DMsoNo=
> rmal><span style=3D'font-family:Consolas;color:black'>&gt; validation,<o:p>=
> </o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family=
> :Consolas;color:black'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; it will never accept a =
> reply of &quot;NODATA&quot; to the query of AAAA<o:p></o:p></span></p></div=
> ><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'=
> >&gt;&nbsp;&nbsp;&nbsp;&nbsp; (because the NSEC (NSEC3) information will no=
> t prove that<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span sty=
> le=3D'font-family:Consolas;color:black'>&gt; non-existance)<o:p></o:p></spa=
> n></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;c=
> olor:black'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; ((and the validating name server w=
> ill repeat the query to all<o:p></o:p></span></p></div><div><p class=3DMsoN=
> ormal><span style=3D'font-family:Consolas;color:black'>&gt;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp; authoritative NS's, looking for a validatable answer))=
> <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-f=
> amily:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p c=
> lass=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; (the=
>  final result, to the user might be that only the A record is<o:p></o:p></s=
> pan></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas=
> ;color:black'>useable<o:p></o:p></span></p></div><div><p class=3DMsoNormal>=
> <span style=3D'font-family:Consolas;color:black'>&gt;&nbsp;&nbsp;- mission =
> accomplished ?<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span s=
> tyle=3D'font-family:Consolas;color:black'>&gt;&nbsp;&nbsp;But the side effe=
> ct will be that validating caching name servers<o:p></o:p></span></p></div>=
> <div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>=
> will hit<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>&gt;&nbsp;&nbsp; *all* authoritative =
> servers for the domain,<o:p></o:p></span></p></div><div><p class=3DMsoNorma=
> l><span style=3D'font-family:Consolas;color:black'>&gt;&nbsp;&nbsp; &quot;i=
> n search of&quot; a correctly validating answer.)<o:p></o:p></span></p></di=
> v><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black=
> '>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span sty=
> le=3D'font-family:Consolas;color:black'>&gt; So, while for the end-user, th=
> e result might be identical,<o:p></o:p></span></p></div><div><p class=3DMso=
> Normal><span style=3D'font-family:Consolas;color:black'>&gt; one &quot;secu=
> rity impact&quot; of this approach is<o:p></o:p></span></p></div><div><p cl=
> ass=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; addit=
> ional (useless) DNS traffic and<o:p></o:p></span></p></div><div><p class=3D=
> MsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; additional =
> load on authoritative NS's (that implement whitelisting)<o:p></o:p></span><=
> /p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;colo=
> r:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><s=
> pan style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span>=
> </p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;col=
> or:black'>&gt; Kind regards,<o:p></o:p></span></p></div><div><p class=3DMso=
> Normal><span style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:=
> p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Con=
> solas;color:black'>&gt; Marc Lampo<o:p></o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; Security=
>  Officer<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>&gt; EURid<o:p></o:p></span></p></div=
> ><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'=
> >&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span styl=
> e=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></di=
> v><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black=
> '>&gt; -----Original Message-----<o:p></o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; From: Th=
> e IESG [<a href=3D"mailto:[email-masked]">mailto:iesg-secretary@ie=
> tf.org</a>]<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span styl=
> e=3D'font-family:Consolas;color:black'>&gt; Sent: 01 February 2012 04:09 PM=
> <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-f=
> amily:Consolas;color:black'>&gt; To: IETF-Announce<o:p></o:p></span></p></d=
> iv><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:blac=
> k'>&gt; Cc: <a href=3D"mailto:[email-masked]">[email-masked]</a><o:p></o:p>=
> </span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Conso=
> las;color:black'>&gt; Subject: [v6ops] Last Call:<o:p></o:p></span></p></di=
> v><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black=
> '>&gt; &lt;draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt&gt;<o:=
> p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-fami=
> ly:Consolas;color:black'>&gt; (Considerations for Transitioning Content to =
> IPv6) to Informational<o:p></o:p></span></p></div><div><p class=3DMsoNormal=
> ><span style=3D'font-family:Consolas;color:black'>RFC<o:p></o:p></span></p>=
> </div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:b=
> lack'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span=
>  style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p=
> ></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:=
> black'>&gt; The IESG has received a request from the IPv6 Operations WG (v6=
> ops)<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'fo=
> nt-family:Consolas;color:black'>to<o:p></o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; consider=
>  the following document:<o:p></o:p></span></p></div><div><p class=3DMsoNorm=
> al><span style=3D'font-family:Consolas;color:black'>&gt; - 'Considerations =
> for Transitioning Content to IPv6'<o:p></o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt;&nbsp;&nb=
> sp; &lt;draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt&gt; as an=
> <o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-f=
> amily:Consolas;color:black'>&gt; Informational RFC<o:p></o:p></span></p></d=
> iv><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:blac=
> k'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span st=
> yle=3D'font-family:Consolas;color:black'>&gt; The IESG plans to make a deci=
> sion in the next few weeks, and<o:p></o:p></span></p></div></blockquote><di=
> v><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>sol=
> icits<o:p></o:p></span></p></div><blockquote style=3D'border:none;border-le=
> ft:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-=
> right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNor=
> mal><span style=3D'font-family:Consolas;color:black'>&gt; final comments on=
>  this action. Please send substantive comments to<o:p></o:p></span></p></di=
> v><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black=
> '>the<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'f=
> ont-family:Consolas;color:black'>&gt; <a href=3D"mailto:[email-masked]">ietf=
> @ietf.org</a> mailing lists by 2012-02-15. Exceptionally, comments<o:p></o:=
> p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Con=
> solas;color:black'>may be<o:p></o:p></span></p></div><div><p class=3DMsoNor=
> mal><span style=3D'font-family:Consolas;color:black'>&gt; sent to <a href=
> =3D"mailto:[email-masked]">[email-masked]</a> instead. In either case, please=
>  retain the<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span styl=
> e=3D'font-family:Consolas;color:black'>&gt; beginning of the Subject line t=
> o allow automated sorting.<o:p></o:p></span></p></div><div><p class=3DMsoNo=
> rmal><span style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p>=
> </span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Conso=
> las;color:black'>&gt; Abstract<o:p></o:p></span></p></div><div><p class=3DM=
> soNormal><span style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</=
> o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:C=
> onsolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3D=
> MsoNormal><span style=3D'font-family:Consolas;color:black'>&gt;&nbsp;&nbsp;=
> &nbsp;&nbsp;This document describes considerations for the transition of en=
> d<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-=
> family:Consolas;color:black'>user<o:p></o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt;&nbsp;&nb=
> sp;&nbsp;&nbsp;content on the Internet to IPv6.&nbsp;&nbsp;While this is ta=
> ilored to<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>address<o:p></o:p></span></p></div><d=
> iv><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&g=
> t;&nbsp;&nbsp;&nbsp;&nbsp;end user content, which is typically web-based, m=
> any aspects of<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span s=
> tyle=3D'font-family:Consolas;color:black'>this<o:p></o:p></span></p></div><=
> div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&=
> gt;&nbsp;&nbsp;&nbsp;&nbsp;document may be more broadly applicable to the t=
> ransition to<o:p></o:p></span></p></div></blockquote><div><p class=3DMsoNor=
> mal><span style=3D'font-family:Consolas;color:black'>IPv6<o:p></o:p></span>=
> </p></div><blockquote style=3D'border:none;border-left:solid #B5C4DF 4.5pt;=
> padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OU=
> TLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal><span style=3D'font=
> -family:Consolas;color:black'>of<o:p></o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt;&nbsp;&nb=
> sp;&nbsp;&nbsp;other applications and services.&nbsp;&nbsp;This document ex=
> plores the<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;challenge=
> s involved in the transition to IPv6, potential<o:p></o:p></span></p></div>=
> </blockquote><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;=
> color:black'>migration<o:p></o:p></span></p></div><blockquote style=3D'bord=
> er:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-le=
> ft:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div>=
> <p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt;&=
> nbsp;&nbsp;&nbsp;&nbsp;tactics, possible migration phases, and other consid=
> erations.<o:p></o:p></span></p></div></blockquote><div><p class=3DMsoNormal=
> ><span style=3D'font-family:Consolas;color:black'>The<o:p></o:p></span></p>=
> </div><blockquote style=3D'border:none;border-left:solid #B5C4DF 4.5pt;padd=
> ing:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOO=
> K_ATTRIBUTION_BLOCKQUOTE"><div><p class=3DMsoNormal><span style=3D'font-fam=
> ily:Consolas;color:black'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;audience for this doc=
> ument is the Internet community generally,<o:p></o:p></span></p></div><div>=
> <p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt;&=
> nbsp;&nbsp;&nbsp;&nbsp;particularly IPv6 implementers.<o:p></o:p></span></p=
> ></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:=
> black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><spa=
> n style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></=
> p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color=
> :black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><sp=
> an style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span><=
> /p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;colo=
> r:black'>&gt; The file can be obtained via<o:p></o:p></span></p></div><div>=
> <p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; =
> <a href=3D"http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-">http:=
> //datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-</a><o:p></o:p></span><=
> /p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;colo=
> r:black'>whitelisting-impl<o:p></o:p></span></p></div><div><p class=3DMsoNo=
> rmal><span style=3D'font-family:Consolas;color:black'>&gt; ications/<o:p></=
> o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:C=
> onsolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3D=
> MsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; IESG discus=
> sion can be tracked via<o:p></o:p></span></p></div><div><p class=3DMsoNorma=
> l><span style=3D'font-family:Consolas;color:black'>&gt; <a href=3D"http://d=
> atatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-">http://datatracker.ietf.=
> org/doc/draft-ietf-v6ops-v6-aaaa-</a><o:p></o:p></span></p></div><div><p cl=
> ass=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>whitelisti=
> ng-impl<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D=
> 'font-family:Consolas;color:black'>&gt; ications/<o:p></o:p></span></p></di=
> v><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black=
> '>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span sty=
> le=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></d=
> iv><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:blac=
> k'>&gt; No IPR declarations have been submitted directly on this I-D.<o:p><=
> /o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:=
> Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p class=
> =3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbs=
> p;</o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-fami=
> ly:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></div><div><p clas=
> s=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; _______=
> ________________________________________<o:p></o:p></span></p></div><div><p=
>  class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&gt; v6=
> ops mailing list<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span=
>  style=3D'font-family:Consolas;color:black'>&gt; <a href=3D"mailto:v6ops@ie=
> tf.org">[email-masked]</a><o:p></o:p></span></p></div><div><p class=3DMsoNo=
> rmal><span style=3D'font-family:Consolas;color:black'>&gt; <a href=3D"https=
> ://www.ietf.org/mailman/listinfo/v6ops">https://www.ietf.org/mailman/listin=
> fo/v6ops</a><o:p></o:p></span></p></div><div><p class=3DMsoNormal><span sty=
> le=3D'font-family:Consolas;color:black'>&gt;<o:p>&nbsp;</o:p></span></p></d=
> iv><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:blac=
> k'><o:p>&nbsp;</o:p></span></p></div><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>_____________________________________=
> __________<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=
> =3D'font-family:Consolas;color:black'>v6ops mailing list<o:p></o:p></span><=
> /p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;colo=
> r:black'><a href=3D"mailto:[email-masked]">[email-masked]</a><o:p></o:p></s=
> pan></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas=
> ;color:black'><a href=3D"https://www.ietf.org/mailman/listinfo/v6ops">https=
> ://www.ietf.org/mailman/listinfo/v6ops</a><o:p></o:p></span></p></div></blo=
> ckquote><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color=
> :black'>_______________________________________________<o:p></o:p></span></=
> p></div><div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color=
> :black'>v6ops mailing list<o:p></o:p></span></p></div><div><p class=3DMsoNo=
> rmal><span style=3D'font-family:Consolas;color:black'><a href=3D"mailto:v6o=
> [email-masked]">[email-masked]</a><o:p></o:p></span></p></div><div><p class=3D=
> MsoNormal><span style=3D'font-family:Consolas;color:black'><a href=3D"https=
> ://www.ietf.org/mailman/listinfo/v6ops">https://www.ietf.org/mailman/listin=
> fo/v6ops</a><o:p></o:p></span></p></div><div><p class=3DMsoNormal><span sty=
> le=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span></p></div><=
> div><p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>_=
> ______________________________________________ v6ops mailing list<o:p></o:p=
> ></span></p></div><div><p class=3DMsoNormal><span style=3D'font-family:Cons=
> olas;color:black'><a href=3D"mailto:[email-masked]">[email-masked]</a> <a h=
> ref=3D"https://www.ietf.org/mailman/listinfo/v6ops">https://www.ietf.org/ma=
> ilman/listinfo/v6ops</a><o:p></o:p></span></p></div><div><p class=3DMsoNorm=
> al><span style=3D'font-family:Consolas;color:black'><o:p>&nbsp;</o:p></span=
> ></p></div></blockquote></div></div></body></html>=
> 
> --_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_--

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 27 Feb 2012 15:04:08 +0000

Marc and Mark worked together to make one final tweak since I was not correctly capturing what they were each trying to communicate. This minor tweak will appear in a –11 in just a few minutes.

Thanks
Jason