Subject: [Softwires] Section 5.1 of the MAP draft

From: Tom Taylor <[email-masked]>
Date: Mon, 28 Jan 2013 11:59:21 -0500

I made some editorial comments about Section 5.1 the other day. I have a 
substantive comment now, and a text proposal to pull it all together.

Comment: the statement

      "For a = 0, A MAY be 0 to
       allow for the provisioning of the system ports."

just below Figure 2 is illogical, since if a = 0, the value A does not 
exist. In fact, a = 0 returns us to the naive approach in the second 
paragraph of Section 5.1. Hence I propose alternative text for the 
section. Note two changes to Figure 2: removed extra bit 16 and changed 
the title.

Proposed text:

5.1.  Port Mapping Algorithm

The port mapping algorithm is used to represent the port numbers 
allocated to a given CE if the CE has been given a shared IPv4 address.

The simplest way to allocate ports is to allocate one range of 
consecutive ports to each CE sharing an address. The Port-Set Identifier 
(PSID) is an index over the sequence of allocated ranges, starting from 
zero. In this case, assuming that the number of port numbers in each 
allocated range is a power of 2, the set of port numbers allocated to a 
given CE can be represented using a notation similar to CIDR [RFC4632], 
but with 16 bits instead of 32. For example, assuming a range size of 
256 port numbers, the first 256 ports are
represented as port prefix 0.0/8, the last 256 ports as 255.0/8.  In
hexadecimal, 0x0000/8 (PSID = 0) and 0xFF00/8 (PSID = 0xFF).

It can be seen from the example that the lowest PSID values allocate 
ports in the system port range [I-D.ietf-tsvwg-iana-ports] to one or 
more CEs. To avoid this, the lowest PSID values (0x00 to 0x03 in the 
example) should not be used.

A more sophisticated approach allocates ports in a series of blocks, 
where each CE sharing an address receives one range from each block. 
This can be represented as shown in Figure 2.

                      0                    1
                      0 1 2 3 4 5 6 7 8 9  0 1 2 3 4 5
                      +-------+-----------+----------+
        Ports in      |   A   |    PSID   |     M    |
     the CE port set  |  > 0  |           |any value |
                      +-------+-----------+----------+
                      |a bits |  k bits   |  m bits  |

        Figure 2: Three-Part Decomposition of Allocated Port Numbers

A     Indexes the blocks of port numbers. The lowest block number
       (A = 0) and possibly others contain the system port numbers,
       and hence should not be used if port numbers 0-1023 are to
       be avoided.

a     Width of the field containing the block index A. Indirectly
       a determines the block size, by the formula:
             Block size = 65536 / 2^a

       a = 0 brings us back to the simple (single block) model
       described above, where the PSID value rather than the value
       of A must be restricted to avoid the system ports. The value
       of a is optionally provisioned as part of the mapping rule.
       The default value for a is 4, to place the start of the PSID
       on a nibble boundary. This leaves ports in the range 0-4095
       unallocated.

PSID  Indexes the position of the allocated range for a given CE
       within each block. In the more general model, where A > 0,
       PSID values can begin at 0 without causing system ports to
       be allocated.

k     Width of the field containing the PSID. The number of CEs
       sharing the same IPv4 address is given by 2^k, except when
       a = 0 and the lowest PSID values are excluded.

M     Indexes a specific port number within a range determined by
       the values of A and the PSID.

m     Width of the port index field. The number of ports in each
       allocated range is given by 2^m.

---

From: Qi Sun <[email-masked]>
Date: Tue, 29 Jan 2013 13:54:27 +0800

Dear Tom,

>      a determines the block size, by the formula:

I'm not sure of the meaning of 'Block size', which is equal to 2^(k+m). As I interpret, each CE can get 2^(a+m) ports and each port range is 2^m. What can we use the 'Block size' for?

Thanks in advance!

Best Regards,
Qi Sun

On 2013-1-29, at 上午12:59, Tom Taylor wrote:

> I made some editorial comments about Section 5.1 the other day. I have a substantive comment now, and a text proposal to pull it all together.
> 
> Comment: the statement
> 
> just below Figure 2 is illogical, since if a = 0, the value A does not exist. In fact, a = 0 returns us to the naive approach in the second paragraph of Section 5.1. Hence I propose alternative text for the section. Note two changes to Figure 2: removed extra bit 16 and changed the title.
> 
> 
> Proposed text:
> 
> The port mapping algorithm is used to represent the port numbers allocated to a given CE if the CE has been given a shared IPv4 address.
> 
> The simplest way to allocate ports is to allocate one range of consecutive ports to each CE sharing an address. The Port-Set Identifier (PSID) is an index over the sequence of allocated ranges, starting from zero. In this case, assuming that the number of port numbers in each allocated range is a power of 2, the set of port numbers allocated to a given CE can be represented using a notation similar to CIDR [RFC4632], but with 16 bits instead of 32. For example, assuming a range size of 256 port numbers, the first 256 ports are
> It can be seen from the example that the lowest PSID values allocate ports in the system port range [I-D.ietf-tsvwg-iana-ports] to one or more CEs. To avoid this, the lowest PSID values (0x00 to 0x03 in the example) should not be used.
> 
> A more sophisticated approach allocates ports in a series of blocks, where each CE sharing an address receives one range from each block. This can be represented as shown in Figure 2.
> 
>                     0                    1
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Tom Taylor <[email-masked]>
Date: Tue, 29 Jan 2013 19:49:27 -0500

Taking your comment literally, I'd say that the number of blocks is more 
relevant than the block size, so maybe the formula shouldn't be there. 
Just in case you didn't understand what a block is, I illustrate the 
ideas below.

The basic idea is that, instead of assigning a single sequence of ports 
to a CE, the port space from whatever to 65535 is divided up into 
equal-size chunks, or blocks, and the CE is assigned a sequence of m 
ports from each block. I assume that this is done to make a 
port-guessing attacker's job more difficult, but I'm not sure it does so 
if the attacker knows the algorithm. My own view is that the MAP 
document could get rid of a bunch of complexity if, like lw4o6, it left 
the *port* mapping algorithm to a separate draft. The PSID could stay, 
since it is needed, but the only thing important to MAP is the *address* 
mapping algorithm.

Anyway, here is your illustration. Assume for example that a = 4, 
implying a block size of 4096 (0x1000) port numbers. Thus port number 
space is divided up into 16 blocks as shown in the figure below. Hex 
notation is used for neatness.

What is also shown below is the set of ports allocated to a particular 
CE, represented by P..P. This is a sequence occuring at the same 
relative position in every block. The PSID is an index that points to 
that relative position. The first port number, in fact, is PSID * m from 
the beginning of the block, where m is the total number of ports in the 
sequence P..P.

Port

----
0x0000

Block not used -- contains system ports.

0x0FFF
----
0x1000

P..P

0X1FFF
----
0x2000
   .
   .
   .
   .
0xEFFF
----
0xF000

P..P

0xFFFF
----

On 29/01/2013 12:54 AM, Qi Sun wrote:
>> (A = 0) and possibly others contain the system port numbers, and
>> hence should not be used if port numbers 0-1023 are to be avoided.
>>
>> a     Width of the field containing the block index A. Indirectly a
>> determines the block size, by the formula: Block size = 65536 /
>> 2^a
>
>
> I'm not sure of the meaning of 'Block size', which is equal to
> 2^(k+m). As I interpret, each CE can get 2^(a+m) ports and each port
> range is 2^m. What can we use the 'Block size' for?
>
> Thanks in advance!
>
> Best Regards, Qi Sun
>
>
...

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Jan 2013 11:41:09 +0100

Tom,

> Taking your comment literally, I'd say that the number of blocks is more relevant than the block size, so maybe the formula shouldn't be there. Just in case you didn't understand what a block is, I illustrate the ideas below.
> 
> The basic idea is that, instead of assigning a single sequence of ports to a CE, the port space from whatever to 65535 is divided up into equal-size chunks, or blocks, and the CE is assigned a sequence of m ports from each block. I assume that this is done to make a port-guessing attacker's job more difficult, but I'm not sure it does so if the attacker knows the algorithm. My own view is that the MAP document could get rid of a bunch of complexity if, like lw4o6, it left the *port* mapping algorithm to a separate draft. The PSID could stay, since it is needed, but the only thing important to MAP is the *address* mapping algorithm.

no, the port mapping algorithm in MAP is _not_ written the way it is to make an attackers job more difficult.
the port mapping algorithm in MAP is the simplest algorithm we could think of, that would exclude the well
known ports with arbitrary values of PSID.

I don't at all see why moving the port mapping algorithm out of the document would make things simpler.
it would make it a lot more complex. then you'd end up with having to support many different port algorithms.

cheers,
Ole

> Anyway, here is your illustration. Assume for example that a = 4, implying a block size of 4096 (0x1000) port numbers. Thus port number space is divided up into 16 blocks as shown in the figure below. Hex notation is used for neatness.
> 
> What is also shown below is the set of ports allocated to a particular CE, represented by P..P. This is a sequence occuring at the same relative position in every block. The PSID is an index that points to that relative position. The first port number, in fact, is PSID * m from the beginning of the block, where m is the total number of ports in the sequence P..P.
> 
> Port
> 
> ----
> 0x0000
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 30 Jan 2013 07:41:00 -0500

Below.

...

>>
>> The basic idea is that, instead of assigning a single sequence of
>> ports to a CE, the port space from whatever to 65535 is divided up
>> into equal-size chunks, or blocks, and the CE is assigned a
>> sequence of m ports from each block. I assume that this is done to
>> make a port-guessing attacker's job more difficult, but I'm not
>> sure it does so if the attacker knows the algorithm. My own view is
>> that the MAP document could get rid of a bunch of complexity if,
>> like lw4o6, it left the *port* mapping algorithm to a separate
>> draft. The PSID could stay, since it is needed, but the only thing
>> important to MAP is the *address* mapping algorithm.
>
> no, the port mapping algorithm in MAP is _not_ written the way it is
> to make an attackers job more difficult. the port mapping algorithm
> in MAP is the simplest algorithm we could think of, that would
> exclude the well known ports with arbitrary values of PSID.
>
> I don't at all see why moving the port mapping algorithm out of the
> document would make things simpler. it would make it a lot more
> complex. then you'd end up with having to support many different port
> algorithms.
>
> cheers, Ole
>

My first reaction to that is to say: unless we fix a at 4, you're going 
to be stuck with implementing the a = 0 case anyway, so you might as 
well use that and exclude the lowest values of PSID if you want to keep 
things simple. The WG really needs to have an opinion on which direction 
to go here.

Thinking in terms of the broader picture, I still wonder if the port 
mapping algorithm should be documented separately with MAP having a 
normative dependency on it, just so the algorithm is reusable amongst 
all A+P variants.

Tom

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Jan 2013 13:47:21 +0100

Tom,

[...]

> My first reaction to that is to say: unless we fix a at 4, you're going to be stuck with implementing the a = 0 case anyway, so you might as well use that and exclude the lowest values of PSID if you want to keep things simple. The WG really needs to have an opinion on which direction to go here.

a premise of MAP is to not put any dependency on the IPv6 addressing plan of the ISP. excluding e.g. PSID = 0, would require the ISP
to not delegate that prefix to the end-user. that's a dependency we do not want.

I'm fine with fixing a to 4.
if an end user needs well known ports, give her a full address.

> Thinking in terms of the broader picture, I still wonder if the port mapping algorithm should be documented separately with MAP having a normative dependency on it, just so the algorithm is reusable amongst all A+P variants.

that is really water under the bridge at this stage.
we have been there and tried that. that's how we started with MAP as the base document, and separate MAP-E and MAP-T documents.

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Wed, 30 Jan 2013 08:42:18 -0500

Below, with [PTT].

On 30/01/2013 7:47 AM, Ole Troan wrote:
> Tom,
>
> [...]
>
>>> I don't at all see why moving the port mapping algorithm out of
>>> the document would make things simpler. it would make it a lot
>>> more complex. then you'd end up with having to support many
>>> different port algorithms.
>>>
>>>
>> My first reaction to that is to say: unless we fix a at 4, you're
>> going to be stuck with implementing the a = 0 case anyway, so you
>> might as well use that and exclude the lowest values of PSID if you
>> want to keep things simple. The WG really needs to have an opinion
>> on which direction to go here.
>
> a premise of MAP is to not put any dependency on the IPv6 addressing
> plan of the ISP. excluding e.g. PSID = 0, would require the ISP to
> not delegate that prefix to the end-user. that's a dependency we do
> not want.
>
[PTT] OK, that statement is in 5.1 now, but I didn't understand it. I'll 
look at the original text again.

> I'm fine with fixing a to 4. if an end user needs well known ports,
> give her a full address.
>
[PTT] I have no opinion on the value of a. Agreed about needing a full 
address to get system ports.

>> Thinking in terms of the broader picture, I still wonder if the
>> port mapping algorithm should be documented separately with MAP
>> having a normative dependency on it, just so the algorithm is
>> reusable amongst all A+P variants.
>
> that is really water under the bridge at this stage. we have been
> there and tried that. that's how we started with MAP as the base
> document, and separate MAP-E and MAP-T documents.
>
> cheers, Ole
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Jan 2013 15:56:36 +0100

> if an end user needs well known ports, give her a full address.

An alternative is possible that
- permits ISPs that want it to assign well-known ports to some privileged users without necessarily giving them full IPv4 addresses;
- uses a trivially simple algorithm.

That which has been chosen for 4rd can be used for MAP-E as well. It uses for this an option to be used if well-nown ports must be assignable.

It is specified in two sentences, in http://tools.ietf.org/html/draft-ietf-softwire-4rd-04#page-15, at the end of the first paragraph. 
Its complete picture representation is in a part of Figure 5:
  
                 (by default)           (If WKPs authorized)
                    :    :                  :    :
                +---+----+---------+        +----+-------------+
   Ports in     |> 0|PSID|any value|   OR   |PSID|  any value  |
the CE port set +---+----+---------+        +----+-------------+
                : 4 :     12       :        :        16        :

Regards,
RD

---

From: Tom Taylor <[email-masked]>
Date: Wed, 30 Jan 2013 10:52:05 -0500

> Le 2013-01-30  13:47, Ole Troan <[email-masked]> :
[Ole said:]
>> if an end user needs well known ports, give her a full address.
[Rémi said:]
...

OK, this explains the bit about system ports in the text, when a = 0. 
The one objection I see to that is again the matter of address 
dependency -- the system ports are available only for the first few 
PSIDs, the PSIDs appear as part of the MAP endpoint prefix, so the 
prefix value becomes constrained.

Since devices requiring system ports are likely to be servers, the full 
address solution makes sense on another level too.

Tom Taylor

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 30 Jan 2013 16:12:15 +0000

On 1/30/13 10:52 AM, "Tom Taylor" <[email-masked]> wrote:

>> - permits ISPs that want it to assign well-known ports to some
>>privileged users without necessarily giving them full IPv4 addresses;
>> That which has been chosen for 4rd can be used for MAP-E as well. It
>>uses for this an option to be used if well-nown ports must be assignable.
>>
>> It is specified in two sentences, in
>>http://tools.ietf.org/html/draft-ietf-softwire-4rd-04#page-15, at the
>>end of the first paragraph.

I agree, that a full address for servers running in a map domain makes the
most sense.
However, since all the well known ports are defined to be < 1024, it seems
that it is advantageous to exclude just that range.
The draft says
"To simplify the port mapping algorithm the defaults are chosen so
   that the PSID field starts on a nibble boundary and the excluded port
range (0-1023) is extended to 0-4095."

How important is to have the PSID start on a nibble boundary? There are
already a lot of bit manipulations involved, I don't see it hard to
implement in a non-nibble boundary.

Thanks
Senthil

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Jan 2013 17:47:12 +0100

2013-01-30  16:52, Tom Taylor <[email-masked]> :

> OK, this explains the bit about system ports in the text, when a = 0. The one objection I see to that is again the matter of address dependency -- the system ports are available only for the first few PSIDs, the PSIDs appear as part of the MAP endpoint prefix, so the prefix value becomes constrained.
> 
> Since devices requiring system ports are likely to be servers, the full address solution makes sense on another level too.

Agreed, it does make sense, and I believe that many ISPs may make this choice. (I personally argued in this direction long ago.)

But there has been a firm requirement in the WG that, even for shared addresses, one of the CE could have the well-known ports. 
The WKPs-authorized option has been added to 4rd to satisfy this requirement. 
I don't think this requirement has disappeared.

A copy of this mail is addressed to Maoke who was involved in this discussion.

Regards,
RD