Re: [BEHAVE] Address format documentation plan

[<[e-mail]>]

Dear Dave, all,

This is good initiative. I hope this won't be exclusive to translation-based solutions but covers also encapsulation-based ones. 

FYI, an IPv4-inferred IPv6 prefix/address has been also defined in the context of port range based solutions (http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-01#section-4). As authors of the that draft, our position is:

- to allow the use both LIR and WKP (IANA) for more flexibility and let SP make a decision based on their need and context. LIR being preferred for inter-domain routing issues among others. Two IPv6 service prefixes may be required in order to solve some issues related to fragmentation for instance.

- to standardise few IPv4-inferred IPv6 prefix/address templates. A mean to "signal" the used template may be required as the one defined in: http://tools.ietf.org/html/draft-boucadair-dhcpv6-shared-address-option-00#section-4


Cheers,
Med
 

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Dave Thaler
Envoyé : mardi 16 juin 2009 07:25
À : BEHAVE WG
Objet : [BEHAVE] Address format documentation plan

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