Subject: [Softwires] draft-despres-softwire-4rd-addmapping

From: Nejc Škoberne <[email-masked]>
Date: Tue, 23 Aug 2011 14:00:39 +0100

Dear authors,

I have some comments on your draft.

---------------------------------------------------------------------------
3.  Terminology

<snip>

   4rd IID prefix:       A 32-bit value use to disambiguate what
                         concerns the 4rd address mapping from other
                         address mapping that may coexist it the same
                         AFTRs or CPEs, e.g. with dynamic port
                         assignments.

[NS: It would be nice if you defined what IID stands for. I guess it is
"Interface ID"?]

<snip>

5.3.  Mapping from IPv4 address or A+P to IPv6 address

<snip>
   For tunnel-based solutions (encapsulation or double-translation
   based),

[NS: I think we have a terminology problem here. I think double-translation
is not tunnel-based solution, since there is no encapsulation. See below
for further discussion on this.]

<snip>
   proposed to IANA for the 4rd IID prefix is 200:5efe::/32.  It has bit
   6 of its first octet set to 1, in order to indicate a universal scope
   of the IID ("u" bit of).  Its other bits have, like in [RFC4214],
   IANA OUI in modified EUI format (ref.  [RFC4291]).

[NS: I guess there is a word missing in the parentheses ("u" bit of ??)?]

<snip>

5.4.  Algorithmic Derivation of a Port Set from a Port-Set ID

   The port set specified by an

[NS: Unfinished sentence? As I can see, the port-set derivation algorithm
has changed. It would be nice to see the motivation why to use this particular
algorithm, so to maybe describe its properties and state why they are
important. For example, why do we need to reverse those bits in step [B](1)
in Figure 4? Also, it is not clear to me what is the "yyyy" part of the
pattern. Why is it separated from the x-es? Finally, it would be great to
show a short table of an example port-pairs obtained using this algorithm.]
---------------------------------------------------------------------------

Other than that, a few more general comments:

1. Terminology
--------------

I think there is confusion regarding to use of terms tunneling and
encapsulation. After some research, I would define the terms as follows:

- Encapsulation. A process of wrapping a packet in another header of the
  same or different network protocol. Decapsulation is therefore the process
  of stripping off the outmost header of the encapsulating packet, which
  brings us back to the encapsulated packet.

- Tunneling. A process of encapsulation, transmission and decapsulation
  of a packet.

So again, double-translation has nothing to do with tunneling. In spirit of
this, I would revise all occurencies of words "tunnel"/"tunneling" and
"encapsulation" in the draft.

2. Separating the mapping mechanism from the port-set calculation algorithm
---------------------------------------------------------------------------

I would say that the address mapping described in the draft is somewhat
orthogonal to the port-set calculation algorithm also proposed. The same
goes for other stateless solutions, so I suggest, that we try to put all
these algorithms into a separate document.

As far as I am aware, the following algorithms have been officially proposed:

 a) Sequential method: port-set is a range of consecutive ports. (See 
    I-D.matsuhira-sa46t-spec-03.)

 b) Modulo method: port-set for 1st CPE is (0, N, 2*N, ...), port-set for 
    2nd CPE is (1, N+1, 2*N+1, ...) and so on, where N is the number of CPEs
    sharing the same IPv4 address. (See I-D.xli-behave-divi-03.)

 d) "New 4rd method" (interleaved port-pairs): port-set for the 1st CPE is
    (0, 1, 2*N, 2*N+1, 4*N, 4*N+1, ...), where N is the number of CPEs
    sharing the same IPv4 address. (See I-D.despres-softwire-4rd-addmapping-00.)

 d) "Old 4rd method" (interleaved port-ranges of different sizes): port-set
    for the 1st CPE is:
    ([4k..4k/N], [8k..8k/N], [16k..16k/N], [32k..32k/N]),
    for the 2nd CPE is:
    ([4k+4k/N..4k+2*4k/N], ..., [32k+32k/N..32k+2*32k/N]),
    where N is the number of CPEs sharing the same IPv4 address. (See 
    I-D.murakami-softwire-4rd-00.)
 
 e) Random method: port-set is a randomly chosen subset of all available ports.
    (See I-D.boucadair-pppext-portrange-option-07.)

 f) Port-range-mask method: port-set is a range of consecutive ports or a
    set of ranges of consecutive ports. (See
    I-D.boucadair-pppext-portrange-option-07.)

If I forgot something, please let me know. It would be also nice to compare
all these algorithms and to identify the trade-offs. The mechanism drafts would
then just pick one of these algorithms (without the need to define it again)
and justify the decision for the specific algorithm.

What do you think about this proposal? With my colleagues we are preparing
another port-selection algorithm, which would enhance the security for
stateless solutions. Something like a stateless-ready counterpart to the 
Random method, specified in I-D.boucadair-pppext-portrange-option-07. This way
we could just add such an algorithm to this "algorithms document" and the
IPv4 address sharing mechanism document authors could then choose the one
which suits them best.

Thanks,
Nejc

---

From: <[email-masked]>
Date: Tue, 30 Aug 2011 17:28:35 +0800

|As far as I am aware, the following algorithms have been 
|officially proposed:
|
| a) Sequential method: port-set is a range of consecutive ports. (See 
|    I-D.matsuhira-sa46t-spec-03.)
|
| b) Modulo method: port-set for 1st CPE is (0, N, 2*N, ...), 
|port-set for 
|    2nd CPE is (1, N+1, 2*N+1, ...) and so on, where N is the 
|number of CPEs
|    sharing the same IPv4 address. (See I-D.xli-behave-divi-03.)
|
| d) "New 4rd method" (interleaved port-pairs): port-set for 
|the 1st CPE is
|    (0, 1, 2*N, 2*N+1, 4*N, 4*N+1, ...), where N is the number of CPEs
|    sharing the same IPv4 address. (See 
|I-D.despres-softwire-4rd-addmapping-00.)
|
| d) "Old 4rd method" (interleaved port-ranges of different 
|sizes): port-set
|    for the 1st CPE is:
|    ([4k..4k/N], [8k..8k/N], [16k..16k/N], [32k..32k/N]),
|    for the 2nd CPE is:
|    ([4k+4k/N..4k+2*4k/N], ..., [32k+32k/N..32k+2*32k/N]),
|    where N is the number of CPEs sharing the same IPv4 address. (See 
|    I-D.murakami-softwire-4rd-00.)
| 
| e) Random method: port-set is a randomly chosen subset of all 
|available ports.
|    (See I-D.boucadair-pppext-portrange-option-07.)
|
| f) Port-range-mask method: port-set is a range of consecutive 
|ports or a
|    set of ranges of consecutive ports. (See
|    I-D.boucadair-pppext-portrange-option-07.)
|
|If I forgot something, please let me know. It would be also 

One more port allocation method documented in separated documents, by which different deployment scenarios and possible provisioning means are elaborated :

Deploy this method  in DS-Lite context:
draft-zhou-softwire-b4-nat-02

Deploy in A+P context: 
draft-deng-v6ops-aplusp-experiment-results-01

A possible provisioning means - PCP:
draft-tsou-pcp-natcoord-03

Cheers,
Xiaohong

|nice to compare all these algorithms and to identify the 
|trade-offs. The mechanism drafts would then just pick one of 
|these algorithms (without the need to define it again) and 
|justify the decision for the specific algorithm.

|
|What do you think about this proposal? With my colleagues we 
|are preparing another port-selection algorithm, which would 
|enhance the security for stateless solutions. Something like a 
|stateless-ready counterpart to the Random method, specified in 
|I-D.boucadair-pppext-portrange-option-07. This way we could 
|just add such an algorithm to this "algorithms document" and the
|IPv4 address sharing mechanism document authors could then 
|choose the one which suits them best.
|
|Thanks,
|Nejc
|