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