Greg,
> On Jun 16, 2020, at 9:05 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > thank you for providing continued support and guidance. Please find my > notes in-lined under tag GIM>>. Attached are the new working version and > its diff to -12. There are two remaining Open Issues - 7 and 9. I much > appreciate your considerations and suggestions. [...] >>> Open Issue 7: "::FFFF:7F00:0/104 IPv6 range" (COMMENT via Benjamin K.) >>> >>> Proposed Action: I believe this issue's fate is similarly tied to Open >> Issue 3. >>> If the proposal is limited solely to management VNI, this text is not >>> relevant and may be deleted. >> >> This action is still pending. >> > GIM>> There are two references to this IPv6 range. I think that the > document should give a recommendation on what address to use as the > destination IP address. As we've discussed with Adam Roach, only ::ffff: > 127.0.0.1/128 has host loopback meaning in IPv6. I propose to change > throughout the text from "one of the addresses from IPv6 range" to "::ffff: > 127.0.0.1/128 for IPv6". Sorry, the issue is from the IESG ballot at https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ballot/: > 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6). There could be a firewall > configured on VTEP to block loopback addresses if set as the > destination IP in the inner IP header. It is RECOMMENDED to allow > addresses from the loopback range through a firewall only if it is > used as the destination IP address in the inner IP header, and the > destination UDP port is set to 3784 [RFC5881]. > > I think we should reword this to make it clear that the default behavior > is still "block all incoming traffic with loopback destination" and that > the exception is tightly scoped to the encapsulated VXLAN traffic > discussed in this document and the specific destination port *and when > BFD has been configured for the VTEP*. So, the question is what should be done about packet drop or firewalls? My opinion is one possible action for this is to drop the text. For this feature to work, traffic will be arriving with packets destined to these well known ranges. If you want the feature to work, they must be permitted to come through. Rather than mention "if you have it", the related actions are implied by things necessary to implement it. > >>> >>> Open Issue 9: "Destination MAC: This MUST NOT be of one of tenant's MAC >>> addresses." (COMMENT via Benjamin K.) >>> >>> Proposed Action: I believe this issue's fate is similarly tied to Open >> Issue 3. >>> If the proposal is limited solely to management VNI, this text is not >>> relevant and may be deleted. >> >> In -12, we now have the following text: >> "Destination MAC: since a Management VNI is the VNI that does >> not have any tenants, the value of this field is not analyzed >> by the receiving VTEP." >> >> For the management VNI, this text is true. However, it likely requires a >> value that is described in the specification. >> >> Proposed solution: A MAC value should be chosen that is well known and th= > e >> text would become: >> >> "Destination MAC: A Management VNI, which does not have any tenants, will >> have no dedicated MAC address for decapsulated traffic. The value >> X:X:X:X:X >> SHOULD be used in this field." >> >> SHOULD might need to be MUST. Since a partial motivation for permitting >> the >> flexibility in the specification to NOT use the management VNI is desired= > , >> MUST might be inappropriate. >> > GIM>> Accepted the suggested text. I agree that the flexibility to not use > the Management VNI is permitted in the specification and thus SHOULD in the > text is consistent with that scenario. How would we pick the MAC address? I am out of my area of expertise and I was hoping someone in the IESG can offer a fix. :-) I am copying Donald Eastlake since he's the designated expert for the IANA MAC address block. Donald, review of the thread may be useful, but tersely the need is to have a well known MAC address that can be placed in this vxlan PDU that is literally a placeholder of "not to be used for forwarding". The packet arrives at the endpoint and, if not immediately accepted, would be dropped. If there is no well known MAC that could be used for such a behavior, perhaps an address from the IANA block may be used? While I suspect the IANA mac documentation range could be used, IANA may not appreciate that. -- Jeff
