Subject: [BEHAVE] draft-ietf-behave-address-format-08 nits

From: Ari Keranen <[email-masked]>
Date: Thu, 08 Jul 2010 16:01:10 +0300

Hi,

Sorry for the late (post-LC) comments, but I spotted a couple of small 
issues in the draft that could be still worthwhile to fix:

3.3. Choice of Prefix for Stateless Translation Deployments

     Standard
     routing preference (more specific wins) will then ensure that the
     IPv6 packets are delivered directly, without requiring that
     translators receive the packets and then return them message in the
     direction they came from.

Extra word "message" in the end.

      We will consider an IPv6 network with the prefix 2001:DB8:
      122::/48.  The network administrator has selected the Network-
      Specific prefix 2001:DB8:122:344::/64 for managing stateless IPv4/
      IPv6 translation.  The IPv4-Translatable address block is 2001:
      DB8:122:344:C0:2::/96 and this block is visible in IPv4 as the
      subnet 192.0.2.0/24.  In this network, the host A is assigned the
      IPv4-Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which
      corresponds to the IPv4 address 192.0.2.33.

Here the step from Network-Specific prefix to IPv4-Translatable address
block is not that clear (it's not really evident that "192.0.2" maps to
"C0:2"). Something like this could be more clear:

      The IPv4-Translatable address block for IPv4 subnet 192.0.2.0/24
      is 2001:DB8:122:344:C0:2::/96. In this network [...]

4.2. Choice of the Well-Known Prefix

     However, such destination-address based load
     balancing may not be desirable.  It is not compatible with STUN in
     the deployments involving multiple stateful translators, each one
     having a different pool of IPv4 addresses.

Lacking STUN reference.

Cheers,
Ari