Hi Ian, Thanks for your comments. Please see my reply inline.
>-----Original Message----- >From: [email protected] [mailto:[email protected]] On >Behalf Of Ian Farrer >Sent: Tuesday, May 30, 2017 5:37 PM >To: [email protected] >Cc: Softwires-wg >Subject: [Softwires] Review of draft-ietf-softwire-map-mib-09 > >Hi, > >Here is a review of the current version of the draft. > >Cheers, >Ian > >Introduction > >a1) This needs to be updated: RFC7597 is for MAP-E and encapsulation is >the single mode described there. RFC7599 deals with translation and so >probably doesn’t need to be mentioned at all as it’s not part of the scope. [Yu]:ok, I will update the description to exclude MAP-T. >a2) Section 4.1.2 >The description of error cases is not correct. The checks that are >performed by both CE and BR validate that the v6, v4 and l4 ports are >consistent, not just the v6 and dest. ports. Please check RFC7597 section >8.1. [Yu]: From the section 8.1 of RFC7597 described: "A MAP BR receiving IPv6 packets selects a best matching MAP domain rule (Rule IPv6 prefix) based on a longest address match of the packet's IPv6 source address, as well as a match of the packet destination address against the configured BR IPv6 address(es). The selected MAP Rule allows the BR to determine the EA-bits from the source IPv6 address. To prevent spoofing of IPv4 addresses, any MAP node (CE and BR) MUST perform the following validation upon reception of a packet. First, the embedded IPv4 address or prefix, as well as the PSID (if any), are extracted from the source IPv6 address using the matching MAP Rule. These represent the range of what is acceptable as source IPv4 address and port. Second, the node extracts the source IPv4 address and port from the IPv4 packet encapsulated inside the IPv6 packet. If they are found to be outside the acceptable range, the packet MUST be silently discarded and a counter incremented to indicate that a potential spoofing attack may be underway. " So I will change the description of error check as below: - The Border Relay (BR) will perform a validation of the consistency of the source IPv6 address and destination IPv6 address for the packet using Basic Mapping Rule (BMR). - The Map node(CE and BR) will check that the received packets' source IPv4 address and port is in the range derived from matching MAP Rule. >MIB Comments: > >b1) It appears that the intention to provide a single model to be used by >both BR and CE. For ‘mapRuleBRIpv6Address, the description only >provides information about what the CE does with this value. Is it valid for >a BR? What should the BR do with it? [Yu]: As described in section 7.2 of RFC7597, "If the BR IPv6 address is anycast, the relay MUST use this anycast IPv6 address as the source address in packets relayed to CEs" So I will add a description for the BR in the definition. >Also, for the ‘mapRuleType’ field - Is there a case where a rule >provisioned to a BR is not an FMR? (I’m not familiar enough with MAP BR >implementations to know if this is the case) [Yu]: In my understanding, as described in the section 7 of RFC7597, the first paragraph, "For a given MAP domain, the BR and CE MUST be configured with the following MAP elements. The configured values for these elements are identical for all CEs and BRs within a given MAP domain. o The Basic Mapping Rule and, optionally, the Forwarding Mapping Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and Length of EA bits." In my understanding for above, I think the BR must be configured with the BMR. >b2) mapRuleID OBJECT-TYPE > DESCRIPTION > "An identifier used to distinguish the multiple >mapping > rule which is unique with each CE in the same BR.” > >[if - The description is unclear. If I understand the purpose of this object, >it >is to give a unique identifier to each rule. If this is the case, I would >propose: >“A unique identifier used to distinguish mapping > rules.” [Yu]:Yes, your understanding is right. I will update the description as yours. >b3) The DESCRIPTION fields of mapRulePSIDLen and mapRuleOffset are >identical. The text makes sense for mapRulePSIDLen, but is incorrect for >mapRuleOffset. [Yu]: Opps, sorry, it's a fault. I will change the definition as below: mapRuleOffset OBJECT-TYPE SYNTAX Unsigned32(0..15) MAX-ACCESS read-only STATUS current DESCRIPTION " The number of the mapRuleOffset is 6 by default as to exclude the System ports (0-1023). It is provided via the "Rule Port Mapping Parameters" in the Basic Mapping Rule." DEFVAL {6} ::= { mapRuleEntry 9 } >b4) RulePSID ::= TEXTUAL-CONVENTION > DISPLAY-HINT "0x:" > STATUS current > DESCRIPTION > "It represents the PSID represented in the hexadecimal >version > so as to display it more clearly." > SYNTAX OCTET STRING (SIZE (4)) > >[if - Is 4 correct here? The allowable range for the PSID is 0..65535 which is >2 octets] [Yu]: I will update it to "SYNTAX OCTET STRING (SIZE (2))" > b5) mapRuleEALen OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The length of the Embedded-Address (EA) defined in > mapping rule which will be assigned to CE." > REFERENCE > "EA: section 3 of RFC 7597." > ::= { mapRuleEntry 10 } > >[if - This can also be constrained for allowable values (0..48)] [Yu]：Thanks for your remind. I will update it to "SYNTAX Unsigned32(0..48)" >b6) mapRuleType > >[if - The choice that is being presented here isn’t inline with the F-Flag >field >described in sec 4.1 of RFC7598 (and by extension the FMR description in >RFC7597). The F flag defines if a rule can be used for forwarding (i.e. mesh >mode), not if it is a a BMR or an FMR (a BMR can be used for mesh mode if >the F flag is set). Any of the received rules can be considered as a suitable >BMR via the longest prefix match. [Yu]: I will update the definition as below: RuleType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This enumeration provides the type of the mapping rule. It defines tree types of mapping rules here: bmr: Basic Mapping Rule (Not Forwarding Mapping Rule), fmr: Forwarding Mapping Rule (Not Basic Mapping Rule), bmrAndfmr: Basic & Forwarding Mapping Rule. The Basic Mapping Rule may also be a Forwarding Mapping Rule for mesh mode." REFERENCE "bmr, fmr: section 5 of RFC 7597. bmrAndfmr: section 5 of RFC 7597， section 4.1 of RFC 7598." SYNTAX INTEGER { bmr(1), fmr(2), bmAndfmr(3) } mapRuleType OBJECT-TYPE SYNTAX RuleType MAX-ACCESS read-only STATUS current DESCRIPTION "It represents the type of the mapping rule. The value of 1 means it is a bmr; the value 2 means it is a fmr, the value 3 means that the bmr is also a fmr for mesh mode." REFERENCE "bmr, fmr: section 5 of RFC 7597. bmrAndfmr: section 5 of RFC 7597， section 4.1 of RFC 7598." ::= { mapRuleEntry 11 } Thanks again for you review. Cheers Yu ______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
