Subject: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02

From: Dave Thaler <[email-masked]>
Date: Mon, 28 Feb 2011 20:55:35 +0000

I have reviewed the latest version and have two main technical comments.
I also have lots of editorial nits that I will send directly to the authors.
The main technical comments are summarized as follows.

1) There are three ways to implement the ENR.
    a) at the API layer (works fine with DNSSEC)
    b) as a recursive resolver on the same host as discussed in Appendix A
        (I believe this has the same properties as DNS64 with respect to
        DNSSEC impact)
    c) in the network stack as shown in figure 2 (I think this breaks DNSSEC)

    Currently the document allows all three options, though seems to
    treat (a) and (c) as equally recommended, and (b) is almost an afterthought.

    I would prefer a stronger recommendation towards things that work
    with DNSSEC.  For example, could we remove (c) all together from this
    Standards Track document?   I'd rather just make (a) a MUST, or at
    least a strong SHOULD.

    Note that the choice of where the ENR is implemented is orthogonal
    to where the protocol translation is implemented (which could be
    either API layer, or in the network stack).   Don't confuse this comment
    with BIS vs BIA for data translation.

2) Applications using name resolution APIs like gethostbyname() have no
    idea whether DNS will be used or something else (hosts file, mDNS,
    netbios, or whatever else).   Indeed that was one of the main points
    of RFC 6055.  That's another reason why a type (a) ENR works much
    better than a type (b) or (c) ENR, since (a) can be done in a name
    resolution protocol agnostic way and the others cannot.   Hopefully
    folks now understand why I'd prefer to make (a) be a MUST or at least
    a strong SHOULD.

3) Section 2.2 on the translator module in a BIS-like implementation claims
    that it needs to do fragmentation.   Since as shown in figure 2, the
    translator sits on top of the IPv6 stack, and the IPv6 stack can do
    fragmentation, I can't imagine any reason the translator itself would
    need to do fragmentation.   It should just send it down to the IPv6
    module to fragment as needed.

4) Section 2.4 states that the mapper registers a pair itself.  However it
    never gives any reason or use for this, so I think that should be removed.

-Dave