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

Alvaro Retana <> Fri, 15 May 2020 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D695E3A0B28; Fri, 15 May 2020 08:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AqB1wdHa_KwZ; Fri, 15 May 2020 08:22:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AAB223A0B1D; Fri, 15 May 2020 08:22:01 -0700 (PDT)
Received: by with SMTP id k12so2708835wmj.3; Fri, 15 May 2020 08:22:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=F59RroQle7U6Ct9ZJRVxAkUxfbBfmcLYGQcWA+6gSDk=; b=OIbjbsJ7BxP14s4MtFD+g/NQTNf8gU3Egj/DeI0PD6im977KoaU53gCb4r1KwQqU0o j7ynFIOdFloUeHijtyJyPrGkXZ78IvcxJI08OTY5qO92NnZmRZP6SMm6p2EDv9YgM+no N2a/kRH6tlFEYm8cL74pq4Jh89/dOF5gQfkRpXrqAhjS7nnlw8fmYgzj1WWkO2aVrpbz 0W2AhsFsmgyx+Iw48kafbHhU8VbhRHuzu4NRTqwzUdS5WuxzG2POTtHuovLdh/xsM5OV lfO3TS/IgV3G+bi7rdel/kX4xg0nO1/y4kKZyYVkEKJWd3ne21rx6N/SbqfT9tH2AyF5 YJrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=F59RroQle7U6Ct9ZJRVxAkUxfbBfmcLYGQcWA+6gSDk=; b=V0VJpdpOhT5f+h537VEKedG1xha7Ngad4fbJv44w1ON1Hlmvc+yZPh3KcmQkn85Zfj a/SOBM9l/qqv2kFyYieW3cTvybDffQyDGcMrW2EWQjNGpTZsX+DFB/7EUvG+SFLo7wal MkLVRyzPyPgSk9U8/MzyUdv8Zgm9KCDPsh2oQj+qnEDhPRn6wlmoRKLTjqu+C3rx43Ou sjhAh3bQpx7ulT/TK9UhywG220be1U7DxIw3bqR+mukG46ira9Ra25TFGVy6MkuiKSr9 j+GisSUE3Bkg5SDVtXKE0dn9cxk41hhyrb18qs0a5uW+UDNmuAdDVVvl/T2AuQ7ynRlV Bujw==
X-Gm-Message-State: AOAM5335MtvjGbADetqstWQXg96ief/VaC1D36WIRm4j6wPB88S2aSWx lVrlmLYmmB+L+OfenZ7UoRdh+tyqdVo2U7CXdRxQLhVV
X-Google-Smtp-Source: ABdhPJzivuFz0Dqn18NLEe4lsF6bppXeDhB+x4LpJQaHwkxUNeQxfrxPjaZRFaBe8G51bjGf5al7ZD2IfJ9JT5WUkKY=
X-Received: by 2002:a1c:7914:: with SMTP id l20mr4461863wme.120.1589556120203; Fri, 15 May 2020 08:22:00 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 15 May 2020 08:21:59 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Date: Fri, 15 May 2020 08:21:59 -0700
Message-ID: <>
To: John Scudder <>
Cc: idr-chairs <>, "idr@ietf. org" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000e537f105a5b15fa3"
Archived-At: <>
Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 May 2020 15:22:13 -0000

On May 4, 2020 at 4:24:45 PM, John Scudder ( 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.




On May 4, 2020, at 4:22 PM, Alvaro Retana <> wrote:

[External Email. Be cautious of content]



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…



On May 4, 2020 at 3:57:10 PM, John Scudder ( wrote:

Hi Alvaro,

On Feb 21, 2020, at 7:47 AM, Alvaro Retana <> 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" 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