Re: [Softwires] WGLC review of draft-ietf-softwire-map

[Simon Perreault <[e-mail]>]

Le 2014-01-02 12:11, Ole Troan a écrit :
>> 1. The distinction between BMR and FMR is very confusing. And it's going to get even more confusing when the reader gets to draft-ietf-softwire-map-dhcp, where there is only a single unified "rule" parameter. Suggestion: remove the concept of FMR. The text already says that the BMR is an FMR, so this means that FMR is already conceptually equal to "MAP rule". So just replace FMR with "MAP rule". Then say that one of the MAP rules is special: it is the BMR. I've provided text inline below.
>
>     "Mapping rules are used differently depending on their function.
>     Every MAP node must be provisioned with a Basic mapping rule.  This
>     is used by the node to configure its IPv4 address, IPv4 prefix or
>     shared IPv4 address.  This same basic rule can also be used for
>     forwarding, where an IPv4 destination address and optionally a
>     destination port is mapped into an IPv6 address.  Additional mapping
>     rules are specified to allow for multiple different IPv4 sub-nets to
>     exist within the domain and optimize forwarding between them."
>
> isn't this text clear enough?
> the analogy of BMR versus FMR, is a router advertisement with two PIO's, one PIO with the A flag set
> and optionally the L flag, and one PIO with the A flag off and the L flag set.
> we've chosen to give those different names to be very clear on their purpose.
> I would claim that it is more confusing and harder to understand the effects of the A/L flags in the PIO example. ;-)
>
> suggested action: keep the BMR/FMR distinction.

I'm not against that suggestion, as long as the other (previously 
agreed) adjustments are made. That is, right now the BMR/FMR distinction 
doesn't make sense because the text says a BMR is an FMR. If that is 
fixed, then at least we can have a BMR/FMR distinction that makes sense. 
Not my preference, but it will work.

Specifically, a BMR it not an FMR because its L flag (to reuse the PIO 
analogy) may be off, whereas for an FMR it is always on.

>> 2. Section 5 says:
>>
>>    1.  Basic Mapping Rule (BMR) - mandatory. [...]
>>        The Basic Mapping Rule is also a Forwarding Mapping Rule. [...]
>>    In hub and spoke mode, there are no forwarding rules [...]
>>
>> Contradiction? There must be at least one FMR since the BMR is an FMR and it is mandatory.
>
> hmm... good point. this is the equivalent of a single RA PIO with the A flag on and L flag off.
> that is all traffic goes through the BR. what about:
>
> "In hub and spoke mode, there are no forwarding rules, apart from the default rule to the BR"

Ok.

>> 3. I can't make sense of this part from section 5.1:
>>
>>    For a > 0, A MUST be larger than 0. [...]
>>    For smaller values of a, A still has to be greater than 0 [...]
>>    For larger values of a, the minimum value of A has to be higher [...]
>>
>> Smaller than what? Larger than what? If a is smaller than a>0, that means a=0. How can A then be greater than 0 if it is 0 bits long?
>>
>> Further comments inline...
>
> agree. I can't make sense of it either. ;-)
>
> OLD:
>   A  Selects the range of the port number.  For a > 0, A MUST be larger
>        than 0.  This ensures that the algorithm excludes the system
>        ports.  For this value of a, the system ports, but no others, are
>        excluded by requiring that A be greater than 0.  For smaller
>        values of a, A still has to be greater than 0, but this excludes
>        ports above 1023.  For larger values of a, the minimum value of A
>        has to be higher to exclude all the system ports.  The interval
>        between successive contiguous ranges assigned to the same user is
>        2^a.
>
> Proposed:
> A   Selects the range of the port number.  For a > 0, A MUST be larger
>        than 0.  This ensures that the algorithm excludes the system
>        ports.  For the default value of a (6), the system ports, are
>        excluded by requiring that A be greater than 0.  Smaller
>        values of a excludes a larger initial range. E.g. a = 4, will exclude ports 0 - 4095.
>        The interval between successive contiguous ranges assigned to the same user is
>        2^a.

Looks good.

>>>    A companion document defines a DHCPv6 option for provisioning of MAP
>>
>> A companion document defines DHCPv6 options for provisioning of Softwire clients
>
> I'm not sure that we should introduce "softwire clients" as a new term here.

I see. Then keep it as is.

>>>    MAP node                A device that implements MAP.
>>
>> Implementation has nothing to do with it.
>>
>> s/implements MAP/participates in a MAP domain/
>
> implements as in "supports/uses", not implement as the act of coding.
> see http://tools.ietf.org/html/rfc4861#section-2 for a node.

I understand, and thanks for the reference, but I still think that this 
is wrong.

 From the point of view of the protocol spec, there is no difference 
between a node that does not implement MAP and a node that implements 
MAP but has it turned off. Both are not MAP nodes, again from the point 
of view of the protocol spec. Unless you want to distinguish between 
nodes that have the MAP function turned off and those that have it 
turned on, which I don't think you do in the current text.

Anyhow, this is mostly a style issue, I don't care too much.

>>>    This architecture is illustrated in Figure 1.
>>>
>>>
>>>          User N
>>>        Private IPv4
>>>       |  Network
>>>       |
>>>    O--+---------------O
>>>    |  |  MAP CE       |
>>>    | +-----+--------+ |
>>>    | NAPT44|  MAP   | |
>>>    | +-----+      | | |\     ,-------.                      .------.
>>
>> Remove this --------^
>
>
>
>>
>>>    |       +--------+ | \ ,-'         `-.                 ,-'       `-.
>>>    O------------------O  /              \   O---------O  /   Public   \
>>>                          /   IPv6 only   \  |  MAP    | /     IPv4     \
>>>                         (    Network      --+  Border +-   Network     )
>>>                          \  (MAP Domain) /  |  Relay  | \              /
>>>    O------------------O  \              /   O---------O  \             /
>>>    |    MAP   CE      |  /".         ,-'                 `-.       ,-'
>>>    | +-----+--------+ | /   `----+--'                       ------'
>>>    | NAPT44|  MAP   | |/
>>>    | +-----+        | |
>>>    |   |   +--------+ |
>>>    O---.--------------O
>>
>> s/./+/
>
> I'm not quite sure what you mean, could you give a complete figure with your suggested changes?

Hehehehe, sure:

OLD:
          User N
        Private IPv4
       |  Network
       |
    O--+---------------O
    |  |  MAP CE       |
    | +-----+--------+ |
    | NAPT44|  MAP   | |
    | +-----+      | | |\     ,-------.                      .------.
    |       +--------+ | \ ,-'         `-.                 ,-'       `-.
    O------------------O  /              \   O---------O  /   Public   \
                          /   IPv6 only   \  |  MAP    | /     IPv4     \
                         (    Network      --+  Border +-   Network     )
                          \  (MAP Domain) /  |  Relay  | \              /
    O------------------O  \              /   O---------O  \             /
    |    MAP   CE      |  /".         ,-'                 `-.       ,-'
    | +-----+--------+ | /   `----+--'                       ------'
    | NAPT44|  MAP   | |/
    | +-----+        | |
    |   |   +--------+ |
    O---.--------------O
        |
         User M
       Private IPv4
         Network

NEW:
          User N
        Private IPv4
       |  Network
       |
    O--+---------------O
    |  |  MAP CE       |
    | +-----+--------+ |
    | NAPT44|  MAP   | |
    | +-----+        | |\     ,-------.                      .------.
    |       +--------+ | \ ,-'         `-.                 ,-'       `-.
    O------------------O  /              \   O---------O  /   Public   \
                          /   IPv6 only   \  |  MAP    | /     IPv4     \
                         (    Network      --+  Border +-   Network     )
                          \  (MAP Domain) /  |  Relay  | \              /
    O------------------O  \              /   O---------O  \             /
    |    MAP   CE      |  /".         ,-'                 `-.       ,-'
    | +-----+--------+ | /   `----+--'                       ------'
    | NAPT44|  MAP   | |/
    | +-----+        | |
    |   |   +--------+ |
    O---+--------------O
        |
         User M
       Private IPv4
         Network

>>>    Port-aware IPv4 entries in the Rules table are installed for all the
>>
>> What is a "port-aware IPv4 entry"?
>
> yes, that's not clear. let me wordsmith.
>
>>>    Forwarding Mapping Rules and an default route to the MAP BR (see
>>
>> s/Forwarding Mapping Rules/MAP rules/
>>
>> s/an/a/
>
> ack.
>
>>
>>>    section Section 5.4.
>>
>> That paragraph was very unclear. Reword.
>
> any suggestion?

I just spent some time trying to come up with better text but I realized 
all of it is repeated from elsewhere.

Section 5.3:
    On forwarding an IPv4 packet, a best matching prefix look up is done
    in the Rules table and the correct FMR is chosen.

Section 5:
    Traffic outside of the domain (i.e. When the destination IPv4 address
    does not match (using longest matching prefix) any Rule IPv4 prefix
    in the Rules database) is forwarded to the BR.

So you could just delete it I guess.

>>>                      0                   1
>>>                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>>
>> Move the two lines above to the right by one character.
>
> hmm, I don't see that error?

Assuming you want to number bits and not frontiers between bits, the 0 
should be aligned with the first bit. And I just noticed that index 16 
needs to be removed.

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

NEW:
                       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    |           |       |
                      +-----------+-----------+-------+
                      |  a bits   |  k bits   |m bits |

>>> 5.2.  Basic mapping rule (BMR)
>>>
>>>    The Basic Mapping Rule is mandatory, used by the CE to provision
>>>    itself with an IPv4 prefix, IPv4 address or shared IPv4 address.
>>>    Recall from Section 5 that the BMR consists of the following
>>
>> s/the BMR/a MAP rule/
>
> this is specifically about the BMR though.

Right, but when reading this text I got confused when I reached section 
5.2 on FMRs since that reference to Section 5 made me think that Section 
5 only applied to BMRs.

Anyhow, this is very minor.

>>> 5.3.  Forwarding mapping rule (FMR)
>>
>> Rename this section to: "Deriving IPv4 routes from MAP rules"
>
> see top.

Well, the problem with this is that this section *does* apply to BMRs as 
well, unless I am mistaken...

>>>    |        32 bits           |         |    16 bits        |
>>>    +--------------------------+         +-------------------+
>>>    | IPv4 destination address |         |  IPv4 dest port   |
>>>    +--------------------------+         +-------------------+
>>>                    :          :           ___/       :
>>>                    | p bits   |          /  q bits   :
>>>                    +----------+         +------------+
>>>                    |IPv4  sufx|         |Port-Set ID |
>>>                    +----------+         +------------+
>>>                    \          /    ____/    ________/
>>>                      \       :  __/   _____/
>>>                        \     : /     /
>>>    |     n bits         |  o bits   | s bits  |   128-n-o-s bits      |
>>>    +--------------------+-----------+---------+------------+----------+
>>>    |  Rule IPv6 prefix  |  EA bits  |subnet ID|     interface ID      |
>>>    +--------------------+-----------+---------+-----------------------+
>>>    |<---  End-user IPv6 prefix  --->|
>>
>> Remove the above line, because only the BMR contains the End-user IPv6 prefix. In general, MAP rules do not (unless we start referring to other user's End-user IPv6 prefix, but that would become confusing very quickly).
>
> the BMR doesn't contain the End-user ipv6 prefix either.

Hmmm... right. So remove it from both Figure 3 and Figure 7?

>>>                  Figure 7: Deriving of MAP IPv6 address
>>
>> s/MAP IPv6 address/IPv4 route/
>
> where?

In "Figure 7: Deriving of MAP IPv6 address". ;)

>>    A CE that allows
>>>    IPv6 configuration by DHCP SHOULD implement this option.
>>
>> Which one? It needs to be introduced earlier.
>
> with the informative references I suggest we drop this sentence.

WFM.

>>>    A single MAP CE MAY be connected to more than one MAP domain, just as
>>>    any router may have more than one IPv4-enabled service provider
>>>    facing interface and more than one set of associated addresses
>>>    assigned by DHCP.  Each domain a given CE operates within would
>>>    require its own set of MAP configuration elements and would generate
>>>    its own IPv4 address.
>>
>> But we're still limited to one MAP domain per End-user IPv6 prefix, right?
>
> yes.

How about adding: "Note that each MAP domain requires a distinct 
End-User IPv6 prefix."

>>>    For increased reliability and load balancing, the BR IPv6 address MAY
>>>    be an anycast address shared across a given MAP domain.  As MAP is
>>>    stateless, any BR may be used at any time.  If the BR IPv6 address is
>>>    anycast the relay MUST use this anycast IPv6 address as the source
>>>    address in packets relayed to CEs.
>>
>> What about IPv4 anycast?
>
> what about it?

Uh, nevermind, I don't remember, sorry.

>>>    For a shared IPv4 address, a MAP CE forwarding IPv4 packets from the
>>>    LAN performs NAT44 functions first and creates appropriate NAT44
>>>    bindings.  The resulting IPv4 packets MUST contain the source IPv4
>>>    address and source transport identifiers defined by MAP.  The IPv4
>>
>> s/defined by/obtained with/
>
> specified by?

ok.

>>>    A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends this
>>>    packet to the CE's MAP function where it is decapsulated.  All other
>>>    IPv6 traffic is forwarded as per the CE's IPv6 routing rules.  The
>>>    resulting IPv4 packet is then forwarded to the CE's NAT44 function
>>>    where the destination port number MUST be checked against the
>>>    stateful port mapping session table and the destination port number
>>>    MUST be mapped to its original value.
>>
>> The previous sentence should be reworded to allow static port forwarding.
>
> hmm, what do you mean by static port forwarding?

For example, the user goes to the CPE's admin web interface and 
configures a mapping from external port 80 to internal host port 80. 
That's a static mapping that needs to be taken into account by the NAT 
function. The MUSTs above don't seem to allow the necessary wiggle room.

>>>    A MAP BR receiving IPv6 packets selects a best matching MAP domain
>>>    rule based on a longest address match of the packets' source address
>>>    against the BR's configured MAP BMR prefix(es), as well as a match of
>>
>> The BR, being a MAP node, can only have a single BMR, and therefore only one BMR prefix. The alternative would be when the BR is part of multiple MAP domains, which is not what I think you're trying to say. So I'm confused.
>
> I think the intention is to pick the right domain, given that it states "MAP domain rule".
> does anyone else know, have suggestions for better text?

I think what confused me is the phrase "the BR's configured MAP BMR 
prefix(es)". What are those?

Maybe introducing them in section 7.2 would reduce possible confusion...

>>>    the packet destination address against the configured BR IPv6 address
>>>    or FMR prefix(es).  The selected MAP rule allows the BR to determine
>>
>> The "FMR prefix" concept has not been defined by this point.
>
> I can expand that to "FMR Rule IPv6 prefix".

WFM.

>> It should be possible to express this using only "MAP rule".
>
> the BR address isn't a MAP rule, which is why it is written like that.
>
>>>    the EA-bits from the source IPv6 address.  The BR MUST perform a
>>>    validation of the consistency of the source IPv6 address and source
>>>    port number for the packet using BMR.  If the packets source port
>>
>> "source IPv6 address and source port number" --> I don't know which port number this refers to. Especially since later text deals with port numbers...
>
> I'm not sure I understand your concern? isn't the "source port" a known term? e.g. RFC768?
> or is this because there seems to be some redundancy between this paragraph and the next?

Hehehe... I was just wondering if in the phrase "source IPv6 address and 
source port number", the "source port number" is the IPv6 source port or 
the IPv4 source port. I suppose it would be the IPv4 source port since 
that's what you're supposed to verify with the BMR, and there are no 
IPv6 port anyway with protocol 41. That would make sense to me, however 
the next paragraph also deals with IPv4 source port validation. So is it 
just a matter of redundancy between paragraphs, or is my understanding 
incorrect?

> that was a lot! thanks a lot for very good and thorough comment!
>
> and if anyone else has gotten all the way down here.
> Happy New Year!

Likewise!

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca