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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
