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

From: <[email-masked]>
Date: Tue, 1 Mar 2011 15:48:33 +0000

Thank you Dave very much for your comments - we are already working on new revision. Some replies and clarifying questions inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Dave Thaler
> Sent: 28. helmikuuta 2011 22:56
> To: [email-masked]
> Subject: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02
> 
> 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.

Agree, the (a) comes from BIA and (c) from BIS, and this (b) is indeed newer thinking. Will look if this could be clarified. But I would not say (c) breaks DNSSEC more than network-based DNS64...:-) Works as long as host's resolver does not do its own validation.

>     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.

The (a) is definitely the most powerful and works best with DNSSEC, but at the same time I believe most difficult to implement. The (b) and (c) are possible to have as plug-ins, which gives them some merit (especially for the time being when host based DNSSEC validation is quite rare). What if document would say (a) is MUST if it is feasible to implement (i.e. acknowledging sometimes the "MUST" may not hold)?
 
>     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.

Agree, we will look ways to clarify this to the draft.

> 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.

I'm not so sure about need for BIH for local communications (mDNS, netbios?) but this is true. Will add these considerations to the ENR section.

> 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.

I thought SIIT procedure would directly construct an IPv6 packet that can be sent to the next hop link? I.e. the IPv6 packet would not be constructed by the actual IPv6 layer, but just transported. While thinking about this, it might be wiser for a host having BIS-model implementation to actually set local IPv4 interface's MTU small enough to avoid generation of IPv4 packets that would be too large after translation:)

---

From: Dave Thaler <[email-masked]>
Date: Tue, 1 Mar 2011 17:38:36 +0000

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 01, 2011 7:49 AM
> To: Dave Thaler; [email-masked]
> Subject: RE: Comments on draft-ietf-behave-v4v6-bih-02
> 
> Thank you Dave very much for your comments - we are already working on
> new revision. Some replies and clarifying questions inline:
> 
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of ext Dave Thaler
> Agree, the (a) comes from BIA and (c) from BIS, and this (b) is indeed newer
> thinking. Will look if this could be clarified. But I would not say (c) breaks
> DNSSEC more than network-based DNS64...:-) Works as long as host's resolver
> does not do its own validation.
> 
> The (a) is definitely the most powerful and works best with DNSSEC, but at the
> same time I believe most difficult to implement. The (b) and (c) are possible to
> have as plug-ins, which gives them some merit (especially for the time being
> when host based DNSSEC validation is quite rare). What if document would say
> (a) is MUST if it is feasible to implement (i.e. acknowledging sometimes the
> "MUST" may not hold)?

"MUST if it is feasible to implement" means the same as "SHOULD", and the 
latter is more concise.
 
> I'm not so sure about need for BIH for local communications (mDNS, netbios?)
> but this is true. Will add these considerations to the ENR section.

Aside: Neither mDNS nor netbios are restricted to communication on the link.
Netbios has name servers (like DNS does), which are what Windows folks
some call WINS servers and RFCs 1001 and 1002 call name server ("NBNS") nodes.
mDNS uses multicast and, contains text saying that it could be used in the future
within wider scopes such as site-local.

My main point is that DNS is not the only protocol for off-link name resolution,
and implementation option (a) is better than the others.

> I thought SIIT procedure would directly construct an IPv6 packet that can be
> sent to the next hop link? I.e. the IPv6 packet would not be constructed by the
> actual IPv6 layer, but just transported. While thinking about this, it might be
> wiser for a host having BIS-model implementation to actually set local IPv4
> interface's MTU small enough to avoid generation of IPv4 packets that would
> be too large after translation:)

Section 4 of draft-ietf-behave-v6v4-xlate already contains sufficient
discussion.  So I think the text on fragmentation can be removed, since
the previous paragraph already references the entirety of that document.

-Dave

---

From: <[email-masked]>
Date: Tue, 1 Mar 2011 19:15:08 +0000

> "MUST if it is feasible to implement" means the same as "SHOULD", and the

SHOULD then, for the next revision, perhaps:
--
In order to properly support DNSSEC, the ENR SHOULD be implemented at the 
socket API level. If the socket API level implementation is not possible, 
DNSSEC support SHOULD be provided by other means.
--

> and implementation option (a) is better than the others.

Maybe:
--
In the case of the socket API layer implementation option, when an IPv4 application
tries to do a forward lookup to resolve names via the resolver
library (e.g., gethostbyname()), BIH intercepts the function call and
instead calls the IPv6 equivalent functions (e.g., getnameinfo()) that
will resolve both A and AAAA records. This implementation option is name resolution
protocol agnostic, and hence supports techniques such as "hosts-file",
NetBIOS, mDNS, and essentially anything underlying operating system uses.
--

> the previous paragraph already references the entirety of that document.

Probably the same applies then for checksum as well, and hence the whole section could be:
--
2.2.  Protocol translator

   The protocol translator translates IPv4 into IPv6 and vice versa
   using the IP conversion mechanism defined in SIIT
   [I-D.ietf-behave-v6v4-xlate].  To avoid unnecessary fragmentation,
   host's IPv4 module should be configured with small enough MTU (IPv6
   link MTU - 20 bytes).
--