%% You should probably cite draft-ietf-behave-v4v6-bih instead of this I-D.
@techreport{huang-behave-bih-01,
    number =    {draft-huang-behave-bih-01},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-huang-behave-bih/01/},
    author =    {Bill Huang and DENG Hui and Teemu Savolainen},
    title =     {{Dual Stack Hosts Using "Bump-in-the-Host" (BIH)}},
    pagetotal = 25,
    year =      2010,
    month =     jul,
    day =       30,
    abstract =  {This document describes the "Bump-In-the-Host" (BIH), a host based protocol translation mechanism that allows a subset of applications supporting only one IP address family to communicate with peers that are reachable or supporting only the other address family. This specification addresses scenarios where a host is provided dual stack or IPv6 only network connectivity. In the dual stack network case, single address family applications in the host sometime will communicate directly with other hosts using the different address family. In the case of IPv6 only network or IPv6 only destination, IPv4 originated communications have to be translated into IPv6. The BIH makes the IPv4 applications think they talk to IPv4 peers and hence hides the IPv6 from those applications. Acknowledgement of previous work This document is an update to and directly derivative from Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI {[}RFC2767{]} and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark's {[}RFC3338{]}, which similarly provides a dual stack host means to communicate with other IPv6 host using existing IPv4 appliations. This document combines and updates both {[}RFC2767{]} and {[}RFC3338{]}. The changes in this document reflect five components 1. Supporting IPv6 only network connections 2. IPv4 address pool use private address instead of the unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255) 3. Extending ENR and address mapper to operate differently 4. Adding an alternative way to implement the ENR 5. Going for standards track instead of experimental/ informational},
}