Subject: [BEHAVE] Comments on draft-ietf-behave-dns64-05

From: Dave Thaler <[email-masked]>
Date: Tue, 5 Jan 2010 03:01:10 +0000

My comments and suggested wording changes on this document 
are marked up in the PDF at 
http://research.microsoft.com/~dthaler/draft-ietf-behave-dns64-05.pdf

They're mostly editorial.  Some technical-ish comments are:

1) Section 5.1.3, last paragraph allows two possible behaviors when
the DNS64 gets some addresses in the excluded ranges and some outside
the excluded ranges:
a) use only the non-excluded addresses,
b) pretend it got no addresses

Both of the above possibilities are "MAY".
Do we really have no preference (or at least no consensus on any
preference)?  I'm okay with no preference, just want to confirm.

2) Section 5.3.1 includes two possible behaviors for handling PTRs:
a) respond authoritatively itself,
b) synthesize a CNAME

Do we really have no preference (or at least no consensus on any
preference)?  I'm okay with no preference, just want to confirm.

3) The discussion in A.4 about static records vs synthesis on
update vs synthesis on query, I believe should be moved out
of the "examples" section and into a section in the main body.
It's also missing an explanation of why synthesis on query is
sometimes needed.  Specifically, it should explain that it may 
be the case where the primary server that receives all the 
DNS updates cannot be upgraded for whatever reason (e.g.,
it's considered production and DNS64 is considered a pilot),
but where a secondary can be upgraded in order to handle the
(comparatively small amount) of AAAA queries. This is an 
important operational consideration.

It's still fine to recommend the other alternatives, but
explaining the above is important to show that the alternative
isn't just there "for completeness" as it currently states.

Some larger editorial comments are:
4) as others have noted, the use of X, Y' etc in Appendix A is
really confusing.  Since the point of the appendix is to walk
through examples, it should be replaced with literal examples
using IP addresses from the documentation ranges and/or 
well-known prefix, and similarly using literal hostnames like
h2.example.com.

5) Appendix A still needs lots of editing work.  I felt like
I had more comments on the Appendix than on the rest of the
doc combined, and it still contains things that contradict
the rest of the doc (e.g. it says that an IPv6->IPv4 address
mapping is never implemented in a DNS64 but in the PTR section,
second option, it is).

6) I'm not sure Appendix A should remain an appendix.  If it's
a good example walkthough it can have a regular numbered section.

-Dave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 Jan 2010 20:07:42 +0100

Hi Dave,

thanks for the review

see replies below

those marked with AS, i am hoping Andrew can address them

DT1: changed to stateful nat64

DT2: added

      If not explicitly
      mentioned, all prefixes are treated equally and the operations
      described in this document are performed using the prefixes available.
      So without loosing generality, we will call Pref64::/n to any of 
these prefixes and
      describe the operations made with the generic prefix Pref64::/n.

DT3 done

DT4 done

DT5: done

DT6: done

DT7: AS

DT8: done

DT9: let's wait to see what we do with the appendix

DT10: I don't think the dns64 synthesizes PTR RR. As i see it, the dns64 
replies to PTR queries that affect prefixes that it is in charge. I have 
added the follwoing sentence.

          <t>DNS64 also responds to PTR queries involving
            addresses containing any of the IPv6 prefixes it uses for 
synthesis of AAAA RRs.</t>

DT11: see DT10

DT12 rephrased as
Support of multicast address
          handling is out of the scope of this document. A possible 
approach is specified in
          <xref target="I-D.venaas-behave-mcast46" />.

DT13: done

DT14: AS

DT15: AS

DT16:

DT17 done

DT18 done

DT19 rephrased as

                    <t>    For each prefix Pref64::/n, n MUST the less 
than or equal to 96.
                    If one or more Pref64::/n are configured in the 
DNS64 through any means in the DNS64
                    (such as manually configured, or other automatic 
means not specified
                    in this document), the default algorithm MUST use 
these prefixes (and not use the Well-Know Prefix).
                    If no prefix is available, the algorithm MUST use 
the Well-Known prefix
                    64:FF9B::/96 defined in <xref 
target="I-D.ietf-behave-address-format" /> to represent the IPv4 unicast 
address range</t>

DT20 see DT19

DT21 done

DT22 AS

DT23 done

DT24: AS

DT25: AS

DT26: AS

DT27: AS
 
DT28: AS

DT29: right, not sure what you want to add in the draft about this, if 
anything

DT30 done

DT31 done

DT32 done

DT33 done

DT34: changed notation to use real IP addresses

DT35 removed the section, added details of the translation within the 
example

DT36 to DT41 no longer apply since are in the removed section

DT42 done

DT43 done

DT44 done

DT45 done

DT46 changed the diagram accordingly

DT47 rephrased as

            <t>The local name server is configured to represent the 
whole IPv4 unicast space with
                using the WKP 64:FF9B::/96

DT48 rephrased as

            <t>For this example, assume the typical DNS situation where 
IPv6 hosts
            have only stub resolvers, and they are configured with the 
IP address of a name server that they always have to query and that 
performs recursive
            lookups (henceforth called "the recursive nameserver").</t>

DT49 done

DT50 removed the sentence

DT51 done

DT52 done

DT53 done

DT54 fixed

DT55 done

DT56 done

DT57, we cannot use the WKP in this case, so i will use a NSP that is 96 
bit long.

DT58 maybe, but i am not sure where to put this, as it seems the 
application of the dns64 to a specific scenario, which is what the 
appendix is all about

DT59 done

DT60 done

DT61 done

DT62 done

DT63 done

DT64 removed the sentence

DT65 done

DT66 done

DT67 done

> preference)?  I'm okay with no preference, just want to confirm.
I have left these two for Andrew

> of the "examples" section and into a section in the main body.

i have included the appendix as a numbered section, so this should be 
addressed this way
> important operational consideration.
added that

> well-known prefix, and similarly using literal hostnames like
done

> mapping is never implemented in a DNS64 but in the PTR section,

hopefully fixed
> a good example walkthough it can have a regular numbered section.

ok, i have included it as a numbered section
> -Dave
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Jan 2010 15:26:54 -0500

> DT7: AS

A security-oblivious DNS64 receiving with DO=1 and CD=1 is a possible
case, I guess, and it's just like with DO=1 and CD=0.  None of it
matters, because it won't respond to the DO bit.  I can add that.

Similarly, in case 1 covers any case with the DO bit clear: if the bit
is clear, it makes no difference to the response.  I can add this too.

> DT15: AS

The reason these are both MAY is because it's up to the implementation
or the configuration.  I was unable to discern a clear direction from
the WG when we made this change, so I left it open.  If people have a
preference, we can obviously change it.  But, given that this document
barely got reviews during LC, it seems as likely to me that people
don't care one way or the other.

> DT16:

I don't think we can pick one and be consistent.  That's because there
are actually different roles here.  I agree that we have too many terms.

One role is the plain, generic, DNS64 function.  You don't care where
it's happening, but it's happening somewhere and when it happens, the
document says what should happen.  This is sometimes unfortunately
shortened to "DNS64" in the document, and I think it's fair to say
that the name should be consistent or the definitions should
explicitly make then consistent.

Another role is DNS64 in the server, whatever kind of server this
happens to be.  So it might be recursive, or it might be an authority
server.  This is also sometimes spelled "the DNS64 nameserver".  If
you really want one term there, ok, but I can't believe this is the
source of confusion.

Another role is a DNS64 recursor, which is _not_ co-extensive with the
DNS64 server, above.  For a recursor will not be authoritative at
least in cases where it's doing recursion (and it's generally
recommended that you not do recursion and authority in the same name
server).

Finally, we have the role of DNS64 resolver.  This could be anywhere
_except_ as part of the authoritative name server.

Now, if you're claiming that the language hasn't been used precisely
in the document, that's a different matter.  But I thought we'd picked
the right words for each case when we were using them, except for the
first case.  

> DT22 AS

No preference.  The DNS community is totally divided over the use of
reverse mapping.  If we want to wade into that bunfight, then we can
state a preference here; otherwise, we should just outline the options
and be done with it.

> DT24: AS

The other thing you might do is option 2, which is outlined in the next paragraph.

> DT25: AS

This plainly needs to be fixed.  Thanks.

> DT26: AS

Sigh.  I expected that document to be long since published when we
finished this.  I'll reword.  Thanks.

> DT27: AS

As in 25

> DT28: AS

Actually, no.  A validator could validate the data anyway, even if
they didn't set CD=1.  It's a bad idea, because things are quite
likely to break.

Best,
A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Jan 2010 15:39:57 -0500

> synthesis of AAAA RRs.</t>

Well, I take Dave's point.  One of the options we give is in fact to
synthesize PTRs on the basis of other data, which goes a little
further than just answering for its prefixes.  But I think your
additional sentence addresses this.  Dave, do you agree?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.