Re: [BEHAVE] Address format documentation plan

[marcelo bagnulo braun <[e-mail]>]

Looks good to me.
Thanks for taking the lead on this.

I am willing to contribute on this.

Regards, marcelo

Dave Thaler escribió:
> 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
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>
>