Éric, On Wed, Jul 22, 2020 at 05:28:14AM -0700, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-bfd-vxlan-13: Abstain > [...]
> ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document and its update. I have cleared > one of my DISCUSS point about TTL = Hop Limit not being 255. > > But, the authors and I are in an impasse about the use of IPv4-mapped IPv6 > addresses but I do not want to block the document. I change my ballot to > "ABSTAIN" in the sense of "I oppose this document but understand that others > differ and am not going to stand in the way of the others". Thank you. This will let us continue toward broader IETF review. > BTW, I understood that the use a prefix rather than /32 or /128 was to allow > for entropy (to explore multiple ECMP/LAG paths). This is one possible case, but primarily it is to let the receiving application have something they can internally "catch" in their packet intercept code. Many router vendors implement unusual things in the loopback network range. > BTW2, the right wording is > "IPv4-mapped IPv6 address" and not "IPv4-mapped IPv4 address" as written twice > in the document. As noted in a separate thread, we'll address that correction. > Did you (or actually the authors) also investigate the use of the: This is my personal comment; the authors are requested to comment as well. > - ::/0 : unspecified address This often interacts oddly with socket libraries and likely would not be as portable as one might want. > - 100::/8 the discard prefix used for RTBH RFC 6666 > - or even requesting a block out of the 2001::/23 (reserved for IETF special > use) As you comment in your private reply, the desire is that we never see the prefix in question in routing. The loopback network property encodes that semantic quite nicely - it's completely local to the box in question. --- I believe that when this thread concludes, we will have closed on last of the open issues. Once Greg has done the necessary updates to pull in the last few issues, I'll update the shepherd report and resubmit to the IESG. Thanks for your efforts. -- Jeff
