[BEHAVE] Address format documentation plan

[Dave Thaler <[e-mail]>]

The chairs have been discussing how to proceed with the documentation
plan regarding the address format and prefix.

First, we observed that there are actually two mostly orthogonal technical
issues:

Issue #1: Choice of IPv6 prefix

Issue #2: Choice of method by which the remainder of the IPv6 address
          is derived from an IPv4 address

For issue #1, there's two alternatives: LIR vs WKP.

For issue #2, there's been multiple proposals already (and we actually
expect there to be more), including:

a)  Zero-pad and embed IPv4 address at the end

b)  Embed IPv4 address right after the prefix, and zero-pad the rest

c)  Use some reversible hash over the IPv4 address to get another set of
    bits and put that in somewhere

What we would like to see is one doc (separate from the framework, DNS64,
NAT64, SIIT update, and FTP ALG, docs) that would be a standards track
document, and covers both of the above issues and gives per-scenario
recommendations for each.  It would specify requirements for algorithms
that would apply to any new algorithms proposed later, and then specify
one or more actual algorithms prescriptively.  It would likely
also point out that the choice of algorithm is not required to be the
same in all networks, but having a small number makes implementing them
easier.

The above doc, plus SIIT update, would together obsolete the two pieces
of the existing SIIT RFC.  There are docs (like
draft-xli-behave-v4v6-prefix-00.txt) that cover most of issue #1
but still need some work on per-scenario recommendations, and hence
may have some text that could be incorporated into the combined doc.

The other WG docs (framework, DNS64, NAT64, SIIT update, FTP ALG, anything
else) would then contain no normative details of any algorithm,
but would be allowed to point to the above doc either informatively or
normatively (e.g., if the above doc specified multiple algorithms,
it would be legal to point to the entire doc, or to a single algorithm
within it, as needed).

To give folks a more clear idea of what we're looking for, here's a
sample title and outline:

Title: IPv6 Addressing of IPv6/IPv4 Address Translators
(Note an "address translator" is anything that has to derive
an IPv6 address from an IPv4 address or vice versa, which applies to
DNS64 and possible other ALGs, not just a NAT64 or stateless
translator.)

Outline:
   * Introduction
      - IPv6 Addresses assigned to IPv6 hosts
      - IPv6 Addresses used for IPv4 hosts
   * Prefix Selection
      - Requirements (routing system scalability, effect on applications, etc)
      - LIR
        * definition, scenario-independent discussion
      - WKP
        * definition, scenario-independent discussion
      - Scenario-specific discussions/recommendations
        * Scenario 1
        * Scenario 2
        * ...
        * Scenario 6
    * IPv6 Address Format & Address Translation Algorithms
      - MUST/SHOULD/MAY Requirements for algorithms
         (e.g., reversible, checksum neutrality, ability to
           pretty-print an address in string format with
           an IPv4 address in dotted decimal like ::FFFF:1.2.3.4 does,
           ability to hide an IPv4 address from "smart" ALGs,
           ability to hide details of internal IPv4 subnetting)
      - v4-mapped (as used by RFC 3493 and RFC 2765)
          * definition, discussion
      - v4-translatable (as used by RFC 2765)
          * definition, discussion (perhaps deprecate them by this document?)
      - Pref64 (padding then address)
        * definition, discussion
      - IVI (address then padding)
        * definition, discussion
      - Pre-configured mapping table
        * definition, discussion
      - Scenario-specific discussions/recommendations
        * Scenario 1
        * Scenario 2
        * ...
        * Scenario 6

The current thinking is that the chairs will take a shot at building -00
from existing drafts/emails with the goal to transition the doc to
willing volunteers for -01.  Anyone who authored a current draft from
which text is pulled would be listed as a contributor unless they
ask not to be.

We're also interested in using some sort of issue tracking system,
which could be http://trac.tools.ietf.org/wg/behave/trac/report/1
or could simply be a web page maintained by the editor(s), or whatever
else works.

-Dave Thaler and Dan Wing