Simon, apologies for the late reply. day job in the way.
>>> 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. good. the text now says the BMR may be an FMR. e.g. in mesh mode a BMR may also be used for forwarding, but in hub and spoke mode, the BMR is not used for forwarding. >>> 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. thanks. ;-) >>>> 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 found it! ;-) >>>> 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 | thanks, fixed. > >>>> 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... only to the extent that it applies to it when it is also an FMR. > >>>> | 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? it is there to help understand where the bits come from. > >>>> Figure 7: Deriving of MAP IPv6 address >>> >>> s/MAP IPv6 address/IPv4 route/ >> >> where? > > In "Figure 7: Deriving of MAP IPv6 address". ;) I believe the figure title is correct. i.e. it refers to the tunnel endpoint address that you derive from the IPv4 address and port. > >>> 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." agree, added. > >>>> 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. correct. you cannot do that with A+P. the user looses control of the ports. >>>> 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... we already refer to a MAP rule earlier in the sentence, I suggest we remove the MAP BMR part. > 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? you are right, there is a confusing redundancy there. let me try to untangle it with the co-authors. I'll then publish an update ASAP. cheers, Ole
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
