Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

[Alvaro Retana <[e-mail]>]

On May 4, 2020 at 4:24:45 PM, John Scudder ([e-mail]) wrote:

Seriously? Doesn’t this just turn into a question of “but what do you mean
by ‘valid IP host address’” then? By contrast, referencing RFC 6890 (and
associated registries, by the transitive property or something) means that
there’s a specific definition the implementor can dig their teeth into.

This is what I’m thinking:  the IP address we’re talking about is akin to
the NEXT_HOP.  As you pointed out, the same clarity issues (for the
NEXT_HOP) exist in rfc4271.

Pointing to rfc6890 may be a good solution, but doing so in this draft and
not in rfc4271 seems inconsistent to me.  If rfc6890 is the solution to the
validity question, then we should have rfc4271 use it — IOW, what ever
rfc4271 uses should also be used by this document.

But without having an answer (yet) for rfc4271, then I think the best we
can do with this document is to point to it.  We can then “fix” rfc4271,
which would automagically fix this document as well.  I’m sure we’re not
ready for a bis, but a small document updating would be enough.


My 2c.

Alvaro.




Thanks,

—John

On May 4, 2020, at 4:22 PM, Alvaro Retana <[e-mail]> wrote:


[External Email. Be cautious of content]


John:

Hi!


I think that pointing at rfc4271 may be better; it explicitly talks about
the address being a host route, and it is akin to the NEXT-HOP…

Thanks!!

Alvaro.

On May 4, 2020 at 3:57:10 PM, John Scudder ([e-mail]) wrote:

Hi Alvaro,

On Feb 21, 2020, at 7:47 AM, Alvaro Retana <[e-mail]> wrote:

428   o  The IP address in the sub-TLV's address subfield is not a valid IP
429      address (e.g., it's an IPv4 broadcast address).

[major] What is a "valid IP address"?  The text above says that
link-local are not allowed...and that a host address is expected...and
that the address must "belong"...now you added broadcast addresses.
Anything else?  Is a multicast destination "valid"?  Is there a
reference that can be added here to avoid having to define it?


This problem has been around from time immemorial; for example RFC 4271 has
a couple of places where it says things like

   Syntactic correctness means that the NEXT_HOP attribute represents a
   valid IP host address.


I remember wrestling with this in years past, but I’m not sure I ever came
up with a good solution. The best reference I can find is RFC 6890,
"Special-Purpose IP Address Registries”, which defines what we generally
refer to as “martians”. Using that, perhaps the rule could be rewritten
something like this?

"o The IP address in the sub-TLV’s address subfield is listed in the
relevant Special-Purpose IP Address Registry [RFC6890] as either not a
valid destination, or not forwardable.”

In practice this would probably be implemented by using the
implementation-specific “martian” list, but this gives us a way to cite it
normatively. By the way, this nominally makes the text about link-local
redundant, since both the v4 and v6 special-purpose registries include
link-local.

—John