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

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, March 01, 2011 7:49 AM
> To: Dave Thaler; [e-mail]
> 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:
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of ext Dave Thaler
> > Sent: 28. helmikuuta 2011 22:56
> > To: [e-mail]
> > 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)?

"MUST if it is feasible to implement" means the same as "SHOULD", and the 
latter is more concise.
 
> >     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.

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.

> > 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:)

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